Pi-hole Sicherheitslücke: Update schließt Fix-Bypass-Lücke

Ein Sicherheitsupdate schließt 15 Lücken – fünf davon mit CVSS-Werten zwischen 7.3 und 7.8, also im hohen Bereich. Betroffen sind Self-Hoster, die den DNS-Filter als Werbeblocker im Heim- oder Firmennetz betreiben; die Schwachstellen reichen nach derzeitigem Stand bis einschließlich Core 6.4.3. Die Pi-hole Sicherheitslücke mit der größten Sprengkraft ist ein Bypass des Fixes für CVE-2026-41489: Der unprivilegierte pihole-Benutzer erlangt über eine manipulierte PID-Datei Root-Rechte. Für den Bypass selbst gibt es bislang keine CVE, Hinweise auf eine Ausnutzung im Wild gibt es nicht.

Pi-hole Sicherheitslücke: Die fünf Hochrisiko-Fälle im Überblick

Fünf Lücken gelten als hochriskant, vier als mittel, sechs als niedrig. Alle fünf schweren Fälle stehen bislang ohne eigene CVE-Nummer; das kann sich kurzfristig ändern, weil Einträge in Advisorys und CVE-Datenbanken laufend nachgezogen werden. Im Einzelnen:

Bypass des CVE-2026-41489-Fixes – lokale Rechteausweitung vom pihole-Benutzer zu Root, CVSS 7.8, verzeichnet als GHSA-cf36-4hhc-8398.
Root-Dateien überschreiben, chmod oder offenlegen über den updatecheck.sh-Cronjob, der einem Symlink auf /etc/pihole/versions folgt – CVSS 7.8.
Rechteausweitung über die Ambient-Capability CAP_CHOWN von pihole-FTL – CVSS 7.8.
Authentifiziertes Datei-Auslesen samt Bypass des dafür gedachten Fixes – CVSS 7.7.
gravity.sh ändert den Besitzer beliebiger Verzeichnisse auf pihole über den Konfigurationspfad files.gravity – CVSS 7.3.

Zu den vier mittleren und sechs niedrigen Lücken sind keine Details öffentlich belegt.

Bypass des CVE-2026-41489-Fixes: eine Prüfung, die nur ein Zeichen ansieht

Die Ursache ist ein Klassiker der Eingabevalidierung. Der Fix für CVE-2026-41489 hardcodierte den PID-Pfad auf /run/pihole-FTL.pid und ergänzte eine Inhaltsprüfung. Diese expr-Prüfung matcht jedoch nur ein führendes Nicht-Ziffer-Zeichen. Werte, die mit einer Ziffer beginnen, passieren die Validierung unverändert. Landet ein solcher Wert in einem Bash-Arithmetik-Kontext wie [[ "$pid" -eq "-1" ]], expandiert Bash Array-Subscripts rekursiv – und führt auf diesem Weg Command Substitution mit Root-Rechten aus. Betroffen sind Versionen bis einschließlich 6.4.3, korrigiert ist der Fehler in 6.5.

Verifiziert ist die Kette im offiziellen Container: Der unprivilegierte pihole-Benutzer manipuliert die PID-Datei, die er beschreiben darf, und ein späteres root-laufendes pihole-Subkommando erzeugt eine root-eigene Belegdatei. Ein Angriff über das Netzwerk ist damit nicht beschrieben – der Weg setzt lokalen Zugriff als pihole voraus und wird erst durch einen root-laufenden Aufruf scharf.

Der Bypass ist die zweite Runde eines bekannten Problems. CVE-2026-41489 (CVSS 8.8) und CVE-2026-39849 (CVSS 8.7) wurden bereits mit Core 6.4.2 und FTL 6.6.1 geschlossen, verwundbar waren Installationen ab Version 6.0. Bei CVE-2026-39849 reichte die Filterung des Feldes dns.interface nicht aus: Zeilenumbrüche wurden akzeptiert, sodass sich dnsmasq-Direktiven wie dhcp-script= einschmuggeln ließen. Dass der Fix für das eine Problem die nächste Lücke offenließ, ist der eigentliche Befund dieser Update-Runde.

Welche Versionen betroffen sind – und welche nicht

Für die Bypass-Lücke gilt: betroffen bis einschließlich Core 6.4.3, gepatcht ab 6.5. Die aktuellen Stände sind Core 6.5, FTL 6.8 und Web 6.6.1 oder neuer; Docker-Images enthalten die Korrekturen ab dem Stand 2026.10.0. Die Zahlen der beiden Runden dürfen nicht vermischt werden: 6.4.2 und 6.6.1 gehören zum Fix von CVE-2026-41489, 6.5 und 6.8 zur jetzt veröffentlichten Welle.

In der Historie stehen unter anderem CVE-2026-50130 mit CVSS 8.8 (gefixt in 6.4.3) und CVE-2026-33727 mit CVSS 6.4 (gefixt in 6.4.1). Insgesamt sind für Pi-hole 23 CVE-Einträge verzeichnet – das ist die historische Gesamtzahl, nicht die 15 jetzt geschlossenen Lücken.

Update für Self-Hoster: erst Teleporter-Backup, dann `pihole -up`

Vor dem Update ein Backup ziehen: im Webinterface unter „Settings“ → „Teleporter“ oder per sudo pihole-FTL --teleporter. Danach sudo pihole -up ausführen. Einen Workaround, der die Lücken ohne Update schließt, gibt es nicht – es bleibt beim Patch. Wer Pi-hole im Container betreibt, zieht das Image ab dem Stand 2026.10.0.

Praktisch relevant ist der Kontext: Ein DNS-Filter sitzt an der Stelle, an der jedes Gerät im Netz seine Auflösung abholt. Eine Rechteausweitung von einem Dienstkonto zu Root ist deshalb kein lokales Schönheitsproblem, sondern der Zugriff auf die Instanz, die bestimmt, wohin Namensauflösung führt.

Was das Update sonst noch ändert

Das Live-Log arbeitet als Ringpuffer. Statt den gesamten Puffer pro Eintrag zu verschieben, bleibt der CPU-Aufwand geringer.
Internationalisierte Domainnamen auf Listen werden nicht mehr als ungültig abgelehnt, sondern in Punycode konvertiert und geblockt.
Die doppelte Logrotation entfällt, weil Pi-hole inzwischen selbst in /etc/logrotate.d auftaucht.

Fazit: „gepatcht“ ist kein Zustand, sondern ein Datum

Der Bypass ist ein Lehrstück darüber, wie wenig ein Fix wert ist, der nur das erste Zeichen eines Werts prüft. Wer Pi-hole betreibt, sollte die Version kontrollieren und patchen – nicht panisch, aber zeitnah. Eine Ausnutzung im Wild ist nicht dokumentiert; die Kombination aus öffentlichem Advisory, lokalem PoC und einer Lücke, die bereits einen Fix aushebelt, macht das Update trotzdem dringlich. Unabhängig von diesen Lücken lohnt der Blick auf die eigene Härtung: administrativer Zugriff nur mit Passwort, API nicht unnötig exponieren, kein Zugriff von außen auf das Webinterface. Und beim nächsten Fix dieser Art: prüfen, ob die Validierung den ganzen Wert ansieht oder nur den Anfang.

Quellen