https://db.gcve.eu/rss/recent/all/10 Most recent entries from all 2026-10-06T06:21:17.970394+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent entries. https://db.gcve.eu/vuln/ghsa-vv4j-m4vr-f3g6 GHSA-vv4j-m4vr-f3g6 — ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfac… 2026-10-06T06:21:17.996376+00:00

Affected: PyPI: esphome-device-builder

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

 https://db.gcve.eu/vuln/pysec-2026-3834 PYSEC-2026-3834 — ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfac… 2026-10-06T06:21:17.996468+00:00

Affected: PyPI: esphome-device-builder

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