Vulnerability-Lookup

CVE-2026-59178 (GCVE-0-2026-59178)

Vulnerability from cvelistv5 – Published: 2026-09-14 18:11 – Updated: 2026-09-14 19:01

Title

ESPHome Device Builder: Renamed auth env vars silently disable dashboard authentication on upgrade

Summary

ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to version 1.0.12, the dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. Earlier versions, and the legacy `esphome` dashboard, read the bare `$USERNAME` and `$PASSWORD` instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with `USERNAME` / `PASSWORD` (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port. The issue is fixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated. This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names. The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12. Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version. Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open.

Severity

9.8 (Critical)


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

SSVC

Exploitation: none Automatable: yes Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-14 19:00 UTC

CWE

CWE-306 - Missing Authentication for Critical Function

Assigner

GitHub_M mitre root

References

4 references

URL	Tags
https://github.com/esphome/device-builder/securit…	x_refsource_CONFIRM
https://github.com/esphome/device-builder/pull/1625	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.12	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-59178",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-14T19:00:53.484049Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-14T19:01:07.730Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "device-builder",
          "vendor": "esphome",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.0.12"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to version 1.0.12, the dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. Earlier versions, and the legacy `esphome` dashboard, read the bare `$USERNAME` and `$PASSWORD` instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with `USERNAME` / `PASSWORD` (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port. The issue is fixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated. This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names. The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12. Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version. Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-306",
              "description": "CWE-306: Missing Authentication for Critical Function",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-14T18:11:02.218Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4"
        },
        {
          "name": "https://github.com/esphome/device-builder/pull/1625",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/esphome/device-builder/pull/1625"
        },
        {
          "name": "https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52"
        },
        {
          "name": "https://github.com/esphome/device-builder/releases/tag/1.0.12",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/esphome/device-builder/releases/tag/1.0.12"
        }
      ],
      "source": {
        "advisory": "GHSA-rrxg-g2pf-6hh4",
        "discovery": "UNKNOWN"
      },
      "title": "ESPHome Device Builder: Renamed auth env vars silently disable dashboard authentication on upgrade"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-59178",
    "datePublished": "2026-09-14T18:11:02.218Z",
    "dateReserved": "2026-07-02T19:53:48.829Z",
    "dateUpdated": "2026-09-14T19:01:07.730Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-59178",
      "date": "2026-09-15",
      "epss": "0.00417",
      "percentile": "0.35261"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-59178\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-09-14T19:17:37.617\",\"lastModified\":\"2026-09-14T19:17:37.617\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to version 1.0.12, the dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. Earlier versions, and the legacy `esphome` dashboard, read the bare `$USERNAME` and `$PASSWORD` instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with `USERNAME` / `PASSWORD` (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port. The issue is fixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated. This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names. The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12. Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version. Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open.\"}],\"affected\":[{\"source\":\"security-advisories@github.com\",\"affectedData\":[{\"vendor\":\"esphome\",\"product\":\"device-builder\",\"versions\":[{\"version\":\"\u003c 1.0.12\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":9.8,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":5.9}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-09-14T19:00:53.484049Z\",\"id\":\"CVE-2026-59178\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"yes\"},{\"technicalImpact\":\"total\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-306\"}]}],\"references\":[{\"url\":\"https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/esphome/device-builder/pull/1625\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/esphome/device-builder/releases/tag/1.0.12\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4\",\"source\":\"security-advisories@github.com\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-59178\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-09-14T19:00:53.484049Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-09-14T19:01:00.677Z\"}}], \"cna\": {\"title\": \"ESPHome Device Builder: Renamed auth env vars silently disable dashboard authentication on upgrade\", \"source\": {\"advisory\": \"GHSA-rrxg-g2pf-6hh4\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 9.8, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"CRITICAL\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"esphome\", \"product\": \"device-builder\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 1.0.12\"}]}], \"references\": [{\"url\": \"https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4\", \"name\": \"https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/esphome/device-builder/pull/1625\", \"name\": \"https://github.com/esphome/device-builder/pull/1625\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52\", \"name\": \"https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/esphome/device-builder/releases/tag/1.0.12\", \"name\": \"https://github.com/esphome/device-builder/releases/tag/1.0.12\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"ESPHome Device Builder Dashboard is a dashboard for the ESPHome home management software. Prior to version 1.0.12, the dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. Earlier versions, and the legacy `esphome` dashboard, read the bare `$USERNAME` and `$PASSWORD` instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with `USERNAME` / `PASSWORD` (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port. The issue is fixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated. This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names. The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12. Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version. Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-306\", \"description\": \"CWE-306: Missing Authentication for Critical Function\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-09-14T18:11:02.218Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-59178\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-09-14T19:01:07.730Z\", \"dateReserved\": \"2026-07-02T19:53:48.829Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-09-14T18:11:02.218Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-59178

Vulnerability from fkie_nvd - Published: 2026-09-14 19:17 - Updated: 2026-09-14 19:17

Severity

9.8 (Critical) - CVSS:3.1/AV:N/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/9e294f729c3eb7334bb57b9fc49b75b728052f52
	security-advisories@github.com	https://github.com/esphome/device-builder/pull/1625
	security-advisories@github.com	https://github.com/esphome/device-builder/releases/tag/1.0.12
	security-advisories@github.com	https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "device-builder",
          "vendor": "esphome",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.0.12"
            }
          ]
        }
      ],
      "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 version 1.0.12, the dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. Earlier versions, and the legacy `esphome` dashboard, read the bare `$USERNAME` and `$PASSWORD` instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with `USERNAME` / `PASSWORD` (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port. The issue is fixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated. This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names. The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12. Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version. Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open."
    }
  ],
  "id": "CVE-2026-59178",
  "lastModified": "2026-09-14T19:17:37.617",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 9.8,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.9,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-59178",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-09-14T19:00:53.484049Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-09-14T19:17:37.617",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/pull/1625"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/releases/tag/1.0.12"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-306"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

GHSA-RRXG-G2PF-6HH4

Vulnerability from github – Published: 2026-09-14 18:08 – Updated: 2026-09-14 18:08

Summary

ESPHome Device Builder: Renamed auth env vars silently disable dashboard authentication on upgrade

Details

Summary

The dashboard reads its authentication credentials from $ESPHOME_USERNAME and $ESPHOME_PASSWORD. Earlier versions, and the legacy esphome dashboard, read the bare $USERNAME and $PASSWORD instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with USERNAME / PASSWORD (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port.

Details

Credentials are resolved in DashboardSettings.parse_args. The fallback originally read os.getenv("USERNAME") and os.getenv("PASSWORD"). The env var rename (#265) replaced those with ESPHOME_USERNAME / ESPHOME_PASSWORD and intentionally removed the bare names, because $USERNAME collides with the OS login user on Linux and Windows and reading it on its own would silently promote the shell user to the dashboard username.

The rename closed that footgun but introduced a backward compatibility break: a deployment that set only the bare names now resolves to no credentials, using_password is false, and the REST auth middleware and the WebSocket login gate are both disabled. The process logs a WITHOUT AUTHENTICATION banner at startup, but a container started detached (docker run -d) never surfaces it, so the exposure is silent in practice.

This reaches users because the dashboard subcommand of the ghcr.io/esphome/esphome container runs this package: the container pins esphome-device-builder and execs it for dashboard, inheriting whatever env the operator passed. The standalone Docker path runs without --ha-addon, so it is the affected path. Home Assistant add on installs are not affected; they pass --ha-addon and authenticate through the supervisor ingress proxy, and do not use these env vars.

The rename was tagged as a breaking change but was not surfaced in the 2026.6.0 changelog, so operators had no signal to migrate before upgrading.

Impact

An unauthenticated client with network access to the dashboard port can manage devices, including editing configurations and flashing firmware. Only deployments that relied on the bare $USERNAME / $PASSWORD env vars for authentication are affected; deployments using --username / --password, the new $ESPHOME_* env vars, or HA add on ingress are not.

Severity rationale

An unauthenticated network client crosses the dashboard's only security boundary, and a client past that boundary has host equivalent capability. ESPHome's threat model documents that an authenticated 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 base score is rated for the worst case, an internet reachable dashboard. That worst case is the right anchor here, because this issue only affects operators who had deliberately configured a dashboard password, and setting a password is the control an operator uses precisely when the dashboard is reachable by parties they do not fully trust, including a deployment exposed to the internet or a network segment shared with untrusted devices. For the affected population a trusted network cannot be assumed, so authentication should be restored as urgent.

Operational risk is lower for the subset of affected installations that run 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. ESPHome is designed for deployment on trusted networks with the network perimeter as the primary defense, so that deployment context reduces real world exposure; it does not lower the base severity, and operators on shared, guest, or internet reachable networks remain at full risk.

Patches

Fixed in 1.0.12. The bare $USERNAME / $PASSWORD are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to $ESPHOME_USERNAME / $ESPHOME_PASSWORD. The fallback is gated on $PASSWORD being set and is only adopted as a pair, so the OS provided $USERNAME is never read on its own and the original collision footgun stays closed. A lone bare $PASSWORD with no username still fails loud as a credential mismatch rather than starting unauthenticated.

This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the $ESPHOME_* names.

The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned esphome-device-builder version to 1.0.12.

Workarounds

Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version:

ESPHOME_USERNAME=<your-username>
ESPHOME_PASSWORD=<your-password>

Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the WITHOUT AUTHENTICATION banner to confirm whether a given instance is currently open.

References

Original report against the esphome container: GHSA-446m-c8jp-v37m
Env var rename that introduced the regression: esphome/device-builder#265
2026.6.0 changelog (breaking change was not documented): https://esphome.io/changelog/2026.6.0
Old setup documentation that used the bare names: https://esphome.io/guides/getting_started_command_line

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/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.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-14T18:08:57Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. Earlier versions, and the legacy `esphome` dashboard, read the bare `$USERNAME` and `$PASSWORD` instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with `USERNAME` / `PASSWORD` (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port.\n\n## Details\n\nCredentials are resolved in `DashboardSettings.parse_args`. The fallback originally read `os.getenv(\"USERNAME\")` and `os.getenv(\"PASSWORD\")`. The env var rename (#265) replaced those with `ESPHOME_USERNAME` / `ESPHOME_PASSWORD` and intentionally removed the bare names, because `$USERNAME` collides with the OS login user on Linux and Windows and reading it on its own would silently promote the shell user to the dashboard username.\n\nThe rename closed that footgun but introduced a backward compatibility break: a deployment that set only the bare names now resolves to no credentials, `using_password` is false, and the REST auth middleware and the WebSocket login gate are both disabled. The process logs a `WITHOUT AUTHENTICATION` banner at startup, but a container started detached (`docker run -d`) never surfaces it, so the exposure is silent in practice.\n\nThis reaches users because the `dashboard` subcommand of the `ghcr.io/esphome/esphome` container runs this package: the container pins `esphome-device-builder` and execs it for `dashboard`, inheriting whatever env the operator passed. The standalone Docker path runs without `--ha-addon`, so it is the affected path. Home Assistant add on installs are not affected; they pass `--ha-addon` and authenticate through the supervisor ingress proxy, and do not use these env vars.\n\nThe rename was tagged as a breaking change but was not surfaced in the 2026.6.0 changelog, so operators had no signal to migrate before upgrading.\n\n## Impact\n\nAn unauthenticated client with network access to the dashboard port can manage devices, including editing configurations and flashing firmware. Only deployments that relied on the bare `$USERNAME` / `$PASSWORD` env vars for authentication are affected; deployments using `--username` / `--password`, the new `$ESPHOME_*` env vars, or HA add on ingress are not.\n\n## Severity rationale\n\nAn unauthenticated network client crosses the dashboard\u0027s only security boundary, and a client past that boundary has host equivalent capability. ESPHome\u0027s [threat model](https://github.com/esphome/device-builder/blob/main/docs/THREAT_MODEL.md) documents that an authenticated 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.\n\nThe base score is rated for the worst case, an internet reachable dashboard. That worst case is the right anchor here, because this issue only affects operators who had deliberately configured a dashboard password, and setting a password is the control an operator uses precisely when the dashboard is reachable by parties they do not fully trust, including a deployment exposed to the internet or a network segment shared with untrusted devices. For the affected population a trusted network cannot be assumed, so authentication should be restored as urgent.\n\nOperational risk is lower for the subset of affected installations that run 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. ESPHome is [designed for deployment on trusted networks](https://esphome.io/guides/security_best_practices/) with the network perimeter as the primary defense, so that deployment context reduces real world exposure; it does not lower the base severity, and operators on shared, guest, or internet reachable networks remain at full risk.\n\n## Patches\n\nFixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated.\n\nThis restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names.\n\nThe esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12.\n\n## Workarounds\n\nWithout upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version:\n\n```\nESPHOME_USERNAME=\u003cyour-username\u003e\nESPHOME_PASSWORD=\u003cyour-password\u003e\n```\n\nAlternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open.\n\n## References\n\n- Original report against the esphome container: GHSA-446m-c8jp-v37m\n- Env var rename that introduced the regression: esphome/device-builder#265\n- 2026.6.0 changelog (breaking change was not documented): https://esphome.io/changelog/2026.6.0\n- Old setup documentation that used the bare names: https://esphome.io/guides/getting_started_command_line",
  "id": "GHSA-rrxg-g2pf-6hh4",
  "modified": "2026-09-14T18:08:57Z",
  "published": "2026-09-14T18:08:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/pull/1625"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/esphome/device-builder"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/releases/tag/1.0.12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ESPHome Device Builder: Renamed auth env vars silently disable dashboard authentication on upgrade"
}

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.

Detection rules are retrieved from Rulezet.

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.

Action not permitted

CVE-2026-59178 (GCVE-0-2026-59178)

FKIE_CVE-2026-59178

GHSA-RRXG-G2PF-6HH4

Summary

Details

Impact

Severity rationale

Patches

Workarounds

References

Tags

Sightings

Nomenclature