Vulnerability-Lookup

CVE-2026-59177 (GCVE-0-2026-59177)

Vulnerability from cvelistv5 – Published: 2026-10-28 13:12 – Updated: 2026-10-28 13:12

Title

ESPHome Device Builder allows unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces

Summary

ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to 1.0.10, the `Home Assistant` add-on's trusted `ingress` site binds to `0.0.0.0` while intentionally skipping dashboard authentication because the supervisor is expected to authenticate requests upstream. Host networking, required for mDNS, also binds this no-auth site to the `Home Assistant` host's LAN interface. Any device on that local network can therefore connect directly to the `ingress` port, bypass the supervisor, and obtain the full dashboard without credentials or operator misconfiguration. Dashboard capability includes compile-time Python execution through `external_components:`, shell execution through compile and validation subprocesses, and arbitrary access to configuration and data files, compromising the mounted `Home Assistant` configuration and managed ESPHome devices. The standalone Docker dashboard and the password-gated public port 6052 are not affected. This issue is fixed in version 1.0.10.

Severity

8.8 (High)


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

CWE

CWE-1327 - Binding to an Unrestricted IP Address

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 8010 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/esphome/device-builder/securit…	x_refsource_CONFIRM
https://github.com/esphome/device-builder/pull/1565	x_refsource_MISC
https://github.com/esphome/device-builder/commit/…	x_refsource_MISC
https://github.com/esphome/device-builder/release…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version	CPE status
esphome	device-builder	Affected: < 1.0.10	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "device-builder",
          "vendor": "esphome",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.0.10"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to 1.0.10, the `Home Assistant` add-on\u0027s trusted `ingress` site binds to `0.0.0.0` while intentionally skipping dashboard authentication because the supervisor is expected to authenticate requests upstream. Host networking, required for mDNS, also binds this no-auth site to the `Home Assistant` host\u0027s LAN interface. Any device on that local network can therefore connect directly to the `ingress` port, bypass the supervisor, and obtain the full dashboard without credentials or operator misconfiguration. Dashboard capability includes compile-time Python execution through `external_components:`, shell execution through compile and validation subprocesses, and arbitrary access to configuration and data files, compromising the mounted `Home Assistant` configuration and managed ESPHome devices. The standalone Docker dashboard and the password-gated public port 6052 are not affected. This issue is fixed in version 1.0.10."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "ADJACENT_NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-1327",
              "description": "CWE-1327: Binding to an Unrestricted IP Address",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T13:12:14.620Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6"
        },
        {
          "name": "https://github.com/esphome/device-builder/pull/1565",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/esphome/device-builder/pull/1565"
        },
        {
          "name": "https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1"
        },
        {
          "name": "https://github.com/esphome/device-builder/releases/tag/1.0.10",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/esphome/device-builder/releases/tag/1.0.10"
        }
      ],
      "source": {
        "advisory": "GHSA-vv4j-m4vr-f3g6",
        "discovery": "UNKNOWN"
      },
      "title": "ESPHome Device Builder allows unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-59177",
    "datePublished": "2026-10-28T13:12:14.620Z",
    "dateReserved": "2026-07-02T19:53:48.829Z",
    "dateUpdated": "2026-10-28T13:12:14.620Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-59177",
      "date": "2026-10-30",
      "epss": "0.01168",
      "percentile": "0.67337"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "device-builder",
                "vendor": "esphome",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003c 1.0.10"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to 1.0.10, the `Home Assistant` add-on\u0027s trusted `ingress` site binds to `0.0.0.0` while intentionally skipping dashboard authentication because the supervisor is expected to authenticate requests upstream. Host networking, required for mDNS, also binds this no-auth site to the `Home Assistant` host\u0027s LAN interface. Any device on that local network can therefore connect directly to the `ingress` port, bypass the supervisor, and obtain the full dashboard without credentials or operator misconfiguration. Dashboard capability includes compile-time Python execution through `external_components:`, shell execution through compile and validation subprocesses, and arbitrary access to configuration and data files, compromising the mounted `Home Assistant` configuration and managed ESPHome devices. The standalone Docker dashboard and the password-gated public port 6052 are not affected. This issue is fixed in version 1.0.10."
          }
        ],
        "id": "CVE-2026-59177",
        "lastModified": "2026-10-28T15:24:56.033",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "ADJACENT_NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 8.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 2.8,
              "impactScore": 5.9,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-10-28T14:17:04.747",
        "references": [
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/esphome/device-builder/pull/1565"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/esphome/device-builder/releases/tag/1.0.10"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-1327"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Primary"
          }
        ]
      }
    }
  }
}

FKIE_CVE-2026-59177

Vulnerability from fkie_nvd - Published: 2026-10-28 14:17 - Updated: 2026-10-28 15:24

Severity

8.8 (High) - CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1
	security-advisories@github.com	https://github.com/esphome/device-builder/pull/1565
	security-advisories@github.com	https://github.com/esphome/device-builder/releases/tag/1.0.10
	security-advisories@github.com	https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "device-builder",
          "vendor": "esphome",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.0.10"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to 1.0.10, the `Home Assistant` add-on\u0027s trusted `ingress` site binds to `0.0.0.0` while intentionally skipping dashboard authentication because the supervisor is expected to authenticate requests upstream. Host networking, required for mDNS, also binds this no-auth site to the `Home Assistant` host\u0027s LAN interface. Any device on that local network can therefore connect directly to the `ingress` port, bypass the supervisor, and obtain the full dashboard without credentials or operator misconfiguration. Dashboard capability includes compile-time Python execution through `external_components:`, shell execution through compile and validation subprocesses, and arbitrary access to configuration and data files, compromising the mounted `Home Assistant` configuration and managed ESPHome devices. The standalone Docker dashboard and the password-gated public port 6052 are not affected. This issue is fixed in version 1.0.10."
    }
  ],
  "id": "CVE-2026-59177",
  "lastModified": "2026-10-28T15:24:56.033",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "ADJACENT_NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 8.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 5.9,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-10-28T14:17:04.747",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/pull/1565"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/releases/tag/1.0.10"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-1327"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

GHSA-VV4J-M4VR-F3G6

Vulnerability from github – Published: 2026-09-09 23:51 – Updated: 2026-09-09 23:51

Summary

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

Details

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/

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "esphome-device-builder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-09T23:51:25Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOn 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\u0027s LAN interface, and any device on the local network could reach `http://\u003cha-ip\u003e:\u003cingress_port\u003e/` and get the full dashboard with no credentials.\n\n## Details\n\nThe HA add-on ingress site is intentionally unauthenticated: the supervisor\u0027s ingress proxy authenticates the browser upstream, and the dashboard\u0027s threat model assumes the site is reachable only through the supervisor\u0027s 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\u0027s LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.\n\nThis 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.\n\nThe fix, in PR #1565, mirrors what the legacy add-on\u0027s nginx did:\n\n- 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\u0027s host-network ESPHome integration, which connects to `127.0.0.1:\u003cingress_port\u003e` without credentials by design; the gateway serves the supervisor\u0027s ingress proxy. The LAN interface is no longer bound; an explicit `--ingress-host` still overrides the bind.\n- 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`.\n\nThe password-gated public port (6052) is not affected; this only affects the host-network HA add-on\u0027s ingress port.\n\n## Impact\n\nAny 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.\n\nThe 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.\n\n\n## Severity rationale\n\nAn 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\u0027s [threat model](https://github.com/esphome/device-builder/blob/main/docs/THREAT_MODEL.md) 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\u0027s local network interface rather than the internet, so the attack vector is adjacent, giving a CVSS base score of 8.8.\n\nThe 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\u0027s 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.\n\nOperational 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](https://esphome.io/guides/security_best_practices/) 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\u0027s authentication even on the local network, and the fix restores that.\n\n## Patches\n\nFixed 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.\n\n## Workarounds\n\nUpgrade to 1.0.10 or newer (an esphome container bundling device-builder 1.0.10+). Without upgrading, restrict access to the add-on\u0027s 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\u0027s normal ingress URL is unaffected and stays authenticated.\n\n## Resources\n\n- Fix: esphome/device-builder#1565\n- Ingress site introduction: esphome/device-builder#25\n- Originating investigation: esphome/device-builder#1560\n- ESPHome security best practices: https://esphome.io/guides/security_best_practices/",
  "id": "GHSA-vv4j-m4vr-f3g6",
  "modified": "2026-09-09T23:51:25Z",
  "published": "2026-09-09T23:51:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/pull/1565"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/esphome/device-builder"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces"
}

PYSEC-2026-3834

Vulnerability from pysec - Published: 2026-09-10 09:45 - Updated: 2026-09-10 11:02

Details

Summary

Details

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

Severity rationale

Patches

Workarounds

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/

Severity

8.8 (High)


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

Impacted products

Name	purl
esphome-device-builder	pkg:pypi/esphome-device-builder

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "esphome-device-builder",
        "purl": "pkg:pypi/esphome-device-builder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.1.0b10",
        "0.1.0b100",
        "0.1.0b101",
        "0.1.0b102",
        "0.1.0b103",
        "0.1.0b104",
        "0.1.0b105",
        "0.1.0b106",
        "0.1.0b107",
        "0.1.0b108",
        "0.1.0b109",
        "0.1.0b11",
        "0.1.0b110",
        "0.1.0b111",
        "0.1.0b112",
        "0.1.0b113",
        "0.1.0b114",
        "0.1.0b115",
        "0.1.0b116",
        "0.1.0b117",
        "0.1.0b118",
        "0.1.0b119",
        "0.1.0b12",
        "0.1.0b13",
        "0.1.0b14",
        "0.1.0b15",
        "0.1.0b16",
        "0.1.0b17",
        "0.1.0b18",
        "0.1.0b19",
        "0.1.0b20",
        "0.1.0b21",
        "0.1.0b22",
        "0.1.0b23",
        "0.1.0b24",
        "0.1.0b25",
        "0.1.0b26",
        "0.1.0b27",
        "0.1.0b28",
        "0.1.0b29",
        "0.1.0b30",
        "0.1.0b31",
        "0.1.0b32",
        "0.1.0b33",
        "0.1.0b34",
        "0.1.0b35",
        "0.1.0b36",
        "0.1.0b37",
        "0.1.0b38",
        "0.1.0b39",
        "0.1.0b40",
        "0.1.0b41",
        "0.1.0b42",
        "0.1.0b43",
        "0.1.0b44",
        "0.1.0b45",
        "0.1.0b46",
        "0.1.0b47",
        "0.1.0b48",
        "0.1.0b49",
        "0.1.0b50",
        "0.1.0b51",
        "0.1.0b52",
        "0.1.0b53",
        "0.1.0b54",
        "0.1.0b55",
        "0.1.0b56",
        "0.1.0b57",
        "0.1.0b58",
        "0.1.0b59",
        "0.1.0b60",
        "0.1.0b61",
        "0.1.0b62",
        "0.1.0b63",
        "0.1.0b64",
        "0.1.0b65",
        "0.1.0b66",
        "0.1.0b67",
        "0.1.0b68",
        "0.1.0b69",
        "0.1.0b70",
        "0.1.0b71",
        "0.1.0b72",
        "0.1.0b73",
        "0.1.0b74",
        "0.1.0b75",
        "0.1.0b76",
        "0.1.0b77",
        "0.1.0b78",
        "0.1.0b79",
        "0.1.0b80",
        "0.1.0b81",
        "0.1.0b82",
        "0.1.0b83",
        "0.1.0b84",
        "0.1.0b85",
        "0.1.0b86",
        "0.1.0b87",
        "0.1.0b88",
        "0.1.0b89",
        "0.1.0b90",
        "0.1.0b91",
        "0.1.0b92",
        "0.1.0b93",
        "0.1.0b94",
        "0.1.0b95",
        "0.1.0b96",
        "0.1.0b97",
        "0.1.0b98",
        "0.1.0b99",
        "1.0.0",
        "1.0.1",
        "1.0.10b1",
        "1.0.10b2",
        "1.0.2b1",
        "1.0.2b2",
        "1.0.2b3",
        "1.0.2b4",
        "1.0.3",
        "1.0.4",
        "1.0.5",
        "1.0.6",
        "1.0.7",
        "1.0.8",
        "1.0.9"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59177",
    "GHSA-vv4j-m4vr-f3g6"
  ],
  "details": "## Summary\n\nOn 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\u0027s LAN interface, and any device on the local network could reach `http://\u003cha-ip\u003e:\u003cingress_port\u003e/` and get the full dashboard with no credentials.\n\n## Details\n\nThe HA add-on ingress site is intentionally unauthenticated: the supervisor\u0027s ingress proxy authenticates the browser upstream, and the dashboard\u0027s threat model assumes the site is reachable only through the supervisor\u0027s 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\u0027s LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.\n\nThis 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.\n\nThe fix, in PR #1565, mirrors what the legacy add-on\u0027s nginx did:\n\n- 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\u0027s host-network ESPHome integration, which connects to `127.0.0.1:\u003cingress_port\u003e` without credentials by design; the gateway serves the supervisor\u0027s ingress proxy. The LAN interface is no longer bound; an explicit `--ingress-host` still overrides the bind.\n- 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`.\n\nThe password-gated public port (6052) is not affected; this only affects the host-network HA add-on\u0027s ingress port.\n\n## Impact\n\nAny 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.\n\nThe 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.\n\n\n## Severity rationale\n\nAn 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\u0027s [threat model](https://github.com/esphome/device-builder/blob/main/docs/THREAT_MODEL.md) 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\u0027s local network interface rather than the internet, so the attack vector is adjacent, giving a CVSS base score of 8.8.\n\nThe 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\u0027s 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.\n\nOperational 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](https://esphome.io/guides/security_best_practices/) 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\u0027s authentication even on the local network, and the fix restores that.\n\n## Patches\n\nFixed 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.\n\n## Workarounds\n\nUpgrade to 1.0.10 or newer (an esphome container bundling device-builder 1.0.10+). Without upgrading, restrict access to the add-on\u0027s 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\u0027s normal ingress URL is unaffected and stays authenticated.\n\n## Resources\n\n- Fix: esphome/device-builder#1565\n- Ingress site introduction: esphome/device-builder#25\n- Originating investigation: esphome/device-builder#1560\n- ESPHome security best practices: https://esphome.io/guides/security_best_practices/",
  "id": "PYSEC-2026-3834",
  "modified": "2026-09-10T11:02:05.860713Z",
  "published": "2026-09-10T09:45:01.543975Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/pull/1565"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/esphome/device-builder"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/esphome-device-builder"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-vv4j-m4vr-f3g6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59177"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-59177 (GCVE-0-2026-59177)

FKIE_CVE-2026-59177

GHSA-VV4J-M4VR-F3G6

Summary

Details

Impact

Severity rationale

Patches

Workarounds

Resources

PYSEC-2026-3834

Summary

Details

Impact

Severity rationale

Patches

Workarounds

Resources

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour