←Security
Security posture

MCP ecosystem CVE ledger

Published CVEs in the MCP ecosystem that matter to anyone running MCP servers behind Hangar — what each one is, and whether Hangar's controls relate to it. Including when they do not.

Updated August 9, 2026

MCP ecosystem CVE ledger

An evergreen record of published CVEs in the Model Context Protocol ecosystem — the protocol SDKs and the servers people run — with one entry per CVE and one anchor per entry, so an advisory can be deep-linked from an issue, a ticket, or a scanner note.

Each entry says three things: what the vulnerability is, what it affects, and how Hangar’s controls relate to it — including the cases where the honest answer is they do not. Hangar is a policy enforcement plane. It enforces deterministic policy on calls that pass through it and records what happened; it does not patch someone else’s code, and it cannot enforce on a connection that never reaches it.

This ledger is a pointer, not a replacement: every entry links to the upstream advisory, and where Hangar published a full write-up, to that too.

CVE-2026-59950

Missing Host and Origin validation in the deprecated websocket_server transport of the upstream MCP Python SDK. CVSS 7.6 (HIGH), CWE-346 (Origin Validation Error). Because browsers do not apply the same-origin policy to WebSocket connections, a malicious page could complete a handshake against a local MCP server and drive it as the user — a cross-site WebSocket hijacking (CSWSH) path, with DNS rebinding as a variant.

Affected componentMCP Python SDK (mcp) — the deprecated websocket_server transport
Affected versionsmcp before 1.28.1
Fixed inmcp 1.28.1
SeverityCVSS 7.6 — HIGH
In Hangar’s own codeNo

Credit to the MCP Python SDK maintainers, who shipped the fix in mcp 1.28.1.

How Hangar’s controls relate

This was a supply-chain gap in a dependency, not a vulnerability in Hangar’s own code. Hangar has never used the SDK’s deprecated websocket_server transport — its own WebSocket endpoints are a separate implementation — so the vulnerable code path was not reachable through Hangar. What was wrong is that Hangar’s published dependency floor read mcp>=1.0.0, which meant a fresh install could still resolve a vulnerable SDK into your environment. MCP Hangar 1.5.1 raised the floor to mcp>=1.28.1, and 1.6.0 added handshake validation at Hangar’s own ASGI edge as defence in depth. The full advisory has the detail and the upgrade steps.

Where it does not help. If you run an MCP server that uses the SDK’s websocket_server transport and something can reach that server directly, a Hangar policy does not mitigate this CVE. Enforcement applies to calls that pass through the enforcement plane; a browser-originated handshake that goes straight to the server never enters that path, so no allow/deny rule, egress policy, or approval gate is consulted. Neither does default-deny egress in a governed namespace help here — the attack rides the connection it just opened. Patch the SDK. There is no Hangar setting that substitutes for mcp>=1.28.1.

How this ledger is kept

One ## heading per CVE, newest first, with the CVE id as the whole heading — that is what makes #cve-2026-59950 a stable anchor. Each block is self-contained: heading, a short factual paragraph, the affected component and versions, how Hangar’s controls relate, then links. Adding an entry means adding one block to src/content/security/cve-ledger.mdx and nothing else.

Entries are listed when they are relevant to running MCP servers under an enforcement plane. A CVE with no Hangar relationship still gets an entry that says so, because “we do not mitigate this” is the useful sentence.