DNS rebinding and cross-origin CSRF in dynoxide's MCP HTTP transport
Exact source revision recorded 24 Oct 2026 13:19:54 UTC. It does not establish the source's current position. Latest evidence.
osv · RUSTSEC-2026-0140
Publisheddynoxide's MCP HTTP transport was vulnerable to DNS rebinding via its transitive `rmcp` dependency, plus a related cross-origin CSRF gap. A malicious web page could make the user's browser send requests to a local `dynoxide mcp --http` or `dynoxide serve --mcp` server with a non-loopback `Host` header, which the server would then process. The Host check alone did not close a related cross-origin CSRF vector: a page could `fetch` the loopback endpoint with `mode: 'no-cors'`, and the Host header would match while the Origin header went unchecked. Affected MCP write tools include `put_item`, `update_item`, `delete_item`, `create_table`, and `batch_write_item`. The stdio transport (`dynoxide mcp` without `--http`) is not affected. ## Patches dynoxide 0.9.13 closes both vectors: - Upgrades `rmcp` from 1.1.1 to 1.6.0 (which ships a default Host-header allowlist). - Sets explicit `allowed_hosts` and `allowed_origins` on `StreamableHttpServerConfig`.
- Source published
- 12 May 2026 12:00:00 UTC
- Source modified
- 12 Oct 2026 18:00:08 UTC
- Observed here
- 24 Oct 2026 13:19:54 UTC
- Source terms
- OSV · upstream source license applies
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H