{
  "entry": {
    "kind": "vuln",
    "slug": "cve-2026-63127",
    "name": "CVE-2026-63127",
    "vendor": "Python `mcp`",
    "description": "The Model Context Protocol reference SDKs published four client-side advisories between 28 September and 2 October 2026, none with a CVE and all scoped to their repositories rather than the global GitHub Advisory Database, so `npm audit` and OSV-backed scanners did not flag them at publication. GHSA-qx49-fqc8-xw99 (Python `mcp`, 28 September, high, CVSS 7.5): the OAuth client did not validate the authorization server `issuer` on every discovery path and did not bind stored or pre-provisioned client credentials to their authorization server, so a malicious or compromised MCP server could direct the client_secret, authorization code and PKCE verifier (or a signed client assertion) to a token endpoint of its choosing. GHSA-6prh-2h8m-c8cw (TypeScript, 2 October, medium 6.5) and GHSA-5h93-6whr-6q8j (Python, 2 October, medium 5.9): HTTP client transports followed cross-origin redirects and re-sent custom headers such as X-API-Key and mcp-session-id, plus the body on 307/308, including OAuth token requests carrying refresh_token and client_secret. GHSA-22jm-h49p-29qw (TypeScript, 2 October, high 8.6): the deprecated experimental task store did not tie tasks to the session that created them, so clients sharing one InMemoryTaskStore could list, read and cancel each other's tasks. The Rust SDK's comparable OAuth flaw, CVE-2026-63127 (rmcp before 2.0.0, missing RFC 9728 resource check, CVSS 8.2), was published by NVD on 16 September.",
    "website": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-qx49-fqc8-xw99",
    "repository": null,
    "documentationUrl": null,
    "license": null,
    "version": null,
    "trustLevel": "advisory",
    "capabilities": [],
    "packaging": null,
    "configFiles": null,
    "category": "mcp-server",
    "updatedAt": "2026-09-28",
    "risk": {
      "score": 82,
      "band": "high",
      "signals": [],
      "dangerousCombos": []
    },
    "dangerousCombos": [],
    "vuln": {
      "id": "CVE-2026-63127",
      "aliases": [
        "ti-113",
        "GHSA-qx49-fqc8-xw99"
      ],
      "title": "MCP Reference SDKs: A Malicious Server Could Pick Where the Python OAuth Client Sent Its Secrets, and Both SDKs Re-Sent Headers Across Redirects",
      "summary": "The Model Context Protocol reference SDKs published four client-side advisories between 28 September and 2 October 2026, none with a CVE and all scoped to their repositories rather than the global GitHub Advisory Database, so `npm audit` and OSV-backed scanners did not flag them at publication. GHSA-qx49-fqc8-xw99 (Python `mcp`, 28 September, high, CVSS 7.5): the OAuth client did not validate the authorization server `issuer` on every discovery path and did not bind stored or pre-provisioned client credentials to their authorization server, so a malicious or compromised MCP server could direct the client_secret, authorization code and PKCE verifier (or a signed client assertion) to a token endpoint of its choosing. GHSA-6prh-2h8m-c8cw (TypeScript, 2 October, medium 6.5) and GHSA-5h93-6whr-6q8j (Python, 2 October, medium 5.9): HTTP client transports followed cross-origin redirects and re-sent custom headers such as X-API-Key and mcp-session-id, plus the body on 307/308, including OAuth token requests carrying refresh_token and client_secret. GHSA-22jm-h49p-29qw (TypeScript, 2 October, high 8.6): the deprecated experimental task store did not tie tasks to the session that created them, so clients sharing one InMemoryTaskStore could list, read and cancel each other's tasks. The Rust SDK's comparable OAuth flaw, CVE-2026-63127 (rmcp before 2.0.0, missing RFC 9728 resource check, CVSS 8.2), was published by NVD on 16 September.",
      "severity": "high",
      "cvss": {
        "score": 8.2,
        "vector": null,
        "version": null
      },
      "cwe": [],
      "attackType": [
        "Credential theft"
      ],
      "componentType": "mcp-server",
      "component": {
        "name": "Python `mcp`",
        "vendor": null,
        "package": null,
        "ecosystem": null,
        "catalogSlug": null
      },
      "affected": [
        {
          "range": "Python `mcp` 1.9.1 to 1.29.1 and 2.0.0 to 2.1.1 (OAuth issuer, fixed 1.30.0 / 2.2.0); `mcp` 1.8.0 to 1.29.1 and 2.0.0 to 2.1.1 (redirects, fixed 1.30.0 / 2.2.0). @modelcontextprotocol/sdk < 1.32.0 and @modelcontextprotocol/client 2.0.0 to 2.2.0 (redirects, fixed 1.32.0 / 2.3.0); @modelcontextprotocol/sdk 1.24.0 to 1.31.0 (task store, fixed 1.32.0). Client-side only: servers and stdio clients are not affected by the OAuth and redirect issues. rmcp < 2.0.0 (CVE-2026-63127).",
          "fixed": "1.30.0"
        }
      ],
      "exploited": false,
      "exploitPublic": false,
      "publishedAt": "2026-09-28",
      "modifiedAt": "2026-09-28",
      "lastVerified": "2026-11-01",
      "references": [
        {
          "type": "advisory",
          "url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-qx49-fqc8-xw99"
        },
        {
          "type": "cve",
          "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63127"
        }
      ],
      "mitigation": "Upgrade MCP clients and agent harnesses built on the SDKs: Python `mcp` to 1.30.0 or 2.2.0, @modelcontextprotocol/sdk to 1.32.0, @modelcontextprotocol/client to 2.3.0, rmcp to 2.0.0 or later. On the Python side, upgrading alone does not protect ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider: pass `issuer=` explicitly, and clear stored client registrations once so they are re-created bound to an issuer. Do not restore the old behaviour with redirectPolicy: 'follow' or follow_redirects=True on an MCP transport; point the endpoint at the redirect target instead. Grep for taskStore and stop using the deprecated experimental tasks. If an OAuth-enabled client may have connected to an untrusted MCP server or a redirecting endpoint, rotate its client secret and API keys and revoke its tokens. Track these repositories' own security-advisories pages, because a clean SCA scan does not cover them.",
      "detectedByAnomity": true
    }
  }
}