RustSec flags dynoxide-rs DNS rebinding flaw in MCP HTTP server

What happens when a browser session can reach into a Rust developer’s localhost MCP server? RustSec answered that question with a high-severity advisory on May 13, flagging dynoxide-rs for DNS rebinding and cross-origin CSRF in its MCP HTTP transport.

The affected range ran from dynoxide-rs 0.9.3 through 0.9.12. The stdio transport was not affected, which matters because dynoxide’s default MCP mode without http stayed outside the blast radius. The problem sat in the HTTP-based server path, where a malicious web page could coerce a browser into sending requests to a local dynoxide MCP server with a non-loopback Host header, and the server would still process them. RustSec also noted that Host validation alone was not enough, because a hostile page could fetch the loopback endpoint with mode: 'no-cors', leaving the Origin header check as the missing line of defense.

This was not a theoretical nuisance. The advisory tied the flaw to write-side MCP tools including put_item, update_item, delete_item, create_table, and batch_write_item. If a developer had dynoxide’s HTTP server running and visited a hostile page, browser-mediated requests could have written to the local service in ways the user never intended. RustSec assigned the issue CVE-2026-42559 and GHSA-fvh2-gm75-j4j7, underscoring how quickly a localhost helper can turn into a browser-to-machine bridge when the trust model is wrong.

Dynoxide 0.9.13, released May 11, closed the gap by upgrading rmcp from 1.1.1 to 1.6.0 in both lockfiles and by setting explicit allowed_hosts and allowed_origins on StreamableHttpServerConfig. That change matters because rmcp 1.6.0 brings a default Host-header allowlist, while dynoxide’s own config now shuts down the cross-origin path that DNS rebinding and no-cors fetches were exploiting. The maintainer’s own framing is blunt: the MCP HTTP transport was intentionally unauthenticated for isolated local or CI use, which is exactly why the browser boundary became the dangerous one.

The broader lesson is the one RustSec keeps forcing onto the MCP ecosystem: localhost tooling still needs web threat modeling. Docker has recently pointed to the same drive-by localhost pattern in MCP services, and dynoxide now sits squarely in that pattern too. If you are running dynoxide-rs 0.9.3 through 0.9.12 with HTTP transport enabled, patch to 0.9.13 or disable HTTP first. Once a browser is in the loop, local is no longer a synonym for safe.