Cycode finds an account takeover flaw in the MCP Python SDK

On Monday, September 28, Security Boulevard reported that Cycode, an application security firm, has found an account takeover vulnerability in the official Python SDK for the Model Context Protocol, the library Anthropic maintains for building MCP servers and clients in that language.

This is not a specific server published by a third party, but the foundation a large share of them are built on. That difference is what makes this news required reading for anyone running MCP servers in production.

Why a flaw in the SDK weighs more

The Python SDK is the most common way to write MCP servers in Python. Since FastMCP was merged into the official package, spinning up a server with a few decorated functions takes minutes, and that has multiplied the number of projects that depend on it, either directly or through other agent frameworks.

When the vulnerability lives in the SDK, every server built on the affected component inherits it without its author writing a single faulty line. And an account takeover, by definition, touches the identity layer: who the user on the other end is and what credentials the server handles on their behalf. In MCP that layer is especially sensitive, because the protocol specification bases authorization for remote servers on OAuth 2.1, and those servers often hold tokens with access to repositories, CRMs, databases or email inboxes.

For the technical details of the finding, go to the original piece and cross-check it with the security advisories in the official repository, which is where the affected versions and the fix are documented.

Not the first warning in the ecosystem

MCP turns two in November, and the list of findings grows as fast as its adoption. During 2025, Oligo Security documented a remote code execution flaw in MCP Inspector, the official debugging tool, and JFrog did the same with mcp-remote, a widely used proxy for connecting local clients to remote servers. The pattern repeats: pieces designed as auxiliary infrastructure that end up exposed in contexts they were never built for.

The difference here is the layer. This is not a development utility, but the code the servers themselves run on.

Who is affected and what to check

Until the exact scope is clear for each deployment, the most exposed profile is teams publishing remote MCP servers over HTTP with user authentication, especially multi-user ones. A local stdio server used by one person on their own machine has a different risk profile, although it should be updated too.

This is what we would do today:

1. Inventory where the `mcp` package shows up. Check lockfiles (`uv.lock`, `poetry.lock`, `requirements.txt`) and transitive dependencies, because many frameworks pull it in without it appearing in the main manifest.
2. Upgrade to the fixed version named in the official advisory and redeploy. Changing the lockfile without restarting the service fixes nothing.
3. If the server was exposed to the internet, revoke and rotate the OAuth tokens and third-party credentials it holds.
4. Review authentication logs for sessions or token issuance that do not match normal usage.
5. In Claude Code, run `claude mcp list` to see which servers are configured and remove the ones no longer in use. Every forgotten server is one more thing to patch.

The price of simplicity

MCP caught on because connecting a model to an external tool is easy. That same ease means many servers reach production with the SDK's default configuration and no security review of their own. When the flaw sits in the shared library, the impact lands on everyone at once, and response speed depends on knowing what you have deployed.

At ElephantPink we treat every MCP server as just another public API: pinned dependencies, active security alerts and short-lived tokens. It does not stop flaws like this from appearing, but it turns the response into an afternoon of work instead of a week.