NewApp Monitoring is liveSign up free
AgentbeamBeta
AI agent vulnerability · Other MCP servers and tools

GHSA-q855-8rh5-jfgq: ha-mcp: Add-on settings and policy routes are reachable without authentication at the bare root path

mediumCVSS 3.1 6.5

The Home Assistant add-on for ha-mcp exposes its settings and policy routes at the bare root of port 9583 with no authentication. Anyone who can reach that port can change which MCP tools are exposed, restore or delete backups, restart the add-on and, if enabled, rewrite the approval policy. Fixed in ha-mcp 7.10.0 per the package data.

Published Jul 7, 2026 · Analysis Oct 25, 2026

What an attacker can do

In add-on mode, the settings UI is mounted under the MCP secret path and also at the root of the published port, so Home Assistant ingress can serve the "Open Web UI" button. The root routes check no secret, no Origin and no CSRF token.

A caller on the LAN, a reverse proxy or tunnel that forwards the bare root (for example a whole-host Cloudflared config), or a CSRF POST from a page open in a LAN browser can use these routes: /api/settings/tools, /api/settings/features, /api/settings/backups (list, view, restore, delete), /api/settings/backup-config and /api/settings/restart. With the opt-in Tool Security Policies feature on, the /api/policy/config PUT and the approve and deny routes are also open. An attacker can then rewrite the policy and switch off the human-approval gate on gated tools.

The advisory says there is no access to Home Assistant data, entities or credentials and no code execution. Effects stay inside the add-on's configuration and lifecycle and are recoverable. Disabling the approval gate matters for agents that drive a smart home through ha-mcp, since later tool calls then run unreviewed. The MCP endpoint itself stays protected by the secret path.

Who is affected

Affected: Home Assistant add-on installs of ha-mcp (host_network: true with port 9583 published), version 7.6.0 and earlier per the advisory text. The package data records < 7.10.0 as vulnerable. Docker and standalone installs are not affected, because there the settings routes mount only under the secret path.

Check the add-on version in Home Assistant under Settings, Add-ons, ha-mcp. To test exposure, request /api/settings/tools on port 9583 without the secret. A 200 response means it is open.

pip show ha-mcp

That last command applies only if you installed the Python package yourself.

ha-mcp

Ecosystem
PyPI
Affected
< 7.10.0
Fixed in
7.10.0
Check
pip show ha-mcp

How to fix it

Upgrade to ha-mcp 7.10.0 (the patched version in the package data). The fix, in pull request 1508, limits the root-mounted add-on routes to Home Assistant ingress, which always comes from the Supervisor at 172.30.32.2. Every other caller gets 403. The check uses the transport peer, not the spoofable X-Forwarded-For header.

Direct and remote access still work through the settings UI under the MCP secret path. The "Open Web UI" button, Cloudflared and the Webhook Proxy add-on are unaffected. The advisory names no workaround. Until you upgrade, do not forward the bare port through a reverse proxy or tunnel, and keep port 9583 off untrusted networks.

How to tell if you were hit

Look in the add-on log for requests to /api/settings/... or /api/policy/... at the bare root from addresses other than the Supervisor. After the upgrade, rejected callers are logged with their address. Check for unexpected add-on restarts, changed tool visibility or feature flags, deleted or restored backups, and an approval policy you did not write. If Tool Security Policies is on, compare the current policy with your last known good copy.

Original advisory

From the GitHub Advisory Database (CC BY 4.0).

Summary

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.

Affected configurations

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, …).

Impact

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.

Proof of concept

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.

Patch

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.

Severity

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.

Credit

Reported by @bharat.

Credited to bharat.

Questions

Are Docker or standalone ha-mcp installs affected?

No. The advisory says only the Home Assistant add-on is affected, since only it mounts the settings routes at the bare root. Other installs mount them only under the secret path.

Can an attacker reach my Home Assistant devices through this?

The advisory says no. There is no access to Home Assistant data, entities or credentials, and no code execution. The impact is limited to add-on configuration, backups and restarts, though an attacker can disable the approval gate.

Does this have a CVE?

The data for this entry has only a GHSA id, GHSA-q855-8rh5-jfgq, and no CVE. The advisory scores it 6.5 with CVSS 3.1.

References

How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. The analysis is written by an AI model from the sources listed above and checked by automated rules before it is published. Check versions against the vendor's advisory before you act. Methodology

More Other MCP servers and tools vulnerabilities

All Other MCP servers and tools entries