https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 06:21:18 +0000 https://db.gcve.eu/vuln/ghsa-vv4j-m4vr-f3g6 <p><strong>Affected:</strong> PyPI: esphome-device-builder</p> <p>## Summary</p> <p>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&#39;s LAN interface, and any device on the local network could reach `http://&lt;ha-ip&gt;:&lt;ingress_port&gt;/` and get the full dashboard with no credentials.</p> <p>## Details</p> <p>The HA add-on ingress site is intentionally unauthenticated: the supervisor&#39;s ingress proxy authenticates the browser upstream, and the dashboard&#39;s threat model assumes the site is reachable only through the supervisor&#39;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&#39;s LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.</p> <p>This is an auth bypass on a boundary the dashboard explicitly defends. `docs/THREAT_MODEL.md` names, under the surface it still defends, &#34;anything that lets external traffic reach the ingress site without going through the supervisor.&#34; The bug is exactly that.</p> <p>The fix, in PR #1565, mirrors what the legacy add-on&#39;s nginx did:</p> <p>- 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&#39;s host-network ESP…</p> <p><strong>Affected:</strong> PyPI: esphome-device-builder</p> <p>## Summary</p> <p>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&#39;s LAN interface, and any device on the local network could reach `http://&lt;ha-ip&gt;:&lt;ingress_port&gt;/` and get the full dashboard with no credentials.</p> <p>## Details</p> <p>The HA add-on ingress site is intentionally unauthenticated: the supervisor&#39;s ingress proxy authenticates the browser upstream, and the dashboard&#39;s threat model assumes the site is reachable only through the supervisor&#39;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&#39;s LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.</p> <p>This is an auth bypass on a boundary the dashboard explicitly defends. `docs/THREAT_MODEL.md` names, under the surface it still defends, &#34;anything that lets external traffic reach the ingress site without going through the supervisor.&#34; The bug is exactly that.</p> <p>The fix, in PR #1565, mirrors what the legacy add-on&#39;s nginx did:</p> <p>- 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&#39;s host-network ESP…</p> https://db.gcve.eu/vuln/ghsa-vv4j-m4vr-f3g6 https://db.gcve.eu/vuln/pysec-2026-3834 <p><strong>Affected:</strong> PyPI: esphome-device-builder</p> <p>## Summary</p> <p>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&#39;s LAN interface, and any device on the local network could reach `http://&lt;ha-ip&gt;:&lt;ingress_port&gt;/` and get the full dashboard with no credentials.</p> <p>## Details</p> <p>The HA add-on ingress site is intentionally unauthenticated: the supervisor&#39;s ingress proxy authenticates the browser upstream, and the dashboard&#39;s threat model assumes the site is reachable only through the supervisor&#39;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&#39;s LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.</p> <p>This is an auth bypass on a boundary the dashboard explicitly defends. `docs/THREAT_MODEL.md` names, under the surface it still defends, &#34;anything that lets external traffic reach the ingress site without going through the supervisor.&#34; The bug is exactly that.</p> <p>The fix, in PR #1565, mirrors what the legacy add-on&#39;s nginx did:</p> <p>- 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&#39;s host-network ESP…</p> <p><strong>Affected:</strong> PyPI: esphome-device-builder</p> <p>## Summary</p> <p>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&#39;s LAN interface, and any device on the local network could reach `http://&lt;ha-ip&gt;:&lt;ingress_port&gt;/` and get the full dashboard with no credentials.</p> <p>## Details</p> <p>The HA add-on ingress site is intentionally unauthenticated: the supervisor&#39;s ingress proxy authenticates the browser upstream, and the dashboard&#39;s threat model assumes the site is reachable only through the supervisor&#39;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&#39;s LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.</p> <p>This is an auth bypass on a boundary the dashboard explicitly defends. `docs/THREAT_MODEL.md` names, under the surface it still defends, &#34;anything that lets external traffic reach the ingress site without going through the supervisor.&#34; The bug is exactly that.</p> <p>The fix, in PR #1565, mirrors what the legacy add-on&#39;s nginx did:</p> <p>- 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&#39;s host-network ESP…</p> https://db.gcve.eu/vuln/pysec-2026-3834