ESPHome Dashboard: Env Var Rename Silently Disabled Auth on Upgrade (CVE-2026-59178)

A GitHub Security Advisory (GHSA-rrxg-g2pf-6hh4, CVE-2026-59178, CVSS 9.8) discloses that the ESPHome dashboard component silently lost authentication for a subset of deployments when its credential env vars were renamed.

What happened

The dashboard reads credentials from $ESPHOME_USERNAME / $ESPHOME_PASSWORD. Older versions, and documentation from the legacy getting-started guide, used bare $USERNAME / $PASSWORD instead. When these were renamed (device-builder#265) to avoid a separate footgun — $USERNAME colliding with the OS login user — the bare names were dropped with no fallback. Any operator who had protected their dashboard using only the bare vars found authentication silently disabled after upgrading, with the REST auth middleware and WebSocket login gate both turned off. A WITHOUT AUTHENTICATION startup banner is logged, but it's easy to miss on a detached container (docker run -d). The break affected the standalone ghcr.io/esphome/esphome Docker container (non-HA-addon mode); Home Assistant add-on installs, which authenticate via supervisor ingress, were not affected. The breaking change was not called out in the 2026.6.0 changelog.

Why it matters

Per the advisory's own threat model, an authenticated dashboard caller can already run arbitrary code at compile time and read/write files in config and data directories — so an unauthenticated caller gets the same host-equivalent capability with no credentials, no user interaction, and low attack complexity. The worst case is an internet-reachable dashboard, which is exactly the scenario operators were trying to prevent by setting a password in the first place. Risk is lower for instances confined to a trusted home/business LAN, but anyone on a shared, guest, or internet-facing network with an affected instance is fully exposed.

What defenders should do now

• Check any ESPHome dashboard/container for the WITHOUT AUTHENTICATION banner in startup logs to confirm whether an instance is currently open.
• Inventory ESPHome dashboard deployments and confirm whether they rely on bare $USERNAME/$PASSWORD — if so, treat them as exposed until remediated.
• Immediate mitigation without upgrading: set ESPHOME_USERNAME and ESPHOME_PASSWORD to the existing values so authentication is restored on any affected version.
• Restrict network exposure of the dashboard port to trusted hosts/segments regardless of auth state, consistent with ESPHome's documented trusted-network deployment model.
• Patch to esphome-device-builder 1.0.12, or the esphome container release 2026.6.2 which pins that version — this restores the bare-name fallback (gated to require both username and password together) with a deprecation warning, and operators should still migrate to the $ESPHOME_* names.
• For hunting: review dashboard access/audit logs (where available) for configuration edits or firmware flashes from unrecognized source IPs during the window an instance may have been unauthenticated.

This is a developing item based on a same-day GHSA publication; details may be refined as more deployment data emerges. See the original advisory for full technical detail: GHSA-rrxg-g2pf-6hh4.