What jumps out here isn’t the bug itself so much as the shape of it. An official SDK for an authentication-heavy protocol let a server redirect an OAuth exchange to a place it shouldn’t trust. That’s the kind of mistake that looks small in code and huge in blast radius. If I were evaluating MCP client integrations right now, I’d be less interested in the CVSS number and more interested in whether any app I care about ever assumes “the server told me where to log in” is a safe sentence.
The annoying part is that this isn’t some exotic memory corruption issue. It’s a trust-boundary failure, which feels very on-brand for AI tooling in 2026. These systems keep stitching together model clients, third-party servers, and cloud identity flows, and every handoff is a chance to quietly route secrets to the wrong place. The article’s description of the client secret, authorization code, and PKCE proof key all being exposed is exactly the sort of thing that should make protocol designers wince. PKCE is supposed to narrow the damage from interception; here it gets neutralized by design mistakes upstream. That’s not a clever bypass. It’s the protocol being used against itself.
I also think the part about the “interactive” flow is the most unsettling. If a human still sees a real login page and approves the sign-in, they may walk away thinking everything is fine. That’s a terrible security story because it trains people to trust the wrong signal. The UI can be genuine while the token path is rotten. That mismatch is where these bugs get nasty: the operator thinks they authenticated to the real service, but the application quietly leaked the pieces that make the exchange valuable.
The remediation advice has a slightly messy edge too. “Upgrade” is not enough for two providers unless you also pass issuer=. That’s the kind of footgun that survives because it looks like a normal deprecation path until you read the fine print. And the note that the warning is a standard deprecation warning Python hides by default feels almost comically bad. If that’s accurate, I’d call that more than a usability issue; it’s the sort of thing that turns a fix into a near-miss.
What I’d actually do first is inventory every MCP client using OAuth, then check whether it ever talks to servers outside my direct control. If it does, I’d treat the old registrations and secrets as suspect, not just the code. The article’s advice to clear stored registrations and rotate secrets makes sense. The more uncomfortable truth is that this is probably the kind of issue where the vulnerable design pattern lingers long after the patched versions land, because people upgrade the package and stop there.
The release-note / advisory timing is interesting too. If the issuer checks were already in the release notes as “behavior changes,” I can see how this slipped past a lot of people. But I also wouldn’t be shocked if that was one of those moments where the right fix existed before the security framing caught up. That happens all the time in infrastructure code: a semantic correction ships, and only later does everyone realize it was actually a security boundary.
Reference: Official MCP Python SDK Flaw Can Let Malicious Servers Steal OAuth Credentials
