GHSA-Q855-8RH5-JFGQ: Missing Authentication and CSRF in ha-mcp bare root settings and policy routes

The ha-mcp add-on for Home Assistant exposes its administrative and configuration endpoints directly at the application's root HTTP path on port TCP/9583. While the primary access mechanism is designed to operate through a high-entropy secret URL (/private_<secret>/...), the alternative bare-root paths (/api/settings/... and /api/policy/...) were implemented without independent authentication controls. This design choice results in an unintended exposure of critical administrative capabilities to any network-adjacent system or client capable of routing traffic to the add-on port.\n\nThis vulnerability falls under the classifications of Missing Authentication for Critical Function (CWE-306) and Cross-Site Request Forgery (CWE-352). Because the endpoints do not validate the source of incoming requests, verify the session state, or enforce Cross-Origin Resource Sharing (CORS) protections, they present a direct attack surface to internal networks. An unauthorized actor can exploit these routes to reconfigure integration tools, access system policy configurations, and bypass human-in-the-loop security validation mechanisms.\n\nThe affected components include configuration handlers that manage tool visibility, system backups, and execution policies. The exposure does not directly leak system-level host credentials or enable direct execution of arbitrary binary code on the host operating system. It does, however, allow attackers to disable approval gates, which are designed to prevent the unauthorized invocation of sensitive physical or system-level actions via the Model Context Protocol.

The root cause of this vulnerability lies in a trust boundary mismatch between the Home Assistant Supervisor Ingress proxy and the internal Starlette-based FastMCP web server. Home Assistant add-ons rely on the Supervisor Ingress component to proxy authenticated user browser sessions to the add-on container. To facilitate this integration, the ha-mcp application exposes administrative routes at its bare root path, expecting that any traffic reaching these paths will have been authenticated and routed through the Supervisor.\n\nThis assumption fails because the add-on is bound to a network port (TCP/9583) that can be accessed directly depending on the container network configuration. When the add-on is deployed using host networking or standard port mapping, port 9583 is accessible to any device on the local network. Because the application did not implement any transport-layer or application-layer authentication checks on the bare-root routes, direct connections to these endpoints bypass the Supervisor Ingress authentication layer entirely.\n\nFurthermore, the routing architecture in src/ha_mcp/settings_ui.py mapped the administrative handlers across two parallel prefixes without applying unified middleware guards. The first prefix used a high-entropy path variable to restrict access to authorized clients holding the secret token. The second prefix mounted the same administrative handlers at the bare root of the API, leaving them entirely unprotected when accessed directly via the container port. The routing engine executed incoming requests on the bare-root path without performing origin, referrer, or session-token validation.

An inspection of the codebase prior to the mitigation reveals that the application initialized its HTTP routes globally on the Starlette application object without discriminating between ingress and non-ingress origins. The following code block illustrates the vulnerable route mapping implementation in src/ha_mcp/settings_ui.py:\n\npython\n# PRE-PATCH: Vulnerable route registration\nif is_addon:\n # The root page and the api prefix are registered without verification\n mcp.custom_route(\"/\", methods=[\"GET\"])(handlers[\"root_page\"])\n _mount(\"\") # Mounts settings and policy routes directly to the bare root path\n\n\nWhen _mount(\"\") is executed, it establishes endpoints such as /api/settings/tools and /api/policy/config at the root prefix. These endpoints map directly to state-changing methods without verifying the underlying connection details. The patched implementation introduces a decorator, _ingress_only, which retrieves the transport-layer client host and compares it to the static Home Assistant Supervisor Ingress IP address:\n\npython\n# POST-PATCH: Mitigated route registration utilizing the _ingress_only guard\nSUPERVISOR_INGRESS_IP = \"172.30.32.2\"\n\ndef _ingress_only(handler: _SettingsRoute) -> _SettingsRoute:\n @functools.wraps(handler)\n async def _guarded(request: Request) -> Response:\n # Extract the transport peer IP directly from the ASGI scope\n peer = request.client.host if request.client else None\n if peer != SUPERVISOR_INGRESS_IP:\n logger.warning(\n \"Blocked non-ingress request to add-on root route %s from peer %r\",\n request.url.path,\n peer\n )\n return JSONResponse(\n {\n \"error\": (\n \"This endpoint is only reachable through Home \"\n \"Assistant ingress. For direct or remote access, use \"\n \"the settings UI under your MCP secret path.\"\n )\n },\n status_code=403,\n headers={\"Content-Type\": \"application/json\"}\n )\n return await handler(request)\n return _guarded\n\n\nmermaid\ngraph LR\n Client[\"Untrusted Client (LAN/WAN)\"] -->|TCP/9583| App[\"ha-mcp Web Server\"]\n Supervisor[\"Supervisor Ingress (172.30.32.2)\"] -->|TCP/9583| App\n App --> Guard[\"_ingress_only Guard\"]\n Guard -->|IP != 172.30.32.2| Block[\"HTTP 403 Forbidden\"]\n Guard -->|IP == 172.30.32.2| Pass[\"Execute Admin Handler\"]\n\n\nThis implementation is robust because it queries the transport-level peer address (request.client.host) directly from the socket wrapper rather than reading HTTP request headers such as X-Forwarded-For. An external attacker attempting to forge the origin IP via headers cannot bypass this check because the ASGI server extracts the socket-level peer IP. However, the completeness of this fix depends on the ASGI server configuration; if the server is run with a flag that trustfully parses proxy headers from arbitrary networks, header spoofing could still be possible.

An attacker can exploit this vulnerability through three distinct operational scenarios depending on the network posture of the targeted Home Assistant host. The primary prerequisite is that the attacker must have network reachability to TCP port 9583 on the host running the ha-mcp container. This occurs when the container is configured with host networking or when port 9583 is mapped to an external interface on the host.\n\nIn a local network attack scenario, a malicious device or compromised asset on the same subnet issues direct HTTP requests to the target host on port 9583. Because the root endpoints require no authentication, the attacker can retrieve the full system configuration by calling GET /api/policy/config. To bypass human-in-the-loop security policies, the attacker can poll GET /api/policy/pending to extract active approval tokens, then issue a POST /api/policy/approve request to authorize restricted tool executions without user intervention.\n\nIn a Cross-Site Request Forgery (CSRF) attack scenario, the attacker does not need direct access to the local network. If a local user visits a malicious website, browser-based JavaScript can execute background requests targeting common local IP subnets on port 9583. Because the application's root routes do not enforce CSRF tokens or validate Origin headers, the browser will execute state-changing requests, allowing the attacker to reconfigure the system or delete configuration backups remotely.

The direct impact of exploiting this vulnerability is the unauthorized modification of the ha-mcp system state and the compromise of tool execution constraints. An attacker who successfully interacts with the bare-root API endpoints can enable or disable integration tools, toggle application feature flags, and manipulate configuration backups. This allows the attacker to restore older, potentially vulnerable backup configurations or erase current backups to cause operational disruption.\n\nCrucially, the exploitation of these routes allows for the complete bypass of human-in-the-loop validation policies. These policies are designed as a defense-in-depth measure to prevent external language models or automated agents from executing hazardous physical actions—such as unlocking smart locks, opening garage doors, or disabling security systems—without manual confirmation. By polling pending approvals and submitting forged approval decisions, an attacker can force the execution of these sensitive actions.\n\nThis vulnerability does not, however, grant direct access to Home Assistant credentials, long-lived access tokens, or sensitive entity historical data stored in the main Home Assistant database. It does not provide arbitrary shell execution on the host operating system. The severity is assessed as Moderate, with a CVSS v3.1 score of 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L), reflecting that while the vulnerability is remotely exploitable without authentication, the scope is restricted to the ha-mcp container environment and does not propagate to the underlying host or the broader Home Assistant instance.

The primary remediation for this vulnerability is upgrading the ha-mcp add-on to version 7.6.0.dev393 or later. This release incorporates the _ingress_only route-guard decorator, which enforces transport-peer restriction to the Supervisor's internal container IP address. Users should verify their active version via the Home Assistant Add-on store and apply any pending updates immediately.\n\nWhere an immediate upgrade is not feasible, operators must implement network-level segmentations to mitigate the risk of direct exposure. The most effective workaround is disabling port exposure for port 9583 in the add-on configuration panel if host network access is not strictly required. Furthermore, local firewalls should be configured to drop incoming TCP traffic on port 9583 originating from external interfaces or untrusted subnets, allowing connections only from the local host loopback or trusted container networks.\n\nDetection of exploitation attempts can be achieved by monitoring web server logs for requests directed at /api/settings/ or /api/policy/ that originate from IP addresses other than the Supervisor Ingress IP (172.30.32.2). Security teams can deploy the provided Sigma rule or Splunk query to automatically flag unauthorized state-changing requests and trigger alerts for non-standard administrative traffic.