Listen to this Post
How the mentioned CVE works:
The vulnerability exists in dynoxide’s MCP HTTP transport (enabled via `dynoxide mcp –http` or dynoxide serve --mcp). A transitive dependency on `rmcp` versions prior to 1.4.0 lacks a Host-header allowlist. An attacker hosts a malicious webpage that uses DNS rebinding: first the page resolves a domain to the attacker’s IP, then after a short TTL, rebinds it to 127.0.0.1 (or other loopback address). The browser’s same-origin policy does not block requests to IP addresses, only to domains. The attacker’s JavaScript fetches the local dynoxide endpoint (e.g., http://attacker.example.com:8000` which now resolves to 127.0.0.1). The browser sends the request with the original domain name in the Host header (attacker.example.com), not localhost. The old `rmcp` server accepts any Host header, so it processes the request. Additionally, a related cross-origin CSRF gap exists: even if the Host header matched (e.g., using `fetch` tohttp://127.0.0.1:8000` with mode: 'no-cors'), the server did not validate the Origin header, allowing cross-site requests. An attacker can call any MCP tool exposed by the local instance, including read and write operations on tables. The stdio transport (default `dynoxide mcp` without --http) is unaffected because it does not expose an HTTP endpoint. Affected versions: 0.9.3 to 0.9.12. The patch upgrades `rmcp` to 1.6.0 (which blocks non-loopback Host headers) and adds explicit `allowed_hosts` and `allowed_origins` lists.
dailycve form:
Platform: dynoxide
Version: 0.9.3-0.9.12
Vulnerability: DNS rebinding CSRF
Severity: High
date: ( unspecified)
Prediction: Patch already available
What Undercode Say:
Check if vulnerable dynoxide version is running dynoxide --version | grep -E "0.9.[3-9]|0.9.1[0-2]" Simulate DNS rebinding attack (conceptual) curl -H "Host: attacker.com" http://127.0.0.1:8000/mcp Verify patch - Host header validation curl -H "Host: evil.net" http://127.0.0.1:8000/mcp Expected 403 Forbidden after upgrade Check Origin header validation (CSRF defense) curl -H "Origin: https://malicious.site" http://127.0.0.1:8000/mcp
how Exploit:
Attacker registers domain (e.g., dynoxide-evil.com) with DNS TTL=0. Victim runs `dynoxide mcp –http` on localhost:8000. Victim visits malicious page. Page uses WebSocket or fetch to resolve domain, then DNS rebinds to 127.0.0.1. Script sends POST request with `Host: dynoxide-evil.com` to http://127.0.0.1:8000/tools/call` with JSON payload{“tool”:”delete_item”,”params”:{…}}. Server processes request, deletes data.dynoxide mcp
<h2 style="color: blue;">Protection from this CVE</h2>
- Upgrade to dynoxide 0.9.13 immediately.
- If upgrade impossible: avoid `--http` flag; use default stdio transport ().dynoxide serve
- For, do not pass–mcp.list_tables
- Add reverse proxy with strict Host header allowlist (localhost, 127.0.0.1, ::1) and Origin validation.
- Run local HTTP MCP server on a random high port and bind only to loopback (already loopback, but still vulnerable – upgrade is only fix).
<h2 style="color: blue;">Impact:</h2>
Full read/write access to all tables accessible by the local dynoxide instance. Attacker can enumerate schemas (,describe_table), exfiltrate data (scan,query), modify records (put_item,update_item), delete records or entire tables (delete_item,delete_table`), and batch operations. Data confidentiality, integrity, and availability compromised. No authentication bypass needed – the browser acts as an authorized client because the server trusts localhost-origin requests without proper header validation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
