Kurzfassung

Mit CVE-2026-59178 ist im ESPHome Device Builder Dashboard eine kritische Schwachstelle mit CVSS 9.8 bekannt geworden. Betroffen sind Installationen vor Version 1.0.12, bei denen ein Upgrade dazu führen kann, dass die Weboberfläche ohne Anmeldung offen im Netz steht. Der Fehler ist besonders brisant, wenn das Dashboard aus anderen Netzen oder direkt aus dem Internet erreichbar ist.

Was ist passiert?

Der Fehler steckt in der Umstellung der Umgebungsvariablen für die Anmeldung am ESPHome-Dashboard. Neuere Fassungen erwarten Zugangsdaten in ESPHOME_USERNAME und ESPHOME_PASSWORD. Ältere Setups und die frühere Dashboard-Variante verwendeten dagegen USERNAME und PASSWORD.

Wurden Instanzen nach der Umstellung aktualisiert, ohne die Variablennamen anzupassen, konnte der Schutz der Oberfläche wegfallen. Das Dashboard startete dann unter Umständen ohne Authentifizierung. Jeder, der den Port erreichen konnte, erhielt Zugriff auf die Oberfläche.

Behoben ist das Problem in Version 1.0.12. Dort akzeptiert die Software die alten Variablennamen wieder als veraltete Übergangslösung, damit bestehende geschützte Installationen beim Upgrade nicht unabsichtlich offen werden.

Technische Details

Für CVE-2026-59178 nennt die NVD einen CVSS-Basiswert von 9.8 mit dem Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Das bedeutet: Ein Angriff ist über das Netzwerk möglich, die Hürden sind niedrig, es sind keine Zugangsdaten und keine Mitwirkung eines Benutzers nötig. Der Wert beschreibt die technische Schwere des Fehlers, nicht automatisch die tatsächliche Ausnutzung in Ihrer Umgebung.

Die Ursache ist kein klassischer Speicherfehler, sondern eine fehleranfällige Änderung im Authentifizierungsverhalten. Wenn Betreiber weiterhin nur die alten Variablen USERNAME und PASSWORD gesetzt hatten, griff die neue Namenskonvention ohne Rückfallmechanismus. Dadurch konnte eine zuvor geschützte Instanz ungeschützt starten.

Der Hersteller hat den Rückfallmechanismus in 1.0.12 so umgesetzt, dass die alten Variablen nur als Paar übernommen werden und nur dann, wenn PASSWORD gesetzt ist. Damit soll verhindert werden, dass vom Betriebssystem bereitgestellte Standardwerte für USERNAME versehentlich allein ausgewertet werden.

Wer ist betroffen?

Betroffen sind ESPHome Device Builder Dashboard-Installationen vor Version 1.0.12. Besonders relevant ist das für Umgebungen, in denen die Weboberfläche per Container oder Self-Hosting betrieben und über Umgebungsvariablen abgesichert wurde.

Hohes Risiko besteht, wenn Administratoren bislang die älteren Variablennamen USERNAME und PASSWORD verwendet haben und das Dashboard nach einem Upgrade weiterhin für andere Netze erreichbar ist. Im Heimnetz bleibt das Risiko oft lokal begrenzt. In Unternehmen, Laboren, OT-Nebennetzen oder gemeinsam genutzten Entwicklerumgebungen kann der Fehler jedoch schnell praktisch ausnutzbar sein.

Der Fix erreicht auch den ESPHome-Container mit Release 2026.6.2, das die korrigierte Version 1.0.12 von esphome-device-builder einbindet.

Empfohlene Maßnahmen

Erste Priorität: Prüfen Sie sofort, ob Ihr Dashboard derzeit ohne Anmeldung erreichbar ist. Kontrollieren Sie die Startprotokolle auf einen Hinweis, dass die Instanz ohne Authentifizierung läuft, und testen Sie den Zugriff von einem zweiten System im gleichen Netz.

Zweite Priorität: Aktualisieren Sie auf Version 1.0.12 beziehungsweise beim Container auf Release 2026.6.2. Das schließt die unbeabsichtigte Öffnung bestehender Installationen beim Upgrade.

Dritte Priorität: Stellen Sie die Zugangsdaten explizit auf ESPHOME_USERNAME und ESPHOME_PASSWORD um. Verlassen Sie sich nicht dauerhaft auf die wieder eingeführte Übergangskompatibilität mit USERNAME und PASSWORD.

Vierte Priorität: Begrenzen Sie die Erreichbarkeit des Dashboard-Ports. Hängen Sie die Oberfläche nicht direkt ins Internet, filtern Sie Zugriffe per Firewall oder Reverse Proxy und erlauben Sie nur vertrauenswürdige Quellnetze.

Fünfte Priorität: Dokumentieren Sie für den Betrieb, welche Umgebungsvariablen produktiv verwendet werden. Gerade bei Compose-Dateien, Kubernetes-Deployments und Vorlagen aus älteren Projekten ist die Gefahr groß, dass veraltete Namen unbemerkt weiterlaufen.

Einschätzung von CyberSecurity-News.de

Der technische Schweregrad ist zu Recht hoch, weil eine ungeschützte Verwaltungsoberfläche aus dem Netz ohne jede Anmeldung erreichbar sein kann. Für viele Unternehmen im DACH-Raum ist das trotzdem kein Massenrisiko, weil ESPHome eher in Spezialumgebungen, Laboren, Smart-Building-Projekten oder privaten Setups läuft als in klassischen Rechenzentrumsanwendungen.

Problematisch ist vor allem die Art des Fehlers: Ein Schutzmechanismus fällt nicht wegen eines falschen Passworts aus, sondern durch eine Namensänderung in der Konfiguration. Solche Brüche werden in der Praxis leicht übersehen, besonders bei Upgrades von Containern und bei Deployments, die seit Jahren unverändert laufen.

Die bereitgestellte Abwärtskompatibilität ist operativ sinnvoll, weil sie bestehende Installationen ohne Eingriff wieder schützt. Gleichzeitig zeigt der Fall, wie riskant Änderungen an Authentifizierungsoptionen ohne robusten Migrationspfad sind. Die Informationslage ist insgesamt brauchbar: Fix-Version und Sofortmaßnahmen sind benannt. Offene Punkte bleiben bei der Verbreitung betroffener Installationen und bei der Frage, wie oft Dashboards tatsächlich öffentlich exponiert sind.

Fazit

Wenn Sie ESPHome-Dashboards betreiben, sollten Sie jetzt zuerst die Erreichbarkeit ohne Login prüfen und dann auf 1.0.12 beziehungsweise 2026.6.2 aktualisieren. Setzen Sie die Zugangsdaten auf ESPHOME_USERNAME und ESPHOME_PASSWORD um und nehmen Sie die Oberfläche aus untrusted Netzen heraus, falls das noch nicht geschehen ist.

Quellenangabe

Weiterführende technische Details finden Sie bei der NVD: CVE-2026-59178.