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 CNA under the mitre root

CNA scorecard C 72/100 over 7763 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/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-11-11",
      "epss": "0.00779",
      "percentile": "0.56341"
    },
    "nvd": {
      "cve": {
        "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-30T19:08:21.363",
        "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": "Awaiting Analysis",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-306"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Primary"
          }
        ]
      }
    },
    "vulnrichment": {
      "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:00.677Z",
              "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"
    }
  }
}

FKIE_CVE-2026-59178

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

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-30T19:08:21.363",
  "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": "Awaiting Analysis",
  "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"
}

PYSEC-2026-4049

Vulnerability from pysec - Published: 2026-10-01 16:38 - Updated: 2026-10-01 17:10

Details

Summary

Details

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

Severity rationale

Patches

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

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.12"
            }
          ],
          "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.10",
        "1.0.10b1",
        "1.0.10b2",
        "1.0.11",
        "1.0.11b1",
        "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-59178",
    "GHSA-rrxg-g2pf-6hh4"
  ],
  "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": "PYSEC-2026-4049",
  "modified": "2026-10-01T17:10:22.395473Z",
  "published": "2026-10-01T16:38:30.649218Z",
  "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"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/esphome-device-builder"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-rrxg-g2pf-6hh4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59178"
    }
  ],
  "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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

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-59178 (GCVE-0-2026-59178)

FKIE_CVE-2026-59178

GHSA-RRXG-G2PF-6HH4

Summary

Details

Impact

Severity rationale

Patches

Workarounds

References

PYSEC-2026-4049

Summary

Details

Impact

Severity rationale

Patches

Workarounds

References

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour