The security fix you have to switch on

The official Python SDK for Model Context Protocol published three advisories on the same day, one fix release on each of its two branches, and a sentence that should change how you read every changelog: upgrading alone changes nothing. It sits under the one flaw of the three that guards the front door of an MCP server.

Three decisions nobody made

Read the three side by side and the bugs are not the interesting part. The interesting part is who decided. A client validating tool results asked a JSON Schema library to resolve references, and the library's default answer was to open whatever URL the server named, including local files. The HTTP transports switched on redirect following for convenience, and a credential header went wherever the redirect pointed. The server's token check was handed to whoever wrote the verifier, and nothing asked that person whether the token was even meant for this server.

None of that is exotic. It is what happens when a protocol's security decisions are made inside an SDK, one library default at a time. You can build on MCP without ever reading the specification. You read the quickstart, and the SDK's defaults become the protocol you actually run.

The server's metadata is an input

The schema flaw deserves its own line, because it inverts the usual picture. We tend to think of a tool's description and schema as configuration, something the client consults. Here the client treated it as instructions to follow: go and fetch this. A malicious server did not need a prompt injection or a confused model. It only needed to declare a tool. Everything a server sends is input, including the parts that look like documentation.

A version number is not a security state

Two of the fixes close when the package moves. The audience fix does not, and for a reason that is defensible: turning it on breaks any verifier that does not report the token's audience, so the maintainers made it opt-in and scheduled the default for the next major release. This is what a server that upgraded and changed nothing gets instead of the check:

`AuthSettings.validate_token_resource` is not set, so bearer
tokens are not checked against `resource_server_url`; it will
default to True in 3.0 when `resource_server_url` is set.

That is honest, and it is a warning written for a developer reading a console. Your dependency scanner reads version numbers. It will mark the package fixed, the ticket will close, and a server that accepts tokens minted for your other services will keep accepting them. Not because anyone skipped the patch, but because the patch is a setting and nobody owns the setting.

Trust is the attack surface

An SDK feels like plumbing, and plumbing feels safe to inherit. It is the opposite: it is where the trust decisions of a protocol are actually taken, quietly, by defaults. Three of them were wrong this week. Two were corrected for you. One was corrected and left for you to switch on.

What to actually do

• Upgrade the mcp package on every client and server. That closes the redirect and schema flaws with no code change.
• Then open every place you build AuthSettings. Either turn on validate_token_resource and make your verifier return the audience, or confirm your verifier already rejects a token whose aud is not your server. Doing neither leaves the flaw open on the new version.
• Treat a DeprecationWarning from an auth library as a finding. Make warnings visible in CI, and fail the build on the ones that come from security settings.
• Stop following redirects you did not plan for. If a client reached its server through a redirect to another host, point it at the real endpoint and rotate whatever credentials it carried while it was following.
• Read tool schemas as untrusted data. Any code that resolves, renders or acts on what an MCP server declares about itself should behave as if the server were hostile, because sometimes it is.