CVE-2026-55637: Remote Administrative Command Execution in genieacs-mcp via DNS Rebinding

The Model Context Protocol (MCP) server genieacs-mcp serves as an administrative bridge, enabling Large Language Model (LLM) agents to interact with GenieACS TR-069 Auto-Configuration Server (ACS) instances.\n\nBy interfacing directly with the GenieACS Northbound Interface (NBI), this tool exposes administrative functions to control Customer Premises Equipment (CPE) such as home routers, ONTs, and gateways.\n\nIn versions prior to 0.3.2, the application features an unauthenticated streamable HTTP server configured by default to listen on the loopback interface (127.0.0.1:8080). This architectural design assumes that loopback binding provides isolated protection against external threats.\n\nThis trust model is bypassed when an administrative user visits an attacker-controlled website. The external site can perform a DNS rebinding attack, routing cross-origin browser payloads to the local bridge.

The underlying vulnerability originates in the HTTP transport layer handler found within cmd/server/main.go.\n\nBy default, the application runs without requiring an authorization token (MCP_AUTH_TOKEN) if the server binds to loopback, operating on the premise that local sockets are unreachable from external domains.\n\nThe unpatched HTTP transport processes incoming Server-Sent Events (SSE) and JSON-RPC over HTTP requests without verifying the Host or Origin headers.\n\nThis configuration is susceptible to a classic DNS rebinding sequence. An attacker registers a domain name with a low Time-To-Live (TTL) value and configures their DNS server to respond first with a public IP hosting exploit scripts, and subsequently with the loopback IP (127.0.0.1).\n\nBecause the browser associates the active session with the original domain, it maintains the Same-Origin Policy (SOP) context. The browser continues sending requests, which are now routed directly to the unauthenticated loopback interface of the local MCP bridge.

The development history of the project shows an iterative hardening process before the final remediation of the DNS rebinding path.\n\nInitially, commit 8d7d343b905827d9cfa2e099dc9967471866f565 attempted to secure the interface by default-binding to 127.0.0.1. A subsequent commit, bcb91f12cbf61afafcd5b85d1c39147d0c6cca71, mandated authorization tokens only for non-loopback bindings, still leaving localhost sockets exposed.\n\nThe vulnerability was resolved in version 0.3.2 via commit 577306d78190622eee97e362b042a69499ef373f with the implementation of a middleware named dnsRebindGuard. This module explicitly evaluates the HTTP metadata of incoming payloads:\n\ngo\n// dnsRebindGuard rejects requests whose Host header is not in the allowed set,\n// and requests carrying an Origin that is not allowed. This blocks DNS\n// rebinding.\nfunc dnsRebindGuard(next http.Handler, hosts, origins map[string]bool) http.Handler {\n\treturn http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\tif !hosts[r.Host] {\n\t\t\thttp.Error(w, "forbidden: untrusted Host header", http.StatusForbidden)\n\t\t\treturn\n\t\t}\n\t\tif origin := r.Header.Get("Origin"); origin != "" && !origins[strings.TrimRight(origin, "/")] {\n\t\t\thttp.Error(w, "forbidden: untrusted Origin header", http.StatusForbidden)\n\t\t\treturn\n\t\t}\n\t\tnext.ServeHTTP(w, r)\n\t})\n}\n\n\nThe helper functions utilize standard library packages like net.SplitHostPort and net.JoinHostPort to normalize incoming requests, blocking variations such as subdomain injection while permitting safe, local command-line tool integrations.

To execute the attack, a threat actor must induce a local operator running genieacs-mcp to load a malicious web resource.\n\nmermaid\ngraph LR\n Victim["Victim Browser"] -->|"1. Visits site"| Attacker["Attacker Web Server (Public IP)"]\n Attacker -->|"2. Delivers Exploit JS"| Victim\n Victim -->|"3. Query DNS (TTL=1s)"| DNS["Malicious DNS Server"]\n DNS -->|"4. Rebinds domain to 127.0.0.1"| Victim\n Victim -->|"5. Issues JSON-RPC HTTP requests"| LocalMCP["local genieacs-mcp (127.0.0.1:8080)"]\n LocalMCP -->|"6. Executes commands on ACS NBI"| GenieACS["GenieACS Instance"]\n\n\nUpon accessing the landing page, the malicious JavaScript sends an asynchronous request to an attacker-controlled subdomain. The custom DNS server answers with a TTL of 1 second.\n\nWhen the TTL expires, the script triggers another request to the same domain name. The DNS server answers this resolution query with 127.0.0.1. The browser routes the network packet to localhost on port 8080.\n\nBecause the port, protocol, and host domain matches the initial configuration from the browser's perspective, the script successfully bypasses SOP restrictions, invoking administrative tools such as reboot_device or download_firmware.

An exploitation sequence targeting a genieacs-mcp setup can result in a significant compromise of downstream network assets.\n\nBy exploiting the local MCP server, an external attacker gains the ability to leverage all privileges assigned to the bridge's API key within the GenieACS environment.\n\nThis vector allows attackers to view sensitive configurations, push modified firmware images to managed CPE devices, or execute localized service disruptions by triggering device reboots.\n\nConsequently, the blast radius of this client-side vulnerability extends far beyond the user's workstation, posing a severe risk to carrier-grade network gateways and customer deployments.

Operators must prioritize upgrading their deployments of genieacs-mcp to version 0.3.2 or above.\n\nIf upgrading is not immediately possible, you can mitigate the vulnerability by forcing Stdio mode. Configure the environment variable:\n\nTRANSPORT=stdio\n\nThis setting disables the HTTP socket transport layer completely, eliminating the network attack surface.\n\nIf you require the HTTP transport layer, you must define MCP_AUTH_TOKEN in your environment configuration to enforce bearer token verification, and configure MCP_ALLOWED_HOSTS to define the strict domains authorized to reach the endpoint.