GHSA-W4FH-QVV9-3V23

Vulnerability from github – Published: 2026-10-27 21:06 – Updated: 2026-10-27 21:07
VLAI
Summary
Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server
Details

Summary

In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.

Am I affected?

Yes, if your HTTP server uses the SDK's bearer authentication (auth=AuthSettings(...) with token_verifier=), its authorization server also issues tokens for other services, and your TokenVerifier does not check the token's audience (aud) itself.

Affected versions:

  • mcp 1.10.0 through 1.29.1
  • mcp 2.0.0 through 2.1.1

Fix

Upgrade to:

  • 1.x: mcp 1.30.0 or later
  • 2.x: mcp 2.2.0 or later

Upgrading alone changes nothing. The patched versions add a validate_token_resource setting that is off unless you set it. To turn the check on, make both of these changes together:

  1. Set validate_token_resource=True in AuthSettings, with resource_server_url set to the audience your authorization server puts in tokens for your server.
  2. Return the token's audience from verify_token() as AccessToken.resource.

A token for another service then gets 401. With only the first change, every request gets 401.

If your TokenVerifier already checks the audience, set validate_token_resource=False to silence the deprecation warning. The setting will default to True in 3.0.

If you cannot upgrade yet, reject any token whose aud does not include your server inside verify_token(). That closes the issue on every version.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-116684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-27T21:06:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nIn affected versions, the SDK\u0027s server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.\n\n### Am I affected?\nYes, if your HTTP server uses the SDK\u0027s bearer authentication (`auth=AuthSettings(...)` with `token_verifier=`), its authorization server also issues tokens for other services, and your `TokenVerifier` does not check the token\u0027s audience (`aud`) itself.\n\nAffected versions:\n\n- `mcp` 1.10.0 through 1.29.1\n- `mcp` 2.0.0 through 2.1.1\n\n### Fix\nUpgrade to:\n\n- 1.x: `mcp` 1.30.0 or later\n- 2.x: `mcp` 2.2.0 or later\n\n**Upgrading alone changes nothing.** The patched versions add a `validate_token_resource` setting that is off unless you set it. To turn the check on, make both of these changes together:\n\n1. Set `validate_token_resource=True` in `AuthSettings`, with `resource_server_url` set to the audience your authorization server puts in tokens for your server.\n2. Return the token\u0027s audience from `verify_token()` as `AccessToken.resource`.\n\nA token for another service then gets `401`. With only the first change, every request gets `401`.\n\nIf your `TokenVerifier` already checks the audience, set `validate_token_resource=False` to silence the deprecation warning. The setting will default to `True` in 3.0.\n\nIf you cannot upgrade yet, reject any token whose `aud` does not include your server inside `verify_token()`. That closes the issue on every version.",
  "id": "GHSA-w4fh-qvv9-3v23",
  "modified": "2026-10-27T21:07:00Z",
  "published": "2026-10-27T21:06:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-w4fh-qvv9-3v23"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/pull/3447"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/pull/3451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/commit/0c9136841ff092987a20700ff9c2c9789bda2f40"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/commit/8c2fa6eabacde869d75568e33b9d466b58c2f512"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/python-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.