PyPI · ha-mcp
ha-mcp: Add-on settings and policy routes are reachable without authentication at the bare root path
In add-on mode, the ha-mcp settings UI routes are mounted both under the MCP secret path and at the bare root of the published port (:9583), so Home Assistant ingress can serve the "Open Web UI" button. The root-mounted routes perform no authentication — no secret, no Origin check, no CSRF token — so any client that can reach :9583 without the MCP secret can invoke them.
Home Assistant add-on installations (host_network: true with port 9583 published), v7.6.0 and earlier. Docker and standalone installs are not affected — there the settings routes are mounted only under the secret path.
Root-mounted routes in affected versions: tool visibility (/api/settings/tools GET/POST), feature flags (/api/settings/features GET/POST), the auto-backup suite (/api/settings/backups… incl. restore/delete, and /api/settings/backup-config), add-on restart (/api/settings/restart), and — when the opt-in Tool Security Policies feature is enabled — the approval-policy API (/api/policy/config GET/PUT, /api/policy/approve, /api/policy/deny, …).
Without authentication, a caller that reaches :9583 — a peer on the local network, a reverse proxy/tunnel that forwards the bare root path (e.g. a whole-host Cloudflared config), or a CSRF POST from a page open in a LAN browser — can read or change which MCP tools are exposed, toggle feature flags, list/view/restore/delete backups, restart the add-on, and (with Tool Security Policies enabled) read and rewrite the approval policy, disabling the human-approval gate on gated tools.
There is no access to Home Assistant data, entities, or credentials, and no code execution. All effects are confined to the add-on's own configuration and lifecycle and are recoverable. The primary (same-LAN) vector is within the add-on's documented trusted-network model; remote reachability requires the operator to have reverse-proxied the bare port.
With the add-on running and reachable on :9583, from any host that can reach the port without the secret:
GET /api/settings/tools -> 200 (read tool config, no auth)
POST /api/settings/tools {"states":{}} -> 200 (rewrite tool config, no auth / no CSRF token)
POST /api/settings/restart -> 200 (restart the add-on)
The MCP endpoint itself remains correctly protected by the secret path.
Fixed in PR homeassistant-ai/ha-mcp#1508 (merged to master): the root-mounted add-on routes are restricted to Home Assistant ingress, which always originates from the Supervisor (172.30.32.2); every other caller receives 403. Direct and remote access continue to use the settings UI under the MCP secret path (…/<secret>/settings), so the "Open Web UI" button, Cloudflared, and the Webhook Proxy add-on are unaffected.
The fix will ship in the next stable add-on release. If you'd rather have it now, it is already on the dev channel (add-on dev build 7.6.0.dev393 or later) — optional; there's no need to switch channels just for this, it is a fairly low risk surface and only exposes the web UI for addon mode only.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L = 6.4 (Moderate). Confidentiality impact is None — tool config and backups are not secrets or credentials; integrity and availability impacts are Low — configuration changes and an add-on restart are recoverable.
Reported by @bharat.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.