https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 16:17:07 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-59178 <p>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 futu…</p> <p>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 futu…</p> https://db.gcve.eu/vuln/fkie_cve-2026-59178 https://db.gcve.eu/vuln/ghsa-rrxg-g2pf-6hh4 <p><strong>Affected:</strong> PyPI: esphome-device-builder</p> <p>## Summary</p> <p>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.</p> <p>## Details</p> <p>Credentials are resolved in `DashboardSettings.parse_args`. The fallback originally read `os.getenv(&#34;USERNAME&#34;)` and `os.getenv(&#34;PASSWORD&#34;)`. The env var rename (#265) replaced those with `ESPHOME_USERNAME` / `ESPHOME_PASSWORD` and intentionally removed the bare names, because `$USERNAME` collides with the OS login user on Linux and Windows and reading it on its own would silently promote the shell user to the dashboard username.</p> <p>The rename closed that footgun but introduced a backward compatibility break: a deployment that set only the bare names now resolves to no credentials, `using_password` is false, and the REST auth middleware and the WebSocket login gate are both disabled. The process logs a `WITHOUT AUTHENTICATION` banner at startup, but a container started detached (`docker run -d`) never surfaces it, so the exposure is silent in practice.</p> <p>This reaches users because the `dashboard` subcommand of the `ghcr.io/esphome/esphome` container runs thi…</p> <p><strong>Affected:</strong> PyPI: esphome-device-builder</p> <p>## Summary</p> <p>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.</p> <p>## Details</p> <p>Credentials are resolved in `DashboardSettings.parse_args`. The fallback originally read `os.getenv(&#34;USERNAME&#34;)` and `os.getenv(&#34;PASSWORD&#34;)`. The env var rename (#265) replaced those with `ESPHOME_USERNAME` / `ESPHOME_PASSWORD` and intentionally removed the bare names, because `$USERNAME` collides with the OS login user on Linux and Windows and reading it on its own would silently promote the shell user to the dashboard username.</p> <p>The rename closed that footgun but introduced a backward compatibility break: a deployment that set only the bare names now resolves to no credentials, `using_password` is false, and the REST auth middleware and the WebSocket login gate are both disabled. The process logs a `WITHOUT AUTHENTICATION` banner at startup, but a container started detached (`docker run -d`) never surfaces it, so the exposure is silent in practice.</p> <p>This reaches users because the `dashboard` subcommand of the `ghcr.io/esphome/esphome` container runs thi…</p> https://db.gcve.eu/vuln/ghsa-rrxg-g2pf-6hh4