Summary
ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces
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.1and172.30.32.1) instead of all interfaces. Loopback serves HA core's host-network ESPHome integration, which connects to127.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-hoststill 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 nginxallow 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.
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 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 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.
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/
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.
CVE-2026-59177 has a CVSS score of 8.8 (High). The vector is reachable from an adjacent network, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.0.10); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-59177? CVE-2026-59177 is a high-severity security vulnerability in esphome-device-builder (pip), affecting versions < 1.0.10. It is fixed in 1.0.10.
- How severe is CVE-2026-59177? CVE-2026-59177 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of esphome-device-builder are affected by CVE-2026-59177? esphome-device-builder (pip) versions < 1.0.10 is affected.
- Is there a fix for CVE-2026-59177? Yes. CVE-2026-59177 is fixed in 1.0.10. Upgrade to this version or later.
- Is CVE-2026-59177 exploitable, and should I be worried? Whether CVE-2026-59177 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-59177 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-59177? Upgrade
esphome-device-builderto 1.0.10 or later.