pypi package report

Is esphome safe?

6 known vulnerabilities, worst severity HIGH.

// reach

54 direct dependencies

12 carry known advisories, worst CRITICAL

0 packages depend on it

an advisory here reaches each of them

    Create a free accountfor every dependency path, dependent and what to upgrade
    // ai model usage

    No published models are known to use this package.


    cvss
    8.1
    high

    CVSS v3.1 base score out of 10

    epss
    1.5%
    medium

    chance of exploitation in 30 days, 75th percentile of all CVEs

    xyz score
    3.9
    low

    CyberXYZ composite out of 10

    fig. 01 — GHSA-mxh2-ccgj-8635, the advisory selected below

    // 6 advisories

    GHSA-mxh2-ccgj-8635

    HIGHGitHub ratingCVE-2025-57808
    // summary

    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.

    // details

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

    // poc

    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 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 web_server, 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 web_server component on ESP-IDF devices may be prudent, particularly if OTA updates through web_server are enabled.

    // cvss v3.1 vector

    CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

    Attack vector
    Adjacent
    Attack complexity
    Low
    Privileges required
    None
    User interaction
    None
    Scope
    Unchanged
    Confidentiality
    High
    Integrity
    High
    Availability
    None

    Checked 2026-11-07 at 21:51 UTC. The most recent advisory here was published 2026-01-21. Updated continuously from NVD, GHSA, OSV and CNA feeds.

    Think a verdict here is wrong? Tell us — we respond within 2 business days.