Back to blog

MCP Python SDK token validation: a patched package still needs the right setting

2 min read
MCP Python SDK token validation: a patched package still needs the right setting

Sources checked: . FailSafe Research.

A valid token can still be the wrong token for a service. The MCP Python SDK advisory GHSA-w4fh-qvv9-3v23 describes bearer authentication accepting tokens intended for another resource server under affected configurations. The important operational detail is that installing a fixed package does not, on its own, turn on the new resource validation.

Identify the deployed authentication path

The advisory lists affected mcp versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1. It identifies fixes in 1.30.0 and 2.2.0. Applicability also depends on how the server verifies tokens and whether its authorization server issues tokens for other services.

Ask the application owner for the running package evidence, server configuration and verifier behavior. An infrastructure inventory alone may identify the library while missing the custom authentication code that determines exposure.

Read the configuration instructions together

The maintainer says the added resource-validation setting is initially off. Its instructions connect the expected resource-server audience with the resource returned by the verifier. Follow the complete advisory for the deployed release, including the case where a verifier already enforces audience checks independently.

Avoid changing a single setting in isolation and assuming the job is done. Document what the authorization service issues and what the resource server actually expects. Store only sanitized configuration evidence in an assessment report.

Prove rejection as well as acceptance

A useful controlled test has two halves. The intended service credential should permit the expected operation. A synthetic credential intended for a different test resource should be rejected. Use your own test identity provider and approved accounts; there is no reason to collect production tokens from other services.

Include a check that legitimate users still complete their normal workflow. Security closure that silently disables the application creates a different operational incident. Record the package and configuration used for each result.

Follow the permission boundary into the tool

Audience validation answers which service may accept a token. The tool still needs to decide which objects and actions that identity may access. Treat resource selection and tool authorization as separate findings when they fail independently.

FailSafe can scope MCP security testing around that composed boundary. The existing audience-validation guide covers the general test design; this article addresses the particular upgrade-and-configuration decision raised by the advisory. SDK maintenance remains the application owner's responsibility.

Source review, 2 November 2026: Maintainer advisory GHSA-w4fh-qvv9-3v23. Check the advisory again when deploying a later release.

Questions & answers

Questions about this topic

Direct answers to common questions about this page.

The maintainer explicitly says upgrading alone does not enable the new check. Review the complete resource-validation and verifier instructions for your configuration.

No. A credential intended for the service can still request an object or action that its identity is not allowed to use.

Put this guidance to work

Bring your deployed MCP identity and tool configuration into an assessment that connects credential acceptance to the operation the resource actually permits.

Startup offer: $999 USD for 250 credits and one authorized black-box run. Sign in to SWARM before Stripe checkout. Custom scope and sovereign deployments are separate.

Review MCP assessment scope