CVE-2026-59178: ESPHome Dashboard Auth Bypass Vulnerability

CVE-2026-59178 Overview

CVE-2026-59178 is a missing authentication vulnerability [CWE-306] in the ESPHome Device Builder Dashboard, a web interface for the ESPHome home automation firmware toolchain. Versions prior to 1.0.12 read authentication credentials exclusively from $ESPHOME_USERNAME and $ESPHOME_PASSWORD. Earlier releases and the legacy esphome dashboard read bare $USERNAME and $PASSWORD environment variables. The rename dropped the legacy names without a fallback. Operators who followed the older getting-started guide lost authentication on upgrade, and the dashboard began accepting all requests reachable on its network port.

Critical Impact
Upgraded dashboards silently start without authentication, exposing device provisioning, firmware flashing, and secrets to any attacker who can reach the dashboard port.

Affected Products

ESPHome Device Builder Dashboard versions prior to 1.0.12
ESPHome container releases prior to 2026.6.2 (which pins esphome-device-builder1.0.12)
Legacy esphome dashboard deployments migrated using the older $USERNAME / $PASSWORD configuration

Discovery Timeline

2026-09-14 - CVE-2026-59178 published to the National Vulnerability Database
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-59178

Vulnerability Analysis

The ESPHome Device Builder Dashboard exposes management functions including device configuration, over-the-air firmware compilation, and access to stored Wi-Fi and API secrets. Access is gated by a single username and password pair sourced from environment variables. When the project renamed those variables from $USERNAME / $PASSWORD to $ESPHOME_USERNAME / $ESPHOME_PASSWORD, the credential-loading code was changed to read only the new names. No fallback was implemented, and no startup check verified that a previously configured operator would still be authenticated after the upgrade.

Because the dashboard treats missing credentials as "no authentication configured" rather than as a fatal error, the process starts normally and serves all endpoints without prompting for a login. A WITHOUT AUTHENTICATION banner is printed to the startup logs but is easy to miss in automated deployments.

Root Cause

The root cause is an unsafe defaults transition combined with missing input handling [CWE-306]. Rather than failing closed when no credentials are discovered, the dashboard fails open. The environment variable rename removed the only source of credentials for a broad class of existing installations, converting an authenticated deployment into an anonymous one during a routine version bump.

Attack Vector

An unauthenticated remote attacker who can reach the dashboard's TCP port after a vulnerable upgrade obtains full dashboard privileges. This includes reading YAML device configurations, extracting API keys and Wi-Fi credentials referenced from secrets.yaml, compiling and flashing arbitrary firmware to managed ESP32 and ESP8266 devices, and pivoting into the broader home network through those devices.

python

# Patch snippet: esphome_device_builder/controllers/config/settings.py
 )
 from ...helpers.api import CommandError
 from ...helpers.auth import hash_password
+from ...helpers.credentials import resolve_credentials
 from ...helpers.network_interfaces import resolve_bind_host
 from ...helpers.secrets_state import migrate_placeholder_wifi_secrets
 from ...models import ErrorCode
# Source: https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52

The fix introduces a resolve_credentials helper that accepts the deprecated $USERNAME / $PASSWORD pair as a fallback, gated on $PASSWORD being set, so an OS-provided $USERNAME alone is never adopted.

Detection Methods for CVE-2026-59178

Indicators of Compromise

The literal string WITHOUT AUTHENTICATION appearing in dashboard startup logs, indicating the instance is currently serving anonymous requests.
HTTP access logs showing successful GET / and POST /compile requests without any prior authenticated session cookie.
Unexpected firmware compilation jobs, new device entries, or modified YAML files that were not initiated by an authorized operator.
Outbound connections from ESP devices to attacker-controlled hosts following unexplained firmware updates.

Detection Strategies

Inventory all ESPHome Device Builder and esphome container instances and check installed versions against 1.0.12 (or container 2026.6.2).
Grep container and systemd logs for the WITHOUT AUTHENTICATION startup banner across all managed hosts.
Baseline the environment variables actually consumed by each running dashboard process using cat /proc/<pid>/environ to confirm whether $ESPHOME_USERNAME and $ESPHOME_PASSWORD are set.

Monitoring Recommendations

Alert on any HTTP request reaching the dashboard port from outside the designated management VLAN.
Monitor for firmware build and flash events outside normal maintenance windows.
Track changes to secrets.yaml and device configuration files in version control or with file integrity monitoring.

How to Mitigate CVE-2026-59178

Immediate Actions Required

Upgrade esphome-device-builder to 1.0.12 or the esphome container to 2026.6.2 on all affected hosts.
On any version, restore authentication immediately by setting $ESPHOME_USERNAME and $ESPHOME_PASSWORD to the same values previously used for $USERNAME and $PASSWORD.
Restrict dashboard network exposure to trusted management networks using firewall rules or a reverse proxy with its own authentication.
Rotate any API keys, OTA passwords, and Wi-Fi credentials that may have been readable during the exposure window.

Patch Information

The fix is delivered in esphome-device-builder1.0.12 via pull request #1625 and commit 9e294f7. Full details are published in GitHub Security Advisory GHSA-rrxg-g2pf-6hh4 and the 1.0.12 release notes. The patch accepts the legacy $USERNAME / $PASSWORD pair as a deprecated fallback and emits a startup deprecation warning directing operators to migrate.

Workarounds

Set both $ESPHOME_USERNAME and $ESPHOME_PASSWORD explicitly before starting the dashboard, even on patched versions, and avoid relying on the deprecated fallback.
Bind the dashboard to 127.0.0.1 and front it with an authenticating reverse proxy such as nginx or Caddy if exposure beyond localhost is required.
Do not publish the dashboard port to untrusted networks; place it behind a VPN or management-only network segment.

bash

# Configuration example: docker-compose environment for ESPHome dashboard
services:
  esphome:
    image: ghcr.io/esphome/esphome:2026.6.2
    environment:
      ESPHOME_USERNAME: "admin"
      ESPHOME_PASSWORD: "<strong-random-password>"
    ports:
      - "127.0.0.1:6052:6052"
    restart: unless-stopped