Six MCP CVEs in 36 hours, all the same three missing boundaries, and half of registered servers changed what they advertise

Between September 14 and September 15, NVD published seven entries hitting MCP infrastructure. I read all of them expecting to find something clever. There's nothing clever in any of them.

CVE-2026-57124, 9.8, published September 14. PraisonAI's default UI exposes POST /api/mcp/connect with no mandatory authentication and passes a caller-controlled command and args straight to StdioMCPClient, which starts a local process. The UI binds 0.0.0.0 by default, so any reachable client runs commands as the UI service account even when the MCP handshake later fails. Fixed in 4.6.59 (NVD).

CVE-2026-57139, also 9.8, published September 15. PraisonAI again. MCPServer.startHttp() binds with no host restriction and forwards every HTTP POST to handleRequest() with no authentication, so any network client calls tools/list, tools/call, resources/read or prompts/get with server-side credentials. Fixed in 1.7.2 (NVD).

CVE-2026-57134, 8.2. MCPSecurity.evaluatePolicy() only calls the credential validator for api-key and bearer. Basic and OAuth policies accept any non-empty Authorization header and return an authenticated result without calling auth.validate(). That's worse than no auth, because a config review sees an authenticated MCP surface that isn't one.

CVE-2026-73496, 7.7. MCP Atlassian's Confluence upload tools pass a client-controlled file_path to upload_attachment with no workspace confinement, so on a remote or multi-tenant deployment a traversing path reads server files and posts them to Atlassian. Fixed in 0.22.0.

CVE-2026-73497 and CVE-2026-53708, 6.5 and 6.6, same root cause in two unrelated projects: validate a hostname, throw away the resolved address, reconnect by name. DNS rebinding wins. ContextForge's /admin/gateways/test rejects private, loopback, link-local and metadata addresses at validation time, then ResilientHttpClient re-resolves the original hostname without binding the validated address (NVD).

Three mistakes, four repeats. Binding 0.0.0.0 with no auth. Passing a caller-controlled path or command to the OS. Validating a hostname then re-resolving it.

Audit those three things and you catch this entire batch. That's a morning of work, not a quarter.

Now the part that makes the CVE list look like a symptom. A census of the full public MCP registry went up September 14: 21,643 servers, 72,606 version records, source fetched for 14,353 of them and scanned against an eight-class threat catalogue calibrated on 414 hand-labeled findings (arXiv 2609.14119).

51.1% of multi-version servers changed their advertised surface between versions. 40.6% did it silently. And 4.2% redirected their remote endpoint to a different host while keeping their registry identity, a change the protocol never surfaces to installed clients.

Silent drift carries 2.96x the odds of a high-severity finding (95% CI [2.56, 3.42]). Star count barely protects you at all: OR 0.78 per log star.

Read that 4.2% again. One server in twenty-four pointed somewhere else and your client didn't tell you. You pinned a version, the version stayed the same, the destination moved.

A second paper explains the supply side. A longitudinal study of 802 MCP publications and 33,319 repos found research and adoption peaked together in March 2026, and that 57.8% of publications plus 93.7% of repositories treat MCP as plumbing to consume rather than something to analyze, evaluate, extend or secure (arXiv 2609.14721). Almost nobody is working on the hygiene layer. That's why the registry looks like this.

We solved version drift in package management with lockfiles that pin content hashes, not names. MCP pins names.

---