All posts
mcpmcp-hangarsecurityadvisorycve

Security advisory: MCP Hangar 1.5.1 requires the CVE-2026-59950 fix

July 16, 2026MCP Hangar Team

Security advisory: MCP Hangar 1.5.1 requires the CVE-2026-59950 fix

Summary. CVE-2026-59950 (HIGH, CVSS 7.6) is a vulnerability in the upstream MCP Python SDK — not in MCP Hangar’s own code. The SDK’s WebSocket server transport accepted handshakes without validating the Host or Origin header, which opens a cross-origin / DNS-rebinding path. Credit to the MCP SDK maintainers: it is fixed in mcp 1.28.1.

Why it matters for MCP Hangar

MCP Hangar does not use the SDK’s deprecated websocket_server transport — Hangar’s WebSocket endpoints are our own implementation, with Origin validation at the gateway. The vulnerable code path is not reachable through Hangar itself.

However, our published dependency floor was mcp>=1.0.0, which meant a fresh install could still resolve a vulnerable SDK into your environment — even though our own lockfile had long moved past it. That is a supply-chain gap, not a Hangar vulnerability, and we closed it anyway.

MCP Hangar 1.5.1 raises the floor to mcp>=1.28.1, so installing Hangar guarantees the patched SDK in your dependency tree.

What to do

  • Upgrade to MCP Hangar 1.5.1: pip install --upgrade mcp-hangar
  • Or, if you can’t upgrade Hangar yet, pin the SDK directly: mcp>=1.28.1.

That’s the whole action item. There is no configuration change and no data migration.

Not using MCP Hangar?

Check whether you’re affected:

grep -rn "mcp.server.websocket\|websocket_server" .

The transport was deprecated, so most deployments don’t touch it. If nothing matches, you’re not exposed via this path. Either way, mcp>=1.28.1 is free.

What’s next

Origin validation belongs at the trust boundary, not only downstream of it. Hangar’s gateway already validates the Origin header on its WebSocket endpoints; as defense-in-depth — independent of the SDK fix — we’re extending this to Host validation with a configurable allowlist, so the edge enforces policy regardless of what any downstream SDK does. That work is tracked in the open-source repo.

Update (2026-07-19): This shipped in MCP Hangar 1.6.0. The Hangar ASGI edge now validates the WebSocket handshake before a connection reaches the SDK app: loopback is trusted, a present Origin must be allow-listed in MCP_CORS_ORIGINS (a missing one is allowed — non-browser client, auth still applies), and the Host must be in MCP_TRUSTED_HOSTS, the same allowlist the REST API uses. Non-loopback is fail-closed. See issue #498 and the public-gateway hardening recipe.

Full release notes: MCP Hangar v1.5.1.