The Tunnel Door Was Left Open on Purpose: CVE-2026-61546 Turns DNS Rebinding Into Unauthenticated AnkiMCP Tool Calls
NVD published CVE-2026-61546 on 28 October 2026, scoring it 8.8: AnkiMCP — the Anki addon that exposes the flashcard application as an MCP server so AI assistants can interact with it — starts a local Streamable HTTP listener by default with no bearer token, API key, session secret, Host allowlist, or Origin allowlist before MCP dispatch, and explicitly disables the DNS-rebinding protection its own framework provides. A malicious web page can use DNS rebinding to route browser requests to the victim listener, complete MCP initialization, list the available Anki tools, and invoke them. The record carries CWE-346 and CWE-350 and is sourced from the repository security advisory GHSA-j9xx-59ph-wmr6; affected versions are 0.20.x and below, fixed in 0.21.0. We read the NVD record and the full GHSA advisory, including its fix commits, first-hand.
A deliberate disable with a comment
What distinguishes this entry in the long catalogue of localhost-MCP exposures is that the protection was present and was switched off on purpose. The vulnerable transport configuration in anki_mcp_server/mcp_server.py constructs TransportSecuritySettings with enable_dns_rebinding_protection = False, under a comment explaining the intent: to allow tunnels and proxies such as ngrok and Cloudflare. The addon runs locally, the reasoning goes, and users explicitly configure tunnel access — so the framework guardrail was disabled globally rather than per-deployment. The default configuration in anki_mcp_server/config.py then enables that unguarded HTTP server on 127.0.0.1:3141 with an empty path selecting the root endpoint, and the project README documents exactly that endpoint as the wiring for Claude Desktop and Claude Code via mcp-remote.
The advisory proof of concept stays on the security-relevant path throughout — the real server class, real FastMCP construction, real Streamable HTTP transport, real tool registration — and demonstrates the full sequence with attacker-controlled headers: initialization, tools/list, then tools/call, with nothing challenging the caller at any step. The browser-origin boundary for this listener depended entirely on the FastMCP transport protection the addon disabled. Once that single control is off, loopback, default port, and documented client wiring do the rest of the attacker's work: the victim only has to visit a page.
A crowded class with a distinct trade-off
Readers of this site will recognise the shape. DNS rebinding against local MCP transports has recurred all year: DBHub's trio of advisories, GitLab MCP personal-token exfiltration, Google MCP Toolbox CVE-2026-9739, MCPJam Inspector CVE-2026-23744, and just this week MoLing's permissive-CORS session hijack (CVE-2026-62863), where any web page could steal an MCP session ID. AnkiMCP adds two details worth keeping. First, the disable was a documented product decision for tunnel support, not an oversight — which means every deployment that enabled ngrok-style access inherited the exposure by design, and the fix has to preserve that legitimate use case behind real authentication rather than merely flipping the flag back. Second, the tools on the other side of the boundary belong to a desktop AI-assistant workflow: the compromise path runs from a browser tab to the same tool surface the user's coding assistant drives, collapsing the distance between drive-by web content and agent capabilities.
The fix, in commits 6dcb6939 and d5306ff4 released under tag v0.21.0, restores the transport protection. NVD still lists the record as Deferred, so enrichment-dependent scanners may lag; the GHSA advisory and the tagged release carry everything needed to act.
What to do
- Upgrade to 0.21.0. Every 0.20.x release carries the flaw with the listener enabled by default. If you pinned the addon version in a managed Anki deployment, unpin or re-pin to the fixed release.
- Disable the HTTP listener if nothing uses it. The exposure exists because
http_enableddefaults to true. If your assistants reach AnkiMCP over stdio or you do not use the Claude Desktop or Code HTTP wiring, turn the listener off rather than relying on the framework guardrail alone. - Put real authentication in front of any tunnel. The original reason for the disable — ngrok and Cloudflare tunnels — remains legitimate, but an internet-reachable MCP endpoint with no bearer token or session secret is not a tunnel configuration, it is a public API. Require a secret at the tunnel edge and a Host allowlist behind it.
- Treat every localhost MCP server as network-exposed. DNS rebinding collapses the loopback trust assumption this entire product class was built on. Inventory local MCP listeners the way you inventory open ports: bound address, authentication, origin checks, and which tools become remotely invocable if all three answers are unsatisfying.
- Do not wait for NVD enrichment. The record status is Deferred, so CPE matching is absent and some scanners will not fire. Decide from the GHSA advisory and the release tag.
Our verification was read-only: we read the NVD JSON record and the complete GHSA-j9xx-59ph-wmr6 advisory page, including the vulnerable transport and configuration excerpts and the proof-of-concept description, plus the two fix commits and the v0.21.0 tree reference. We did not clone the repository, run the server, or send any request to a local or remote listener.
Sources:
- GHSA-j9xx-59ph-wmr6 — DNS rebinding reaches unauthenticated local AnkiMCP HTTP tools (affected 0.20.x and below, patched 0.21.0; vulnerable configuration excerpts and proof of concept; read first-hand)
- NVD — CVE-2026-61546 (published 28 October 2026; CVSS 8.8; CWE-346 and CWE-350; status Deferred; read first-hand)
- ankimcp/anki-mcp-server-addon commit 6dcb6939 (fix commit referenced by the NVD record)
- ankimcp/anki-mcp-server-addon tree v0.21.0 (patched release referenced by the NVD record)