security: MCP HTTP transport sets Access-Control-Allow-Origin: * with no Origin validation

[jrosskopf]

Surfaced while reviewing MCP transports across DataZoo repos (flAPI MCP overhaul, DataZooDE/flapi#107).

src/mcp/mcp_http_server.cpp (~line 75) sets Access-Control-Allow-Origin: * and never validates the Origin header on the POST /mcp transport. This is the DNS-rebinding / CSRF shape the MCP transport spec has warned about since 2025-03-26, and it is more serious here because the endpoint executes writes against a production SAP system (adt_write_source, adt_delete_object, bw_save_object).

Recommended fix (independent of any protocol-version work):

• Validate Origin against an allowlist; return 403 on mismatch.
• Default the allowlist to the embedded web UI's origin.

Reference: MCP 2026-07-28 Streamable HTTP transport security section.

[sattyamjjain]

Confirming the shape from the other side. Same class as CVE-2026-11624, Google MCP Toolbox for Databases < 0.25.0, CWE-346, and it maps to OWASP MCP Top-10 MCP07. Their fix is a good template: --allowed-origins plus a separate --allowed-hosts, with a warning when either is *.

Two things I would add to your recommendation:

Validate Host always, not only Origin. A rebinding request from a browser carries a Host you control the DNS for and frequently no Origin at all, so an Origin-only check waves it straight through.

Default to loopback-only when nothing is configured, rather than to *. Failing closed on an unconfigured deployment is what protects the self-hosters who never read the flag, and they are most of the exposure.

Since you are doing this across DataZoo repos by hand, the wildcard-CORS and DNS-rebinding checks are already rules in a scanner I maintain. MIT, runs offline, emits SARIF, works as a GitHub Action: https://github.com/sattyamjjain/agent-audit-kit

[jrosskopf]

Host validation landed in #55 (merged). Keeping this open, because it is opt-in — details below.

The comment above is right, and I confirmed it against the released build before changing anything. Origin validation (shipped in v2026.08.31) does not see DNS rebinding: once evil.example points rebind.evil.example at 127.0.0.1, the browser treats the call as same-origin, and both shapes were answered 200:

POST /mcp  Host: rebind.evil.example  Origin: http://rebind.evil.example  → 200
POST /mcp  Host: rebind.evil.example  (no Origin)                         → 200

The first passed the same-origin rule — which proves nothing when the attacker owns both sides of the comparison — and the second passed the no-Origin rule.

What #55 adds. The Host header is now classified on its own, before Origin: loopback names and IP literals always pass (an IP address has no name to rebind, so --host 0.0.0.0 reached at a LAN address is unaffected), as do the bound address and anything named by the new --allowed-hosts. Any other DNS name is Unrecognised.

with --allowed-hosts:   rebound Host + matching Origin  → 403
                        rebound Host, no Origin         → 403
                        loopback / IP literal / named   → 200

Why it stays open. On the second recommendation — defaulting to closed — we went the other way for now: --allowed-hosts is what turns refusal on, and without it an unrecognised Host is still served, with one warning per distinct host on stderr. That keeps every deployment reached through a DNS name or a reverse proxy working across the upgrade, but it does mean the rebinding path above is still reachable in the default configuration. Closing this issue should wait until that default flips, which is a separate call about breaking existing setups.

Thanks for the CVE-2026-11624 / MCP07 pointer — the Toolbox split of --allowed-origins and --allowed-hosts is the shape #55 follows.