How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

383,304

Total vulnerabilities in the database

CVE-2026-59177 — esphome-device-builder

Binding to an Unrestricted IP Address

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://<ha-ip>:<ingress_port>/ 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:<ingress_port> 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/

Published: Sep 9, 2026
Updated: Sep 10, 2026
CVE: CVE-2026-59177
GHSA: GHSA-vv4j-m4vr-f3g6
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 8.8
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CWEs:

CWE-1327

Affected Software
References

Software	Affected versions
esphome-device-builder	`< 1.0.10`

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.