On the ESP-IDF platform, ESPHome's web_server 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 web_server functionality (including OTA, if enabled) without knowing any information about the correct username or password.
The HTTP basic auth check in web_server_idf's AsyncWebServerRequest::authenticate only compares up to auth.value().size() - auth_prefix_len 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).
Configure ESPHome as follows:
esp32:
board: ...
framework:
type: esp-idf
web_server:
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...
1.10.11.11.01.11.0b11.11.0b21.11.0b31.11.11.11.21.12.01.12.0b11.12.0b2+484 more2025.8.1Exploitability
AV:AAC:LPR:NUI:NScope
S:UImpact
C:HI:HA:NCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N