Summary

The dashboard reads its authentication credentials from $ESPHOMEUSERNAME and $ESPHOMEPASSWORD. 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.

Details

Credentials are resolved in DashboardSettings.parseargs. The fallback originally read os.getenv("USERNAME") and os.getenv("PASSWORD"). The env var rename (#265) replaced those with ESPHOMEUSERNAME / ESPHOMEPASSWORD 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.

The rename closed that footgun but introduced a backward compatibility break: a deployment that set only the bare names now resolves to no credentials, usingpassword 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.

This reaches users because the dashboard subcommand of the ghcr.io/esphome/esphome container runs this package: the container pins esphome-device-builder and execs it for dashboard, inheriting whatever env the operator passed. The standalone Docker path runs without --ha-addon, so it is the affected path. Home Assistant add on installs are not affected; they pass --ha-addon and authenticate through the supervisor ingress proxy, and do not use these env vars.

The rename was tagged as a breaking change but was not surfaced in the 2026.6.0 changelog, so operators had no signal to migrate before upgrading.

Impact

An unauthenticated client with network access to the dashboard port can manage devices, including editing configurations and flashing firmware. Only deployments that relied on the bare $USERNAME / $PASSWORD env vars for authentication are affected; deployments using --username / --password, the new $ESPHOME env vars, or HA add on ingress are not.

Severity rationale

An unauthenticated network client crosses the dashboard's only security boundary, and a client past that boundary has host equivalent capability. ESPHome's threat model documents that an authenticated dashboard caller can run arbitrary code at compile time and read or write files in the config and data directories, so confidentiality, integrity, and availability are all High, with no credentials, no user interaction, and low attack complexity.

The base score is rated for the worst case, an internet reachable dashboard. That worst case is the right anchor here, because this issue only affects operators who had deliberately configured a dashboard password, and setting a password is the control an operator uses precisely when the dashboard is reachable by parties they do not fully trust, including a deployment exposed to the internet or a network segment shared with untrusted devices. For the affected population a trusted network cannot be assumed, so authentication should be restored as urgent.

Operational risk is lower for the subset of affected installations that run on a single trusted home or business network behind a firewall, since reaching the dashboard there requires an attacker who is already inside that network. ESPHome is designed for deployment on trusted networks with the network perimeter as the primary defense, so that deployment context reduces real world exposure; it does not lower the base severity, and operators on shared, guest, or internet reachable networks remain at full risk.

Patches

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 $ESPHOMEUSERNAME / $ESPHOMEPASSWORD. 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.

Workarounds

Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version:

ESPHOMEUSERNAME=<your-username> ESPHOMEPASSWORD=<your-password>

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.

References

- Original report against the esphome container: GHSA-446m-c8jp-v37m - Env var rename that introduced the regression: esphome/device-builder#265 - 2026.6.0 changelog (breaking change was not documented): https://esphome.io/changelog/2026.6.0 - Old setup documentation that used the bare names: https://esphome.io/guides/gettingstartedcommandline

ESPHome through 2026.7.0-dev contains an operator-precedence bug in the cv.url validator in esphome/configvalidation.py. Because binds tighter than , any file: URI passes validation regardless of netloc. This validator gates the field of the externalcomponents YAML directive's git source schema, which is passed to (git supports file:// natively).

Summary Security misconfiguration in edit configuration file API in dashboard component of ESPHome version 2023.12.9 (command line installation) allows authenticated remote attackers to read and write arbitrary files under the configuration directory rendering remote code execution possible.

Details It is possible to abuse this path traversal vulnerability both in command line installation and Home Assistant add-on, but it is possible to read and write files only under the configuration directory.

The vulnerability is present and exploitable in the command line installation, but it was not possible to confirm an impact in the home assistant add-on version.

PoC <img width="482" alt="/edit?configuration=/config/.esphome/esphome.json" src="https://github.com/esphome/esphome/assets/115887876/d2da3180-976e-4bed-b4b9-35ac960a7fb4"> <br/>

<img width="344" alt="/edit?configuration=/config/.esphome/build/test01/src/main.cpp (firmware for board named test01)" src="https://github.com/esphome/esphome/assets/115887876/707fb6d7-d4a8-461e-bbb7-05382471e925"> <br/>

<img width="482" alt="RCE payload POST request on /edit?configuration=.esphome/platformio/packages/tool-esptoolpy/esptool.py" src="https://github.com/esphome/esphome/assets/115887876/c6cb28d8-352d-4fea-b77a-705f63be94e3"> <br/>

<img width="482" alt="Arbitrary code execution during ESP board flashing" src="https://github.com/esphome/esphome/assets/115887876/5eb0f14c-ceb2-4b15-8898-c02c610763d1">

Impact The issue gives read and write access to files under the configuration directory and allows malicious users to write arbitrary code in python scripts executed during the compilation and flashing of firmwares for ESP boards.

If chained with GHSA-9p43-hj5j-96h5 and GHSA-5925-88xh-6h99, this issue could allow an unauthenticated remote user to gain remote code execution on the machine hosting the dashboard.

It also allows accessing sensitive information such as esphome.json and board firmware source code allowing a user to modify the board firmware, and leaking secrets such as: WiFi network credentials, fallback hotspot WiFi credentials, OTA component authentication password and API encryption key.

Credits Spike Reply Cybersecurity Team

Impact

Anyone with webserver enabled and HTTP basic auth configured on 2021.9.1 or older

webserver allows OTA update without checking user defined basic auth username & password

Patches

Patch released in 2021.9.2

Workarounds

Disable/remove webserver

Summary An integer overflow in the API component's protobuf decoder allows denial-of-service attacks when API encryption is not used.

Details The bounds check ptr + fieldlength > end in components/api/proto.cpp can overflow when a malicious client sends a large fieldlength value. This affects all ESPHome device platforms (ESP32, ESP8266, RP2040, LibreTiny). The overflow bypasses the out-of-bounds check, causing the device to read invalid memory and crash.

When using the plaintext API protocol, this attack can be performed without authentication. When noise encryption is enabled, knowledge of the encryption key is required.

Affected Versions ESPHome 2025.9.0 through 2025.12.6

Mitigation - Upgrade to ESPHome 2025.12.7 or later (or 2026.1.0b3 or later) - Enable API encryption with a unique key per device - Follow the Security Best Practices

Severity Low - Users following Security Best Practices with API encryption enabled are not affected without knowledge of the encryption key.

Impact Denial-of-service. An attacker with network access to port 6053 can crash and reboot the device.

Credits Thanks to @Mat931 for responsibly reporting this vulnerability.

Summary Edit configuration file API in dashboard component of ESPHome version 2023.12.9 (command line installation and Home Assistant add-on) serves unsanitized data with “Content-Type: text/html; charset=UTF-8”, allowing remote authenticated user to inject arbitrary web script and exfiltrate session cookies via Cross-Site scripting (XSS).

Credits Spike Reply Cybersecurity Teams

Details It is possible for a malicious authenticated user to inject arbitrary Javascript in configuration files using a POST request to the /edit endpoint, the configuration parameter allows to specify the file to write.

To trigger the XSS vulnerability, the victim must visit the page /edit?configuration=[xss file].

PoC

To reproduce the issue, it is possible to perform a POST request to inject the payload:

request: POST /edit?configuration=xss.yaml HTTP/1.1 Host: localhost:6052 User-Agent: Mozilla/5.0 (X11; Linux x8664; rv:109.0) Gecko/20100101 Firefox/116.0 Accept: / Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: http://localhost:6052/ Connection: close Cookie: authenticated=[replace with valid cookie] Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Content-Length: 40 <script>alert(document.cookie);</script>

response: HTTP/1.1 200 OK Server: TornadoServer/6.3.3 Content-Type: text/html; charset=UTF-8 Date: Thu, 30 Nov 2023 11:02:27 GMT Content-Length: 0 Connection: close

And subsequently trigger the XSS with a GET request to the same endpoint:

request: GET /edit?configuration=xss.yaml HTTP/1.1 Host: localhost:6052 User-Agent: Mozilla/5.0 (X11; Linux x8664; rv:109.0) Gecko/20100101 Firefox/116.0 Accept: / Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: http://localhost:6052/ Connection: close Cookie: authenticated=2|1:0|10:1701341719|13:authenticated|4:eWVz|0907127d7274094cc5a2490b95becf5c11fd52b8c3ee3655d65fe9fda099108c Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Content-Length: 0

response: HTTP/1.1 200 OK Server: TornadoServer/6.3.3 Content-Type: text/html; charset=UTF-8 Date: Thu, 30 Nov 2023 11:04:12 GMT Etag: "ec6c9889f5c9a6c8e9d2d5e4ce1b1a85e6e7da2b" Content-Length: 40 Connection: close <script>alert(document.cookie);</script>

Impact Abusing this vulnerability a malicious actor could perform operations on the dashboard on the behalf of a logged user, access sensitive information, create, edit and delete configuration files and flash firmware on managed boards. In addition to this, cookies are not correctly secured, allowing the exfiltration of session cookie values.

Credits Spike Reply Cybersecurity Team

Summary On the ESP-IDF platform, ESPHome's webserver authentication check can pass incorrectly when the client-supplied base64-encoded Authorization value is empty or is a substring of the correct value (e.g., correct username with partial password). This allows access to webserver functionality (including OTA, if enabled) without knowing any information about the correct username or password.

Details The HTTP basic auth check in webserveridf's AsyncWebServerRequest::authenticate only compares up to auth.value().size() - authprefixlen bytes of the base64-encoded user:pass string. This means a client-provided valuer like dXNlcjpz (user:s) will pass the check when the correct value is much longer, e.g., dXNlcjpzb21lcmVhbGx5bG9uZ3Bhc3M= (user:somereallylongpass).

Furthermore, the check will also pass when the supplied value is the empty string, which removes the need to know (or brute force) the username. A browser won't generally issue such a request, but it can easily be done by manually constructing the Authorizaztion request header (e.g., via curl).

PoC Configure ESPHome as follows:

yaml esp32: board: ... framework: type: esp-idf webserver: auth: username: user password: somereallylongpass

In a browser, you can correctly log in by supplying username user and password somereallylongpass... but you can also incorrectly log in by supplying substrings of the password whose base64-encoded digest matches a prefix of the correct digest. (For example, I was able to log into an ESPHome device so configured by supplying password some... or even just s.)

You can also use a tool like curl to manually set an Authorization request header that always passes the check without any knowledge of the username:

$ curl -D- http://example.local/ HTTP/1.1 401 Unauthorized ...

$ curl -D- -H 'Authorization: Basic ' http://example.local/ HTTP/1.1 200 OK ...

Impact This vulnerability effectively nullifies basic auth support for the ESP-IDF webserver, allowing auth bypass from another device on the local network with no knowledge of the correct username or password required.

Remediation This vulnerability is fixed in 2025.8.1 and later.

For older versions, disabling the webserver component on ESP-IDF devices may be prudent, particularly if OTA updates through webserver are enabled.