CVE-2026-59178: CWE-306: Missing Authentication for Critical Function in esphome device-builder
ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to version 1.0.12, the dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. 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. The issue is fixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated. This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names. The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12. Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version. Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open.
AI Analysis
Technical Summary
ESPHome Device Builder Dashboard versions before 1.0.12 read authentication credentials from environment variables named $USERNAME and $PASSWORD. In version 1.0.12, these were renamed to $ESPHOME_USERNAME and $ESPHOME_PASSWORD, but initially the legacy variables were dropped without fallback. This caused instances that relied on the legacy variables for authentication to become unauthenticated after upgrade, exposing the dashboard to anyone who can reach its port. The fix in 1.0.12 restores the legacy variables as a deprecated fallback, requiring both username and password to be set, and issues a deprecation warning to operators to migrate to the new variable names. The esphome container version 2026.6.2 includes this fix by updating the pinned device-builder version to 1.0.12.
Potential Impact
Without upgrading, affected instances lose authentication protection, allowing unauthenticated access to the dashboard. This can lead to full compromise of the device management interface, potentially enabling attackers to control or manipulate ESPHome devices. The CVSS score of 9.8 reflects the critical impact with network attack vector, no privileges required, no user interaction, and high confidentiality, integrity, and availability impacts.
Mitigation Recommendations
Upgrade to ESPHome Device Builder Dashboard version 1.0.12 or later, or use the esphome container version 2026.6.2 or later which includes the fix. Alternatively, immediately restore authentication by setting the new environment variables $ESPHOME_USERNAME and $ESPHOME_PASSWORD to the same values as the legacy variables. Operators should also avoid exposing the dashboard port to untrusted networks. Check startup logs for the 'WITHOUT AUTHENTICATION' banner to verify if an instance is currently unauthenticated. Operators are advised to migrate to the new environment variable names as the legacy fallback will be removed in the future.
CVE-2026-59178: CWE-306: Missing Authentication for Critical Function in esphome device-builder
Description
ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to version 1.0.12, the dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. 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. The issue is fixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated. This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names. The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12. Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version. Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open.
CVSS v3.1
Score 9.8critical
Affected software
esphome
device-builder
pkg:github/esphome/device-builderRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
ESPHome Device Builder Dashboard versions before 1.0.12 read authentication credentials from environment variables named $USERNAME and $PASSWORD. In version 1.0.12, these were renamed to $ESPHOME_USERNAME and $ESPHOME_PASSWORD, but initially the legacy variables were dropped without fallback. This caused instances that relied on the legacy variables for authentication to become unauthenticated after upgrade, exposing the dashboard to anyone who can reach its port. The fix in 1.0.12 restores the legacy variables as a deprecated fallback, requiring both username and password to be set, and issues a deprecation warning to operators to migrate to the new variable names. The esphome container version 2026.6.2 includes this fix by updating the pinned device-builder version to 1.0.12.
Potential Impact
Without upgrading, affected instances lose authentication protection, allowing unauthenticated access to the dashboard. This can lead to full compromise of the device management interface, potentially enabling attackers to control or manipulate ESPHome devices. The CVSS score of 9.8 reflects the critical impact with network attack vector, no privileges required, no user interaction, and high confidentiality, integrity, and availability impacts.
Mitigation Recommendations
Upgrade to ESPHome Device Builder Dashboard version 1.0.12 or later, or use the esphome container version 2026.6.2 or later which includes the fix. Alternatively, immediately restore authentication by setting the new environment variables $ESPHOME_USERNAME and $ESPHOME_PASSWORD to the same values as the legacy variables. Operators should also avoid exposing the dashboard port to untrusted networks. Check startup logs for the 'WITHOUT AUTHENTICATION' banner to verify if an instance is currently unauthenticated. Operators are advised to migrate to the new environment variable names as the legacy fallback will be removed in the future.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-07-02T19:53:48.829Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6aa83dab55bf5e2cf57193db
Added to database: 09/14/2026, 18:32:11 UTC
Last enriched: 09/14/2026, 18:46:51 UTC
Last updated: 09/15/2026, 04:22:07 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.