Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The dashboard reads its authentication credentials from $ESPHOMEUSERNAME and $ESPHOMEPASSWORD. Earlier versions, and the legacy esphome dashboard, read the bare $USERNAME and $PASSWORD instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with USERNAME / PASSWORD (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port. Details Credentials are resolved in DashboardSettings.parseargs. The fallback originally read os.getenv("USERNAME") and os.getenv("PASSWORD"). The env var rename (#265) replaced those with ESPHOMEUSERNAME / ESPHOMEPASSWORD and intentionally removed the bare names, because $USERNAME collides with the OS login user on Linux and Windows and reading it on its own would silently promote the shell user to the dashboard username. The rename closed that footgun but introduced a backward compatibility…
Recommended action: Upgrade to 1.0.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:<ingressport/ 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…
Recommended action: Upgrade to 1.0.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.