On 28 September 2026 the MCP project published a security advisory for its Python SDK, and on 30 September one of the same kind for its TypeScript SDK: a malicious MCP server could point the client to a token address of its own and receive the OAuth credentials the client uses for a real service. MCP (Model Context Protocol) is the open standard an AI assistant uses to connect to external tools and data. If someone proposes connecting one to your business system, your CRM or an API, ask whoever builds it which SDK it uses, at which version and with which permissions.
What happened
An MCP client that connects to a server asks it where the login service is. In the affected versions the SDK did not always check the answer, and did not tie stored credentials to the service they belonged to. A malicious or compromised server could therefore point the client to a token address of its own and receive the client secret, the authorization code and the PKCE verifier. Cycode (analysis of 28 September) showed that with these values an attacker obtains a valid token from the real service.
- The Python SDK (package
mcp) is affected from 1.9.1 to 1.29.1 and from 2.0.0 to 2.1.1, and is fixed in 1.30.0 and 2.2.0. - The TypeScript SDK is affected in
@modelcontextprotocol/sdkfrom 1.12.0 to 1.30.1 (fixed in 1.31.0) and, in some configurations, in@modelcontextprotocol/clientfrom 2.0.0 to 2.1.0 (fixed in 2.2.0). - Severity is high, CVSS 7.5. Neither the advisories nor Cycode report real attacks.
Who is affected
The affected clients are MCP clients written with either SDK that use HTTP and OAuth and can connect to servers that are not fully trusted, while holding credentials for a real login service. Servers built with the SDKs and local clients that use stdio are not affected by this flaw.
Providers that use pre-provisioned credentials, two in Python (ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider) and four in TypeScript, have to be configured with the expected login service after the update: issuer in Python, expectedIssuer in TypeScript. Without this setting they behave as before, and in Python SDK 1.30.0 leaving it out only produces a deprecation warning that Python hides by default. Credentials stored before the update have to be cleared.
Two other cases
- According to Pillar Security, on 10 August a single GitHub account opened 23 pull requests on AI, MCP and developer-tool projects to get an MCP server called productivity-suite added. The server offers two harmless tools and, from the third call, changes the instructions it passes to the assistant to steer it towards SSH keys, AWS credentials, shell history and Kubernetes configuration, hiding this from the user; a quick inspection sees only the two harmless tools. On 12 August 19 pull requests were closed, 4 were open and none had been merged.
- A study by an independent researcher on arXiv (31 July) confirmed 640 MCP servers reachable from the internet and audited 414: 91.8% of those did not use OAuth, in the great majority of cases because they had no authentication or used a static token. Among the 640 it counted 687 tools that offer shell command execution without asking for credentials.
What to expose from your business system
An AI assistant connected to your business system acts as one more user, with the credentials you give it. This is our starting point for deciding in advance what it can see and what it can do.
| What | How to expose it | Why |
|---|---|---|
| Reads (customer records, orders) | Read-only, with filters | The risk is a data leak |
| Writes (quotes, invoices) | Denied by default, enabled one by one | A mistake costs money |
| Irreversible actions | Only with a person's confirmation | Deleting or sending cannot be undone |
| Credentials | One technical user per assistant, minimum permissions | It can be revoked without touching people |
| The server's tools | Compared at every connection | They can change after approval |
| Log | Who did what, with which assistant | You need it to reconstruct an incident |
If the business system is exposed through a server written with the Python SDK, the advisory of 5 October says that after the update the check on who a token was issued for stays off: it has to be switched on with validate_token_resource, otherwise the server also accepts tokens that the same login service issues for other services.
What to do this week
- List where an AI assistant or a development tool already has access to your systems, including employees' trials.
- Ask whoever builds an MCP client which version it uses (Python 1.30.0 or 2.2.0, TypeScript 1.31.0 or 2.2.0, or later) and whether
issuerorexpectedIssueris set. - Ask the vendor which tools the assistant sees, which user it signs in to your system as and where the log of its actions ends up; if the server uses the Python SDK, ask whether
validate_token_resourceis on. - If a client may have connected to an unverified server, change the client secret and revoke the tokens.
- Connect assistants only to MCP servers you know: one proposed in a pull request or found in a public directory is not a trusted server.
What we check first
An assistant connected to a business system touches two of our services: AI automation and chatbots, where we integrate language models into existing workflows with control over cost and answer quality, and internal platforms and cloud software, where we design multi-user platforms with roles, granular permissions and integration with the systems already in use.
If you ask us to look at a connection like this, we start from four things: the SDK version and the login service set in the client, the user the assistant signs in as and its permissions, the tools it sees, and the log of its actions. For a new connection we propose starting read-only and adding writes one at a time, with analysis, quote and roadmap agreed before we start. We cannot vouch for the behaviour of a third-party server, so we keep permissions on the business-system side: a server that changes after approval can only do what the technical user can do.
What we do not know yet
- Whether there has been real abuse: the advisories and Cycode report none, but these sources cannot rule it out.
- Which commercial products use vulnerable versions of the SDKs: the sources do not say, so ask the individual vendors.
- How much weight to give the study of exposed servers: it has a single author, who writes that independent checks would be needed.
If you want us to look at the connection between an AI assistant and your business system, write to us or start from the page on AI automation and chatbots.
Sources
- GitHub, Python SDK: advisory GHSA-qx49-fqc8-xw99 (28 September 2026)
- GitHub, TypeScript SDK: advisory GHSA-6qxp-vccf-f47h (30 September 2026)
- Cycode: analysis of the Python SDK OAuth flaw (28 September 2026)
- GitHub, Python SDK: release notes for 1.30.0
- GitHub, Python SDK: release notes for 2.2.0
- Pillar Security: report on the Deadbugz campaign (12 August 2026)
- arXiv: Exposed by Design, a study of exposed MCP servers (31 July 2026)
- GitHub, Python SDK: advisory GHSA-w4fh-qvv9-3v23 (5 October 2026)
