EUVD-2026-112079
GHSA-vv4j-m4vr-f3g6
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain LAN access to HA host network
-
DeliveryIdentify ingress port from HA add-on config
-
ExploitSend unauthenticated HTTP request to ingress site
-
ExecutionReceive full dashboard with no auth challenge
-
PersistSubmit malicious ESPHome config with external_components
-
ImpactExecute arbitrary code on HA host
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Hardware binding mechanism
|
| Exploitation Conditions | Exploitation requires two conditions: first, the target must be running esphome-device-builder as a Home Assistant add-on (not the standalone Docker dashboard), since only the add-on deploys in host network mode; second, the attacker must be on the same local network as the HA host, or on a network segment that has routed access to the host's LAN interface and the ingress port. No authentication, no special tools, no user interaction, and no non-default configuration are required - the vulnerability was present by default on every host-network HA add-on install. What limits exploitation: the attacker must have LAN-level network access (cannot exploit from the internet unless the ingress port is directly exposed externally, which is a separate misconfiguration). The password-gated public port (6052) is not affected. The standalone Docker dashboard (non-HA deployment) is not affected. |
| Impact | The CVSS 3.1 vector AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8) accurately characterizes the risk. Adjacent vector is appropriate because exploitation requires LAN access, not internet reachability; the attack cannot be automated at internet scale. However, AC:L and PR:N/UI:N are both correct - once on the LAN, exploitation is a single unauthenticated HTTP request requiring no user interaction or special configuration. The impact metrics (C:H/I:H/A:H) are well-supported: the ESPHome threat model documents that a dashboard-authenticated caller has host-equivalent capability including arbitrary Python execution, shell access, and full filesystem read/write over the config and data directories. No EPSS data is present in the input; no KEV listing and no public exploit code have been identified, which lowers operational urgency relative to raw CVSS. Real-world risk is highest on networks with untrusted devices (IoT segments, guest networks, shared environments), where an attacker inside the LAN perimeter could exploit this with trivial effort. Installations on fully trusted, isolated home networks behind a firewall are at materially lower risk because the attacker must already have LAN access. The vulnerability was present by default on every host-network HA add-on install; no operator misconfiguration was required. |
| Exploit ScenarioDerived | An attacker on the same LAN as the Home Assistant host - such as a compromised smart TV, an untrusted IoT device, or a guest network visitor if the HA host is not properly segmented - sends a single unauthenticated HTTP GET request directly to http://<ha-ip>:<ingress_port>/. The request reaches the ESPHome Device Builder ingress site, which performs no authentication check, and the attacker receives the full dashboard. From there, they can upload an ESPHome configuration referencing a malicious external_components URL, triggering arbitrary Python code execution at compile time on the HA host, or read and overwrite files in the Home Assistant config directory. No public exploit code has been identified, but the attack requires no specialized tooling - any browser or curl command suffices. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 10, 2026
Unauthenticated LAN access to the ESPHome Device Builder dashboard on Home Assistant add-on deployments allows any device on the local network to gain host-equivalent control with no credentials. The ingress site, which deliberately skips authentication because the HA supervisor is supposed to authenticate upstream, was bound to 0.0.0.0 instead of loopback and the supervisor gateway. Because the add-on uses host networking for mDNS, this exposed the no-auth site on the host's LAN interface, directly bypassing the supervisor's authentication layer. An attacker with LAN access can run arbitrary Python via external_components at compile time, execute arbitrary shell through compile/validation subprocesses, and read or write arbitrary files in the config and data directories. No public exploit has been identified at time of analysis.
RemediationAI
Upgrade to esphome-device-builder 1.0.10 or a newer esphome container that bundles it; this is the definitive fix per vendor advisory GHSA-vv4j-m4vr-f3g6. The fix (PR #1565, commit b6387db) restricts the ingress site bind to 127.0.0.1 and 172.30.32.1 only, and adds ingress_peer_guard which returns HTTP 403 to any TCP peer other than loopback or the supervisor (172.30.32.2), providing defense in depth. Without upgrading, the vendor recommends restricting access to the ingress port at the network layer - for example, a host firewall rule (iptables/nftables) or router ACL that blocks all traffic to the ingress port from LAN clients other than the HA host and supervisor. This mitigation prevents exploitation but does not fix the root cause; the ingress port number can be identified from the add-on's config.yaml advertised ingress_port. Additionally, keeping the HA host on a trusted, isolated LAN segment (not shared with untrusted IoT or guest devices) reduces the pool of potential attackers. Accessing the dashboard through Home Assistant's normal ingress URL remains unaffected and authenticated.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in pypi, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
ESPHome Device Builder (pkg:pip/esphome-device-builder, CWE-1327: Binding to an Unrestricted IP Address) runs as a Home Assistant add-on in host network mode to support mDNS discovery. The add-on exposes two sites: a password-gated public site on port 6052, and a trusted ingress site on the HA ingress port that skips authentication because the HA supervisor's ingress proxy is supposed to authenticate the browser before forwarding. The flaw is that the ingress site was bound to 0.0.0.0 (all interfaces) rather than only the loopback (127.0.0.1) and supervisor gateway (172.30.32.1). In host network mode, 0.0.0.0 includes the host's LAN interface, so the no-auth site was reachable by any LAN device directly, without traversing the supervisor proxy. The threat model documented in docs/THREAT_MODEL.md explicitly names 'anything that lets external traffic reach the ingress site without going through the supervisor' as a defended boundary - and this misconfiguration was exactly that breach.
Know when Docker gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Adjacent vector because LAN access is required; PR:N and AC:L because any LAN device can exploit with a single request; C/I/A all High per documented host-equivalent dashboard capability.
Primary rating from Vendor (https://github.com/esphome/device-builder).
CVSS VectorVendor: https://github.com/esphome/device-builder
DescriptionCVE.org
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.1and172.30.32.1) instead of all interfaces. Loopback serves HA core's host-network ESPHome integration, which connects to127.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-hoststill 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 nginxallow 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/
Articles & Coverage 2
Technical POC Analysis
CWE-1327, Binding to an Unrestricted IP Address.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
2 public PoC links from nuclei
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
Home Assistant deployments with the ESPHome add-on have an authentication bypass exposing them to unauthorized takeover from any local network device. No public exploit has been identified at time of analysis. An attacker with LAN access can seize full control of the system, execute arbitrary commands, and modify configurations, threatening both home and enterprise automation infrastructure.
Apply vendor patch.
Threat Model
5 threats: Elevation of Privilege, Information Disclosure, Tampering and 2 more
5-step attack chain with trust boundaries and controls
Full threat model - attack chain, trust boundaries, controls per stage and evidence - is part of the Pro and Business plans.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Path traversal in JFrog Artifactory (CWE-22) enables an authenticated low-privilege user to write data outside the inten
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in Gogs through 0.14.2 allows authenticated users (and unauthenticated attackers on default-config
Unauthenticated remote command injection in SGWBOX N3 firmware 2.0.25 lets attackers execute arbitrary operating-system
Remote code execution in Flowise before 3.1.2 allows any authenticated user (or API caller with chatflow view/update per
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Exploit-DB