ESPHome dashboard lost its password after env var rename

ESPHome has disclosed a flaw in ESPHome Device Builder that silently switched off authentication on its device dashboard for some self-hosted deployments after an upgrade. The advisory, GHSA-rrxg-g2pf-6hh4, tracked as CVE-2026-59178, was published on 14 September 2026 and rates the issue at high severity.

According to the advisory, the dashboard reads its login credentials from the environment variables ESPHOME_USERNAME and ESPHOME_PASSWORD. Earlier versions, and the legacy esphome dashboard, read the bare USERNAME and PASSWORD instead. When the variables were renamed, the bare names were dropped with no fallback. An operator who had protected the dashboard using the old names, as the older getting started guide documented, lost authentication on upgrade, and the dashboard became open to anyone who could reach its port.

The project said the rename was deliberate. Reading a bare USERNAME collides with the operating system login user on Linux and Windows, which would silently promote the shell user to the dashboard username. Removing it closed that trap but broke backward compatibility: a deployment that set only the bare names resolves to no credentials, and both the REST authentication middleware and the WebSocket login gate are disabled.

The process does print a WITHOUT AUTHENTICATION banner at startup. ESPHome notes that a container started in detached mode never surfaces it, so the exposure is silent in practice. The advisory also says the rename was tagged as a breaking change but was not listed in the 2026.6.0 changelog, so operators had no signal to migrate before upgrading.

The affected path is the standalone Docker route. The dashboard subcommand of the ghcr.io/esphome/esphome container runs the pinned esphome-device-builder package and inherits whatever environment the operator passed. Home Assistant add-on installs are not affected, because they pass --ha-addon and authenticate through the supervisor ingress proxy without using these variables. Deployments that use the --username and --password flags, or the new ESPHOME_* variables, are also unaffected.

On impact, the advisory says an unauthenticated client with network access to the dashboard port can manage devices, including editing configurations and flashing firmware. ESPHome's own threat model documents that an authenticated dashboard caller can run arbitrary code at compile time and read or write files in the configuration and data directories, which the project cites as the reason confidentiality, integrity and availability are all rated high with no credentials and no user interaction required.

ESPHome scored the issue for the worst case of an internet-reachable dashboard, arguing that setting a password is the control an operator uses precisely when the dashboard can be reached by parties they do not fully trust. It adds that real-world exposure is lower for installations behind a firewall on a single trusted network, since an attacker would already need to be inside, but that this does not lower the base score.

The fix is in ESPHome Device Builder 1.0.12, which accepts the bare USERNAME and PASSWORD again as a deprecated fallback so previously protected instances stay protected without operator action, with a loud deprecation warning at startup. The fallback is gated on PASSWORD being set and is only adopted as a pair, so the operating system USERNAME is never read alone. A lone bare PASSWORD fails loudly as a credential mismatch rather than starting unauthenticated. The esphome container ships the fix in release 2026.6.2.

Without upgrading, ESPHome says operators can restore authentication on any affected version by setting the new ESPHOME_USERNAME and ESPHOME_PASSWORD variables to the same values, keep the dashboard port off untrusted networks, and check startup logs for the WITHOUT AUTHENTICATION banner.