ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces

## Summary On the Home Assistant add-on, the dashboard serves a trusted ingress site that skips authentication because the supervisor authenticates the request upstream. That site was binding `0.0.0.0`. The add-on runs in host network mode for mDNS, so binding all interfaces also bound the host's LAN interface, and any device on the local network could reach `http://<ha-ip>:<ingress_port>/` and get the full dashboard with no credentials. ## Details The HA add-on ingress site is intentionally unauthenticated: the supervisor's ingress proxy authenticates the browser upstream, and the dashboard's threat model assumes the site is reachable only through the supervisor's docker network. The protection depended on physically binding the site to the supervisor, but the site bound `0.0.0.0` instead. Because the add-on uses host networking, `0.0.0.0` includes the host's LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely. This is an auth bypass on a boundary the dashboard explicitly defends. `docs/THREAT_MODEL.md` names, under the surface it still defends, "anything that lets external traffic reach the ingress site without going through the supervisor." The bug is exactly that. The fix, in PR #1565, mirrors what the legacy add-on's nginx did: - Bind the ingress site to loopback plus the supervisor gateway (`127.0.0.1` and `172.30.32.1`) instead of all interfaces. Loopback serves HA core's host-network ESPHome integration, which connects to `127.0.0.1:<ingress_port>` without credentials by design; the gateway serves the supervisor's ingress proxy. The LAN interface is no longer bound; an explicit `--ingress-host` still overrides the bind. - Add `ingress_peer_guard`, which returns 403 to any TCP peer other than loopback or the supervisor (`172.30.32.2`), so another hassio bridge add-on reaching the gateway cannot use the site either. This mirrors the legacy nginx `allow 127.0.0.1; allow 172.30.32.2; deny all`. The password-gated public port (6052) is not affected; this only affects the host-network HA add-on's ingress port. ## Impact Any device on the same local network as the Home Assistant host could open the dashboard with no credentials and gain its full authenticated capability. Per `docs/THREAT_MODEL.md`, that capability is host equivalent: an authenticated caller can run arbitrary Python at compile time via `external_components:`, run arbitrary shell through the compile and validation subprocesses, and read or write arbitrary files in the config and data directories. So the practical impact is full compromise of the add-on, including the Home Assistant config directory it mounts and the ESPHome devices it manages. The exposure was present by default on every host-network HA add-on install; no operator misconfiguration was required. The standalone Docker dashboard and the password-gated public port are not affected. ## Severity rationale An unauthenticated network client reaches a dashboard site that performs no authentication of its own, and a client that reaches the dashboard has host equivalent capability. ESPHome's [threat model](https://github.com/esphome/device-builder/blob/main/docs/THREAT_MODEL.md) documents that a dashboard caller can run arbitrary code at compile time and read or write files in the config and data directories, so confidentiality, integrity, and availability are all High, with no credentials, no user interaction, and low attack complexity. The exposed surface is the Home Assistant host's local network interface rather than the internet, so the attack vector is adjacent, giving a CVSS base score of 8.8. The rating is anchored at the worst case because the exposure was present by default on every host-network HA add-on install, the dominant deployment, and required nothing of the victim. Any party able to reach the host's local network, including a guest network that is not isolated, an untrusted IoT device, or a compromised local host, obtains full control with a single unauthenticated request. Operational risk is lower for installations on a single trusted home or business network behind a firewall, since reaching the dashboard there requires an attacker who is already inside that network, and ESPHome is [designed for deployment on trusted networks](https://esphome.io/guides/security_best_practices/) with the network perimeter as the primary defense. That deployment context reduces real world exposure; it does not change the base severity. The ingress site is intended to require the supervisor's authentication even on the local network, and the fix restores that. ## Patches Fixed in device-builder 1.0.10 (PR #1565). The ingress site is bound to loopback and the supervisor gateway only, and a peer guard rejects any TCP peer other than loopback or the supervisor regardless of `--ingress-host`. The esphome container delivers the fix by bundling device-builder 1.0.10 or newer. ## Workarounds Upgrade to 1.0.10 or newer (an esphome container bundling device-builder 1.0.10+). Without upgrading, restrict access to the add-on's ingress port at the network layer, for example a host or router firewall rule that allows only the Home Assistant host and the supervisor to reach it, and keep the Home Assistant host on a trusted LAN segment. Accessing the dashboard through Home Assistant's normal ingress URL is unaffected and stays authenticated. ## Resources - Fix: esphome/device-builder#1565 - Ingress site introduction: esphome/device-builder#25 - Originating investigation: esphome/device-builder#1560 - ESPHome security best practices: https://esphome.io/guides/security_best_practices/

Quoted source text, attributed separately from HOL analysis.