CVE-2026-59178
CriticalCVSS 9.8Summary
In ESPHome Device Builder Dashboard prior to version 1.0.12, authentication environment variables were renamed from $USERNAME/$PASSWORD to $ESPHOME_USERNAME/$ESPHOME_PASSWORD with no fallback. As a result, instances protected with the old names lost authentication after upgrade and the dashboard became open to anyone who could reach its port. The issue is fixed in 1.0.12, which restores the old names as a deprecated fallback with a startup warning.
Risk Assessment
After an upgrade, the dashboard may start without authentication, allowing unauthorized parties to access the ESPHome management panel and device configuration. The risk is especially high when the dashboard port is exposed to untrusted networks.
Recommendation
Upgrade to version 1.0.12 or later (in the esphome container: release 2026.6.2). If upgrading is not possible, immediately set the new $ESPHOME_USERNAME and $ESPHOME_PASSWORD variables to the same values and check startup logs for the "WITHOUT AUTHENTICATION" banner.
Related vulnerabilities
- CVE-2026-12944Critical
IBM Langflow OSS 1.0.0 through 1.10.0 allows attackers to execute arbitrary Python code with root privileges (UID=0) on the Langflow server by submitting components containing socket or urllib imports. This enables AWS credential theft via IMDSv1 SSRF, arbitrary file exfiltration from the container filesystem, and lateral movement to internal services (PostgreSQL, Redis) within the Docker network. The scanner incorrectly returns "validated": true, providing a false security signal.
- CVE-2026-67399Critical
Deserialization of untrusted data in WHMCS 9.0.0 before 9.0.8 and 8.0.0 before 8.13.7 allows remote attackers to execute arbitrary code.
- CVE-2026-65414Critical
An out-of-bounds write issue in Apple products was addressed with improved bounds checking. A remote attacker may be able to cause unexpected app termination or arbitrary code execution. This issue is fixed in iOS 26.7, iPadOS 26.7, iOS 27, iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, and watchOS 27.
- CVE-2026-53713Critical
Envoy Gateway prior to 1.7.4 and 1.8.1 does not collapse redundant separators in to_absolute_normalized_path in internal/gatewayapi/luavalidator/security.lua before is_critical_path evaluates Lua submitted through EnvoyExtensionPolicy during default Strict validation. Linux resolves a double-slash absolute path as the corresponding single-slash path, but the validator does not match the redundant-separator form, allowing submitted Lua to read arbitrary files from the gateway controller pod. Exposed files can include Kubernetes service-account tokens, TLS certificates, and process environment data, and the disclosed credentials can provide access to sensitive Kubernetes API Server or Gateway xDS server information. This issue is fixed in versions 1.7.4 and 1.8.1.
- CVE-2026-55209Critical
resdata prior to 6.2.9 insufficiently validates numeric fields, grid dimensions, keyword sizes, and array indexes while parsing untrusted GRDECL files in lib/resdata/rd_kw_grdecl.cpp and lib/resdata/rd_grid.cpp. Malformed COORD, ZCORN, CORSNUM, ACTNUM, or MAPAXES data can reach rd_grid_alloc_GRDECL_kw__ with inconsistent lengths, while unbounded floating-point conversion can exceed the intended parser buffer. In a network service that accepts untrusted GRDECL files, these conditions can cause a classic buffer overflow, out-of-bounds reads, invalid array access, NULL pointer dereference, memory corruption, or service termination. This issue is fixed in version 6.2.9.
- CVE-2026-54334Critical
UEFI Firmware Parser prior to 1.14 has a flaw in ReadCLen() in uefi_firmware/compression/Tiano/Decompress.c where reading Number from GetBits(Sd, CBIT) with CBIT = 9 can obtain 511 entries for the 510-element Sd->mCLen heap array because its loop does not enforce Index < NC. The CharC == 2 run-length path can additionally request up to 531 zero writes through Sd->mCLen[Index++] = 0. Crafted Tiano or EFI compressed firmware can corrupt heap memory, deterministically crash the parsing process, and potentially execute code. This issue is fixed in version 1.14.
- CVE-2026-54333Critical
UEFI Firmware Parser prior to 1.14 has a flaw in MakeTable() in uefi_firmware/compression/Tiano/Decompress.c that does not validate that bit-length values read from a crafted Tiano or EFI compressed firmware bitstream remain within the expected range from 0 through 16. The parsing path CompressedSection.process() to efi_compressor.TianoDecompress() to TianoDecompress() to ReadPTLen() to MakeTable() can write beyond the stack-allocated Count[17] array and related decode tables. The resulting stack corruption deterministically crashes the parsing process and may permit code execution. This issue is fixed in version 1.14.
- CVE-2026-50006Critical
Anyquery prior to 0.4.5 forwards unauthenticated SQL from its MySQL-compatible server port to SQLite without restricting ATTACH DATABASE filesystem targets. A remote attacker can select any path writable by the Anyquery server process, cause SQLite to create a database file there, and place attacker-controlled table content in that file. This permits arbitrary file creation or overwrite, causing filesystem integrity loss and denial of service; remote code execution is possible only when another service interprets the written file or the process has a suitably privileged writable target. This issue is fixed in version 0.4.5.
- CVE-2026-16338Critical
IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to perform an arbitrary file write due to improper validation of file paths.
- CVE-2026-90945Critical
Crawlab through 0.6.3 uses a hard-coded HMAC-SHA256 secret for JWT token signing that cannot be overridden via configuration or environment variables. Unauthenticated attackers can forge valid administrator tokens to access administrative APIs and execute code on worker nodes.
Original NVD description (English source)
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.