critical · 9.8CVE-2026-59178Sep 14, 2026

CVE-2026-59178: esphome-device-builder Silent Authentication Bypass on Upgrade

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

Upgrading the ESPHome Device Builder dashboard silently drops password protection for any deployment that used the old USERNAME and PASSWORD environment variables, leaving the dashboard open to…

Packageesphome-device-builder
Ecosystempip
Affected< 1.0.12
Fixed in1.0.12
CVE-2026-59178: esphome-device-builder Silent Authentication Bypass on Upgrade

The problem

The dashboard resolves credentials in DashboardSettings.parse_args. An env-var rename in a prior release replaced os.getenv("USERNAME") and os.getenv("PASSWORD") with ESPHOME_USERNAME and ESPHOME_PASSWORD, with no fallback.

Any deployment that set only the bare USERNAME and PASSWORD (as the legacy getting-started guide documented) resolves to no credentials after upgrading. When that happens, using_password is false, and both the REST auth middleware and the WebSocket login gate are disabled.

The process logs a WITHOUT AUTHENTICATION banner, but a container started detached with docker run -d never surfaces it, so the exposure is silent in practice.

Proof of concept

A working proof-of-concept for CVE-2026-59178 in esphome-device-builder, with the exact payload below.

bash
# Affected container started with the old env vars (no ESPHOME_* names set)
docker run -d \
  -e USERNAME=admin \
  -e PASSWORD=secret \
  -p 6052:6052 \
  ghcr.io/esphome/esphome dashboard /config

# Dashboard starts with using_password=False; any client reaches it unauthenticated:
curl -s http://<dashboard-host>:6052/api/devices
# Returns full device list with no credentials required

The root cause is CWE-306 (Missing Authentication for Critical Function). When neither ESPHOME_USERNAME nor ESPHOME_PASSWORD is present in the environment, parse_args sets both credential fields to empty strings, using_password evaluates to false, and the middleware stack skips all auth checks entirely.

The patch (PR #1625, commit 9e294f7) restores a deprecated fallback: if PASSWORD is set in the environment and USERNAME is also set, both bare names are accepted as a pair and a loud deprecation warning is emitted at startup. The fallback is gated on PASSWORD being set and is adopted only as a pair, so the OS-provided USERNAME is never read on its own.

A lone bare PASSWORD with no username still fails loud rather than starting unauthenticated.

The fix restores compatibility rather than failing closed, because the priority is that an instance protected before the upgrade stays protected without operator intervention.

The fix

Upgrade esphome-device-builder to 1.0.12 (delivered in the ESPHome container via the 2026.6.2 release). Without upgrading, restore authentication immediately by migrating to the new env var names:

ESPHOME_USERNAME=<your-username> ESPHOME_PASSWORD=<your-password>

Operators using --username and --password flags, the new ESPHOME_* env vars, or the Home Assistant add-on ingress path are not affected. Check startup logs for the WITHOUT AUTHENTICATION banner to confirm whether a running instance is currently open.

Reporter not attributed.

References: [1][2][3][4][5]

Related research