CVE-2026-59177

HIGHPre-NVD 8.88.8
EchelonGraph scoreLOW confidence

This high-severity CVE scores 8.8 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). No GitHub Security Advisory CVSS is on record for this CVE.

Triggered by: Headline CVSS from the CNA's CVSS
Sources: the CNA's CVSS
8.8EG
EchelonGraph verdictPlan a fixRemediate within your standard update timelines (the SSVC decision on this page).
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: —CVSS: 8.8Exploit: None knownExposed services: Not assessed

A fix is available — apply it.

ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces

Summary

On the Home Assistant add-on, the dashboard serves a trusted ingress site that skips authentication because the supervisor authenticates the request upstream. That site was binding 0.0.0.0. The add-on runs in host network mode for mDNS, so binding all interfaces also bound the host's LAN interface, and any device on the local network could reach http://:/ and get the full dashboard with no credentials.

Details

The HA add-on ingress site is intentionally unauthenticated: the supervisor's ingress proxy authenticates the browser upstream, and the dashboard's threat model assumes the site is reachable only through the supervisor's docker network. The protection depended on physically binding the site to the supervisor, but the site bound 0.0.0.0 instead. Because the add-on uses host networking, 0.0.0.0 includes the host's LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.

This is an auth bypass on a boundary the dashboard explicitly defends. docs/THREAT_MODEL.md names, under the surface it still defends, "anything that lets external traffic reach the ingress site without going through the supervisor." The bug is exactly that.

The fix, in PR #1565, mirrors what the legacy add-on's nginx did:

  • Bind the ingress site to loopback plus the supervisor gateway (127.0.0.1 and 172.30.32.1) instead of all interfaces. Loopback serves HA core's host-network ESPHome integration, which connects to 127.0.0.1: without credentials by design; the gateway serves the supervisor's ingress proxy. The LAN interface is no longer bound; an explicit --ingress-host still overrides the bind.
  • Add ingress_peer_guard, which returns 403 to any TCP peer other than loopback or the supervisor (172.30.32.2), so another hassio bridge add-on reaching the gateway cannot use the site either. This mirrors the legacy nginx allow 127.0.0.1; allow 172.30.32.2; deny all.

The password-gated public port (6052) is not affected; this only affects the host-network HA add-on's ingress port.

Impact

Any device on the same local network as the Home Assistant host could open the dashboard with no credentials and gain its full authenticated capability. Per docs/THREAT_MODEL.md, that capability is host equivalent: an authenticated caller can run arbitrary Python at compile time via external_components:, run arbitrary shell through the compile and validation subprocesses, and read or write arbitrary files in the config and data directories. So the practical impact is full compromise of the add-on, including the Home Assistant config directory it mounts and the ESPHome devices it manages.

The exposure was present by default on every host-network HA add-on install; no operator misconfiguration was required. The standalone Docker dashboard and the password-gated public port are not affected.

Severity rationale

An unauthenticated network client reaches a dashboard site that performs no authentication of its own, and a client that reaches the dashboard has host equivalent capability. ESPHome's threat model documents that a 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 exposed surface is the Home Assistant host's local network interface rather than the internet, so the attack vector is adjacent, giving a CVSS base score of 8.8.

The rating is anchored at the worst case because the exposure was present by default on every host-network HA add-on install, the dominant deployment, and required nothing of the victim. Any party able to reach the host's local network, including a guest network that is not isolated, an untrusted IoT device, or a compromised local host, obtains full control with a single unauthenticated request.

Operational risk is lower for installations 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, and ESPHome is designed for deployment on trusted networks with the network perimeter as the primary defense. That deployment context reduces real world exposure; it does not change the base severity. The ingress site is intended to require the supervisor's authentication even on the local network, and the fix restores that.

Patches

Fixed in device-builder 1.0.10 (PR #1565). The ingress site is bound to loopback and the supervisor gateway only, and a peer guard rejects any TCP peer other than loopback or the supervisor regardless of --ingress-host. The esphome container delivers the fix by bundling device-builder 1.0.10 or newer.

Workarounds

Upgrade to 1.0.10 or newer (an esphome container bundling device-builder 1.0.10+). Without upgrading, restrict access to the add-on's ingress port at the network layer, for example a host or router firewall rule that allows only the Home Assistant host and the supervisor to reach it, and keep the Home Assistant host on a trusted LAN segment. Accessing the dashboard through Home Assistant's normal ingress URL is unaffected and stays authenticated.

Resources

  • Fix: esphome/device-builder#1565
  • Ingress site introduction: esphome/device-builder#25
  • Originating investigation: esphome/device-builder#1560
  • ESPHome security best practices: https://esphome.io/guides/security_best_practices/

CVSS v3
8.8
EG Score
8.8HIGHlow confidence
EG Risk
40
EG Risk 40/100

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed (value × EchelonGraph’s weight)
Severity88% × 45%
The EG Score, 8.8 of 10.
Exploitation0% × 40%
No KEV listing, EG-KEV tier or EPSS when EchelonGraph scored this CVE.
Automatability0% × 15%
CISA's BOD 26-04 default: no one has published Automatable for this CVE, and CISA treats it as “no” for a CVE not in KEV.
SSVC (CISA's decision table, applied by EchelonGraph): Track at low or medium mission impact; Track* at high (mission-essential systems).
Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE.
Action: A fix is available. Apply it within your standard update timelines.
EPSS PROB
—
EPSS %ILE
—
KEV
Not listed

SSVC (CISA's decision table, applied by EchelonGraph)Track at low or medium mission impact; Track* at high (mission-essential systems).

A fix is available. Apply it within your standard update timelines.

Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

September 9, 2026

Last Modified

September 9, 2026

Vendor Advisories for CVE-2026-59177(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(1 across 1 ecosystem)
PyPI(1)
PackageVulnerable rangeFix by version rangeDependents
esphome-device-builder0.1.0b10 ... 1.0.9 (125 versions)
  • every version up to 1.0.10: fixed in 1.0.10
—

Data Freshness Timeline

(refreshed 4× in last 7d / 6× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-10-12 15:52 UTCEG score recompute
  2. 2026-10-11 19:36 UTCEG score recompute
  3. 2026-10-11 16:51 UTCEG score recompute
  4. 2026-10-11 14:14 UTCEG score recompute
  5. 2026-09-29 04:02 UTCEG score recompute
  6. 2026-09-16 08:54 UTCEG score recompute
  7. 2026-09-10 00:25 UTCEG score recomputeFirst assessed: 8.8 HIGH

Public detection templates

(1 reference)

A public Nuclei detection template is referenced for this CVE. A detection template checks whether a system is affected; it is not necessarily exploit code.

  • Nucleihttp/cves/2026/CVE-2026-59177.yaml
    Published Sep 15, 2026

    ESPHome Device Builder <1.0.10 - Unauthenticated Dashboard Access

    Open source ↗

Related CVEs(same product)

Same product

1 shown

PyPI:esphome-device-builder

Frequently asked(4)

What is CVE-2026-59177?
CVE-2026-59177 is a high-severity vulnerability; its CVE record was published on September 9, 2026. ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces Summary On the Home Assistant add-on, the dashboard serves a trusted ingress site that skips authentication because the supervisor authenticates the request upstream. That site…
When was the CVE record for CVE-2026-59177 published?
The CVE record for CVE-2026-59177 was published on September 9, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of September 9, 2026; the record at its source may have been updated since.
What is the CVSS score of CVE-2026-59177?
CVE-2026-59177 has a CVSS base score of 8.8 (the CNA's own assessment, by github_m; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-59177?
A fix for CVE-2026-59177 is available: update to the fixed version the vendor names in its advisory. The vendor advisories EchelonGraph has for CVE-2026-59177 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-59177

Explore →

Is Your Infrastructure Affected by CVE-2026-59177?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.

Book a Demo →Browse All CVEs