MCP Server Security: What the OAuth Credential Flaw Means for Enterprise AI Agents
A malicious server could tell your AI agent exactly who it was, and your agent had no way to check. That is the plain-language version of a vulnerability disclosed on September 28, 2026 in the official Model Context Protocol (MCP) Python SDK, the library that underpins a large share of the enterprise agent-to-tool connections built on Anthropic’s MCP standard. The flaw did not live in a careless integration or a third-party plugin. It lived in the reference implementation itself, the code thousands of MCP clients import and trust by default.
Security firm Cycode reported the issue, and The Hacker News covered the disclosure in detail. The short version: an MCP server could redirect a connecting client to a token endpoint of the attacker’s choosing, and the SDK had no reliable way to catch it. Patches exist. Most organizations running MCP integrations have not applied them yet, because most organizations do not have a clean inventory of which MCP servers their agents talk to in the first place.
That last sentence is the real story. A CVSS score and a version bump are a patching problem, and patching problems get solved. What this flaw reveals is structural. The MCP ecosystem built its trust model on the assumption that a server correctly identifies itself, and nobody checked what happens when it does not. For a CISO or compliance lead trying to answer “can we prove our AI agents only talked to who they were supposed to talk to,” this is the question that needs an answer, and it does not go away when the SDK ships a fix.
Key Takeaways
- A flaw in the official MCP SDK let rogue servers impersonate identity providers. The reference implementation that enterprise MCP clients import by default failed to verify that an OAuth token endpoint belonged to the authorization server the client thought it was talking to.
- The bug lived in a fallback path, not an edge case. When the SDK’s modern discovery request failed, it fell back to trusting configuration served by the MCP server itself, skipping the one check that would have caught an attacker-controlled endpoint.
- Patching fixes this CVE. It does not fix the trust model. The SDK now validates issuers correctly, but the underlying assumption, that a connecting agent can and should verify a server’s self-reported identity before trusting it with credentials, was never built into the protocol’s default posture.
- Non-human identities already outnumber human ones by roughly 109 to 1, and AI agent identities are growing the fastest. A credential-interception flaw at the SDK layer does not threaten one account. It threatens every agent built on the vulnerable code path.
- Credential hygiene is necessary and not sufficient. Rotating a stolen client secret stops that one compromise. It does nothing for the next agent that connects to a server it has no way to verify, which is why enforcement must move to the point where data is accessed and used, not stop at the token.
How the Vulnerability Worked
MCP clients built on the Python SDK use OAuth to authenticate against the servers they connect to, the same pattern that underlies most modern API authorization. Under normal conditions, the client discovers the authorization server’s metadata, confirms it matches the server it expects, and only then exchanges codes and tokens with that confirmed endpoint.
The vulnerable versions skipped a step. According to the technical writeup from GBHackers, when the SDK’s request for current OAuth discovery metadata returned a 404, it fell back to configuration pulled directly from the MCP server rather than an independently verified source. Issuer validation in the SDK only runs when an authorization-server URL has already been established. Because the fallback path left that value unset, the check did not fail. It was simply skipped. A malicious server could supply its own token endpoint while claiming the identity of a legitimate provider, and the client had no remaining checkpoint to catch the substitution.
In practice, a rogue or compromised MCP server could capture the client secret, the authorization code, and the PKCE verifier passed through that exchange, enough to mint valid access tokens carrying whatever permissions the real application had been granted. The affected version ranges were 1.9.1 through 1.29.1 on the 1.x line and 2.0.0 through 2.1.1 on the 2.x line, with fixes shipping in 1.30.0 and 2.2.0. A patch had quietly gone out on September 7, originally characterized as a behavior change rather than a security fix, with the full security advisory following three weeks later on September 28. Cycode credited eight researchers in total on the disclosure. No active exploitation has been confirmed publicly as of this writing. That is the good news, and it is also exactly the window in which a patient attacker does the most damage. Every week an organization spends not knowing whether it runs an affected SDK version is a week that window stays open.
Why This Is Not Really a Patching Story
Upgrade the SDK, and this specific hole closes. That part is straightforward, and every organization running MCP clients on the affected versions should treat it as an immediate action item, not a backlog ticket. But stop at the patch, and the actual lesson gets missed.
The vulnerability existed because the protocol’s default posture trusts a server to correctly describe its own identity provider, and only checks that description when a separate variable happens to already be populated. That is not a bug that shows up once and gets fixed. It is a category of bug, and MCP will not be the last protocol to have one, because “trust what the other side tells you about itself, verify later if convenient” is a pattern that keeps reappearing anywhere agents negotiate credentials with systems they have never met before. Kiteworks has made the same point about access control generally. When enforcement sits in a system prompt, a client library, or a configuration file that the connecting party can influence, it is not enforcement so much as a convention, one that holds only until something pushes against it.
Think about what a fully “fixed” environment still looks like the week after every client is patched. The SDK correctly validates issuers now. Your agents still connect to MCP servers you may not have a current inventory of, maintained by vendors you have not all individually audited, exchanging OAuth tokens whose scopes were set once and rarely revisited. The patch removes one specific way an attacker could have exploited that arrangement. It does not touch the arrangement itself.
The Pattern Is Bigger Than One SDK
This is not the first time an OAuth trust boundary, rather than a credential sitting somewhere unencrypted, has been the point of failure. Kiteworks documented how a third-party AI tool’s OAuth integration opened a path into Vercel’s internal systems earlier this year, where the exposure traced back to an OAuth application trusted further than its scope warranted. That incident alone would be a reasonable one-off. It is not alone. A separate incident involving OpenAI’s Codex saw authentication tokens lifted through an npm supply chain attack, with credentials sitting in plaintext storage where a compromised dependency could simply read them.
Three different products, three different vendors, one recurring shape. A credential or a trust relationship that an AI agent depended on turned out to be verifiable in theory and unverified in practice. None of these were failures of encryption strength or password complexity. They were failures of a question nobody built a mechanism to ask automatically, whether the thing on the other end of this connection is what it claims to be, right now, for this specific exchange.
Microsoft’s own research backs this up at a broader scale. Microsoft has catalogued seven distinct ways enterprise AI agents get compromised, and MCP plugin abuse and execution-container escapes sit alongside credential-layer attacks as recurring categories, not isolated curiosities. The MCP SDK flaw fits cleanly into that catalogue. It is one well-documented instance of a failure mode that keeps recurring because the underlying trust assumption keeps getting rebuilt the same way in a new codebase.
The Non-Human Identity Scale Problem
Here is why a single SDK vulnerability deserves more attention than its CVSS score suggests. Organizations now manage roughly 109 machine identities for every human identity, according to Palo Alto Networks’ 2026 Identity Security Landscape Report, based on a survey of 2,930 cybersecurity decision-makers worldwide. Machine identities are projected to grow 77 percent over the next year. AI agent identities specifically are projected to grow faster still, at 85 percent. Roughly 90 percent of surveyed organizations had already experienced at least one identity-related breach in the prior twelve months.
A vulnerability in a widely imported SDK does not threaten a handful of accounts at that scale. It threatens every agent instance built on the affected code path, across every organization that adopted MCP without a central inventory of which servers their agents talk to. Kiteworks has described this directly. Confidence in AI security dropped sharply industry-wide this year, and non-human identity governance, or the lack of it, is the reason security leaders keep citing. The MCP SDK flaw is a specific, dated, documented example of exactly that gap, not a hypothetical one.
It also exposes a quieter problem. Many enterprise AI agents are still effectively logging in as humans, authenticating through shared service accounts, long-lived static API keys, or OAuth grants that were scoped once at setup and never revisited. An agent identity that behaves like a shared human login inherits every weakness a shared human login has, plus a scale problem a human login never had, because nobody logs in 50,000 times a day. When the credential layer itself turns out to be exploitable, as the MCP SDK flaw demonstrates, an identity model that was already indistinguishable from a human account offers no additional friction to slow an attacker down.
Why Enforcement Must Move to the Data Layer
Patch the SDK. Rotate the exposed secrets. Audit the MCP servers your agents connect to and confirm each one against a known-good inventory. All of that is necessary, and none of it is optional. But none of it answers the question a regulator, an auditor, or opposing counsel will ask after an incident. Can you prove that this specific data access, by this specific agent, was authorized at the moment it happened, regardless of whether the credential presented was technically valid?
A stolen but technically valid OAuth token looks identical to a legitimate one at the authentication layer. That is precisely the point of stealing it. Credential validation answers “was this token issued correctly.” It cannot answer “should this specific request, from this specific agent, touching this specific record, be happening right now.” Those are different questions, and the MCP SDK flaw is a clean illustration of why conflating them is dangerous. Every defense in this story, up through the patched SDK, lives entirely at the authentication and authorization layer. None of it inspects what the agent does with the data once a token, stolen or legitimate, gets it through the door.
This is the argument behind entity-aware, contextual enforcement at the point data is used, rather than only at the point a credential is checked. An agent holding a valid-looking token should still be subject to a policy that asks whether this relationship, this record, and this moment make sense together, the same way a human employee’s access gets questioned when their behavior stops matching their role, not just when their password gets typed correctly. Kiteworks and Bonfy’s shared position, post-acquisition, is that the Control Plane must govern data access, use, and exchange for human and agent identities under one policy and one audit trail, rather than treating agent credentials as a separate problem to be solved purely at the OAuth layer. Kiteworks’ own secure MCP server, now listed on Anthropic’s connector marketplace, was built on exactly that premise. The connection point between an agent and sensitive content is where governance must live, not an afterthought bolted onto a protocol that was never designed to ask the question.
What CISOs and Compliance Leads Should Ask This Week
Patching the SDK is the easy part of the response. The harder, more valuable part is the set of questions this incident should put in front of every security and compliance leader managing MCP-connected agents.
Do you have a current, complete inventory of every MCP server your AI agents connect to, including ones individual teams stood up without a formal review? Most organizations do not, at least not in any single place a CISO could pull up on short notice. You cannot patch or audit a connection you do not know exists.
There is a second question worth asking alongside it: when were the OAuth scopes granted to each of those connections last reviewed, rather than just renewed automatically? A scope set broadly at initial setup and never revisited carries the same risk whether or not this specific SDK flaw ever gets exploited against it.
And a third, the one that tests whether the organization has moved past credential-layer thinking. If an agent credential were stolen tomorrow through a mechanism nobody has discovered yet, what would stop that credential from reading or moving sensitive data, beyond the hope that nobody notices the token being misused? “Nothing, because the token itself is the only thing we check” is a common honest answer, and it is the gap this incident points at.
For regulated organizations specifically, this incident also belongs in whatever evidence package already covers AI agent oversight. An auditor asking about AI governance controls six months from now is not going to be satisfied by “we patched the SDK when it came out.” They will want to see that the organization had a process for identifying affected systems, a timeline for remediation, and, ideally, controls that would have limited the damage even if the patch had landed a month later than it did. That is the artifact worth building now, while the incident is fresh and the review has an obvious trigger, rather than reconstructing it after the next one.
None of this requires waiting for a perfect inventory before acting. Start with the MCP servers that touch regulated data, whichever framework applies, PHI under HIPAA, CUI under CMMC, or customer financial records under GLBA and SOX, and work outward from there. A partial inventory built this week beats a complete one promised for next quarter, particularly given how long this specific flaw sat in production before its advisory caught up with its patch.
Frequently Asked Questions
1. Does patching the MCP Python SDK fully resolve the risk for our organization?
It resolves this specific CVE. Upgrading to version 1.30.0 or later on the 1.x line, or 2.2.0 or later on the 2.x line, closes the issuer-validation gap that made the attack possible. It does not address the broader pattern behind it. An MCP server that your agents already trust, for reasons unrelated to this flaw, still represents a credential exposure if that trust was never independently verified. Treat the patch as mandatory and immediate, and treat your MCP server inventory and OAuth scope review as the follow-up work that closes the gap that mattered. Kiteworks’ coverage of access control at the data layer goes into why credential-layer fixes alone tend to leave the underlying exposure intact.
2. Our MCP servers are internal and not exposed to the public internet. Are we still at risk?
Being internal reduces the pool of attackers who can reach the server directly, but it does not remove the risk if any MCP server in your environment, internal or external, was compromised through another vector, or if a third-party integration you rely on connects through the vulnerable SDK path on its own infrastructure. The flaw lives in how the client validates the server’s identity, not in where the server happens to be hosted. An internal server that has itself been compromised, or a vendor-managed server your agents connect to outside your network boundary, both remain viable paths for this exact exploit.
3. How is this meaningfully different from a routine OAuth or API security bug?
Most OAuth bugs involve a specific application misconfiguring a specific integration. This one lived in the reference SDK that a large share of MCP clients import directly, which means the blast radius is every application built on the vulnerable version range, not one misconfigured deployment. It is closer in shape to a flaw in a widely used cryptographic library than to a single app’s bad implementation, which is exactly why the inventory question matters more here than it would for an isolated bug in one vendor’s product.
4. What should we ask an MCP server vendor to confirm this is handled?
Ask for the specific SDK version in use and confirmation it is 1.30.0, 2.2.0, or later. Ask whether the vendor independently validates the authorization server’s issuer on every connection, rather than relying solely on the SDK’s default behavior. And ask what audit trail exists for OAuth token issuance and use on their side, so that if a credential is later found to have been misused, there is a record to investigate rather than a gap. A vendor who cannot answer the third question clearly has not closed the loop this incident opened, even if their SDK version number is current.
5. Does this vulnerability affect Claude’s MCP integrations specifically, or is it broader than that?
The flaw sits in the official Model Context Protocol Python SDK, the reference implementation used across the MCP ecosystem rather than in any single vendor’s product. Any MCP client, regardless of which AI assistant or platform it supports, that imported an affected SDK version and relied on its default OAuth handling was exposed. Kiteworks’ secure MCP server, available through Anthropic’s connector marketplace, was built with its own governance layer specifically so that credential and connection trust are not left entirely to defaults inherited from an upstream library.
To learn more about governing AI agent data access with enforcement that holds up even when a credential layer gets compromised, schedule a custom demo today.
.png)
%20(3).png?width=200&height=200&name=Bonfy-YB-Icon%20(200%20x%20200%20px)%20(3).png)