GHSA-84m7-p3x7-pcfv: High severity pip/mcp vulnerability

Published Oct 15, 2026
·
Updated

Summary In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:

- sessions did not expire; - a client DELETE ended the session but left its entry registered; - a session whose first request was refused stayed registered with a running task.

Each session also kept its parsed initialize parameters, and the number of sessions was unlimited. A client that could reach the endpoint could grow server memory without bound using ordinary short requests; only a restart reclaimed it.

Am I affected? Yes, if you serve MCP over Streamable HTTP in stateful mode and clients you do not fully trust can reach the endpoint. Stateful mode is the default for:

- FastMCP (1.x) - MCPServer and Server.streamablehttpapp() (2.x) - StreamableHTTPSessionManager

Affected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.

Not affected:

- servers on 1.12.0 or later passing statelesshttp=True (no sessions are kept) - servers using only the stdio or SSE transports

Authentication limits who can open sessions, not how many a token holder can open.

Fix Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:

- a session with no request in flight for sessionidletimeout seconds (default 1800) is closed and its ID then answers 404; open streams and in-progress requests keep it alive; - at most maxsessions sessions exist at once (default 10000); a request that would open another is answered 503; - a session is discarded as soon as it ends, whether by DELETE, expiry, or a refused opening request.

Both settings are keyword arguments on FastMCP(...) (1.x), MCPServer.run() / streamablehttpapp() (2.x) and StreamableHTTPSessionManager; None disables them.

This bounds retention rather than eliminating it: a live session still holds its initialize parameters (up to roughly twice the 4 MiB body limit), and an initialize with invalid parameters still opens a session that expires like any other. On a small host, lower sessionidletimeout, maxsessions and maxrequestbodysize to fit.

If you cannot upgrade yet, pass statelesshttp=True (1.12.0 or later) where you need no per-session state, or restrict who can reach the endpoint.

Affected Software

2 affected componentsFixes available
pip/mcp>=2.0.0<2.2.0
2.2.0
pip/mcp>=1.8.0<1.30.0
1.30.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/mcp to a version that resolves this vulnerability.

    Fixed in 2.2.0
  2. Upgrade

    Upgrade pip/mcp to a version that resolves this vulnerability.

    Fixed in 1.30.0
  3. Upgrade

    Upgrade mcp to a version that resolves this vulnerability.

    Fixed in 1.30.0
  4. Upgrade

    Upgrade mcp to a version that resolves this vulnerability.

    Fixed in 2.2.0
  5. Configuration

    For mcp 1.12.0 or later, enable stateless_http=True where per-session state is not required.

    Streamable HTTP server stateless_http = true
  6. Configuration

    Lower session_idle_timeout, max_sessions, and max_request_body_size to fit the host; the stated defaults are 1800 seconds for session_idle_timeout and 10000 for max_sessions.

    Streamable HTTP server session_idle_timeout, max_sessions, max_request_body_size = lower values appropriate for the host
  7. Compensating control

    Restrict which clients can reach the Streamable HTTP endpoint.

Event History

Oct 15, 2026
Advisory Published
via GitHub·08:13 PM
Data Sourced
via GitHub·08:13 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed to this issue?

Deployments serving MCP over Streamable HTTP in stateful mode are exposed when clients that are not fully trusted can reach the endpoint. Stateful mode is the default for FastMCP 1.x, MCPServer and Server.streamable_http_app() in 2.x, and StreamableHTTPSessionManager.

2

Which mcp versions need remediation?

Affected releases are mcp 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1. Upgrade to 1.30.0 or 2.2.0, respectively, or a later release.

3

Does requiring authentication prevent exploitation?

No. Authentication restricts who can open sessions, but it does not limit the number of sessions a token holder can create.

4

What can be done if an immediate upgrade is not possible?

On version 1.12.0 or later, passing stateless_http=True avoids retaining sessions. Deployments using only the stdio or SSE transports are not affected.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203