GHSA-q855-8rh5-jfgq

### 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