Hat dein Pi-hole ein Passwort? Falls du beim Einrichten „später" gedacht hast, ist jetzt später. Am 17-10-2026 hat das Pi-hole-Team Core v6.5, FTL v6.8 und Web v6.6.1 veröffentlicht, als Docker-Image mit dem Tag 2026.10.0, und die Release Notes lesen sich diesmal weniger wie ein Changelog und mehr wie ein Sicherheitsbericht: 17 Advisories auf einmal, fünf davon mit Schweregrad High. Eine davon betrifft genau die Installationen ohne Passwort, und sie ist die einzige, die eine fremde Website aus dem Browser heraus ausnutzen konnte.

Neue Funktionen gibt es auch, sie stehen in diesem Beitrag weiter unten, weil sie diesmal nicht der Grund zum Updaten sind.

Kurz gesagt: Pi-hole v6.5 schließt 17 Sicherheitslücken in Core, FTL und Web. Vier High-Lücken im Core erlauben einem Angreifer, der schon als Benutzer pihole auf dem System ist, den Aufstieg zu root; eine in FTL lässt angemeldete Nutzer beliebige Dateien lesen. Ohne Web-Passwort konnte zusätzlich jede Website im Browser eines Heimnetz-Geräts das Pi-hole auslesen und umstellen. Update heute: Teleporter-Backup, dann pihole -up oder neues Docker-Image. Danach ein Passwort setzen, falls keins da ist. Stand: Pi-hole Core 6.5, FTL 6.8, Web 6.6.1, Docker-Image 2026.10.0, geprüft am 20-10-2026.
Schaubild: Pi-hole 6.5 sicher updaten in drei Schritten: Teleporter-Backup anlegen, Update per pihole -up oder neuem Docker-Image einspielen, Web-Passwort prüfen
Drei Schritte, der mittlere ist der wichtige. Der dritte war es schon vor dem Update.

Vier Wege vom Benutzer pihole zu root

Die vier High-Lücken im Core haben dasselbe Muster, und wer es einmal verstanden hat, kann die Advisories selbst einordnen. Pi-hole lässt seinen DNS-Dienst FTL absichtlich als eigenen Benutzer namens pihole laufen, nicht als root. Das ist richtig so: Wer FTL übernimmt, soll damit noch nicht das ganze System haben. Die Skripte drumherum, Gravity für die Blocklisten, der Update-Checker per Cron, der Befehl pihole selbst, laufen aber als root. Und an vier Stellen vertrauten diese root-Skripte Dateien, die dem Benutzer pihole gehören.

  • GHSA-cf36-4hhc-8398 (CVSS 7.8): Der Befehl pihole liest die Prozess-ID von FTL aus einer Datei, die pihole gehört. Die Prüfung schaute nur aufs erste Zeichen; dahinter durfte Bash-Code stehen, der beim nächsten pihole reloaddns eines Admins als root lief. Das Advisory sagt dazu etwas, das ich selten so offen lese: Es ist die Umgehung eines früheren Fixes, CVE-2026-41489. Der erste Flicken hielt nicht, jetzt ist der zweite dran. Gefunden hat das abdoghazy2015.
  • GHSA-xch2-4qxw-g5vj (CVSS 7.8): Der Update-Checker schreibt als root nach /etc/pihole/versions, ohne zu prüfen, ob die Datei inzwischen ein Symlink ist. Ein Link auf /etc/shadow, und root kürzt oder ändert die Rechte einer Datei, die er nie anfassen sollte. Laut Advisory kam das Problem erst mit 6.4.2 hinein. Gemeldet von Keith Linneman und dem KimiSecurityTeam.
  • GHSA-j8vh-6fp9-cjcx (CVSS 7.8): FTL bekam über seine systemd-Unit die Fähigkeit CAP_CHOWN mit, also das Recht, Besitzer von Dateien zu ändern, und reichte sie an jeden Kindprozess weiter. Damit ließ sich die Logrotate-Konfiguration übernehmen, und der tägliche Logrotate-Lauf führte dann als root aus, was drinstand. Betroffen seit Core 5.4. Ebenfalls Keith Linneman.
  • GHSA-mff6-cjc4-5wq9 (CVSS 7.3): Gravity liest den Pfad seiner Datenbank aus pihole.toml, und die Datei gehört pihole. Trägt dort jemand /etc/cron.d ein, übergibt das nächste sudo pihole -g eines Admins das Verzeichnis an pihole. Der Unterschied zu den anderen drei: Ohne einen Admin, der den Befehl tippt, passiert nichts. KimiSecurityTeam und Pedromdsn.

Die Einordnung, die in jedem der vier Advisories steht und die ich hier nicht unterschlagen will: Alle vier setzen voraus, dass jemand bereits Code als Benutzer pihole ausführen kann. Aus dem Internet geht das nicht. Es braucht eine zweite Lücke als Einstieg, und genau da wird es ungemütlich, denn die liefert dieselbe Release-Runde in FTL gleich mit. Lokal und nur mit Vorarbeit heißt nicht harmlos, es heißt Glied zwei einer Kette.

Was mir an der Sache gefällt: Vier Lücken, vier Melder, alle in derselben Runde, und das Team hat sie zusammen in einem Release abgearbeitet, mit Namen und CVSS-Vektor zu jeder. Dass FTL sein CAP_CHOWN nicht mehr an Kindprozesse weitergibt und /opt/pihole für FTL jetzt schreibgeschützt ist, sind Änderungen, die auch die nächste, noch unbekannte Lücke kleiner machen.

FTL 6.8: Dateien lesen mit Passwort, und das Problem ohne

Die fünfte High-Lücke sitzt in FTL und ist die einzige, die über das Netz geht. GHSA-2h7g-g549-hf74 (CVSS 7.7): Wer sich an der Weboberfläche anmelden kann, konnte über einen Teleporter-Import das Verzeichnis des Webservers verschieben, im Advisory auf /proc/self/root, einen Symlink, der zur Laufzeit auf / zeigt. Danach lieferte der Webserver jede Datei aus, die der Benutzer pihole lesen darf, darunter die Passwort-Hashes in pihole.toml. Die Pfadprüfung verglich nur Buchstaben und löste keine Symlinks auf. Gemeldet von abdoghazy2015 und Jgarcg40.

„Angemeldet" klingt nach einer hohen Hürde. Eine Medium-Lücke aus demselben Release senkt sie: Nach GHSA-v53r-4564-3449 konnte ein App-Passwort, also der Zweitschlüssel, den man für Skripte oder ein Dashboard wie Homepage anlegt, über die API die Passwort-Hashes und das Geheimnis für die Zwei-Faktor-Anmeldung lesen. Mit beidem lässt sich das Admin-Passwort offline knacken und der zweite Faktor umgehen. Das Advisory empfiehlt nichts Weiteres als das Update. Ich würde trotzdem nach dem Update das App-Passwort entfernen und neu anlegen, und wer 2FA nutzt, richtet sie einmal neu ein. Das ist meine Schlussfolgerung aus dem Advisory, nicht dessen Wortlaut: Was vor dem Patch lesbar war, könnte gelesen worden sein, und ein neuer Schlüssel kostet fünf Minuten.

Und dann ist da die Lücke, die nur als Low eingestuft ist und die ich für die wichtigste in diesem Beitrag halte, weil sie die meisten Leute betrifft, die „Passwort später" gedacht haben. GHSA-322h-f873-hp54: Läuft Pi-hole ohne Web-Passwort, kann jede Website, die irgendein Gerät im Heimnetz gerade im Browser offen hat, die Pi-hole-API über diesen Browser ansprechen. Lesen: den Abfrageverlauf aller Geräte, die Konfiguration, ein komplettes Teleporter-Backup. Schreiben: Blocking abschalten, Listen ändern, die Upstream-DNS-Server umbiegen. Letzteres leitet den gesamten DNS-Verkehr des Hauses auf einen Server des Angreifers. Gemeldet von ChrisLundquist.

DNS-Rebinding? Dein Browser verbietet einer Website normalerweise, Geräte in deinem Heimnetz anzusprechen. Der Trick: Die Website lässt ihren eigenen Domainnamen nach dem ersten Aufruf auf die IP deines Pi-hole zeigen. Für den Browser ist das noch dieselbe Website, für dein Pi-hole ist es ein Gerät aus dem eigenen Netz, das Fragen stellt. Beide haben recht, und genau das ist das Problem.

FTL 6.8 schickt ab Werk keine CORS-Header mehr und lehnt schreibende Anfragen von fremden Websites mit 403 ab. Gegen Rebinding gibt es eine neue Option webserver.api.allowedHosts, und die ist nach dem Update leer, also aus. Das Advisory sagt es selbst: Die wirksamste Gegenmaßnahme ist ein Passwort, vor wie nach dem Update. Pi-hole v5 ist von dieser Lücke nicht betroffen.

Dazu kommen drei Low-Lücken in der Weboberfläche (gespeichertes Cross-Site-Scripting in den Einstellungen, den lokalen DNS-Einträgen und der bedingten Weiterleitung, gemeldet von KHr00t), drei Abstürze in FTL, die sich über die API auslösen ließen, und ein Pufferüberlauf, den eine DNS-Anfrage ohne jede Anmeldung treffen konnte. Die vollständige Liste mit allen 17 Einträgen steht in den Release Notes des Docker-Images, die bequemste Übersicht, die das Team diesmal hat.

Was sich nach dem Update anders verhält

FTL 6.8 heißt ausdrücklich nicht 6.7.2, weil sich Verhalten ändert, das man merkt. Die Liste steht im Release unter „Behaviour changes to be aware of", und zwei Punkte daraus gehören in jeden Haushalt:

  • Die Datenbank räumt in der ersten Nacht auf. Anfragen, die älter sind als database.maxDBdays, löscht FTL künftig in der ersten Nacht nach dem Start, jeweils 10.000 am Stück. Der Grund steht bei den Fixes: Auf Systemen, die FTL mindestens einmal am Tag neu starten, wurden alte Anfragen bisher nie gelöscht. Wer so eine stetig gewachsene Datenbank hat, verliert laut Release Notes in dieser Nacht den gesamten Rückstand auf einmal. Das ist korrekt und gewollt, aber wenn das Dashboard am nächsten Morgen plötzlich nur noch 90 Tage zeigt, weißt du jetzt, warum.
  • Ungültige Werte in pihole.toml fliegen raus. Ein database.DBinterval = 0 oder ein Zertifikatspfad außerhalb des Webroots wird auf den Standard zurückgesetzt. Ein Blick ins FTL-Log nach dem Start zeigt, was es verworfen hat.

Kleiner und seltener: Mit webserver.serve_all = false antwortet / unter einem anderen Hostnamen als webserver.domain jetzt mit 404, eine eigene index.html unter http://<ip>/ erscheint dann nicht mehr. Ein erneuertes selbstsigniertes Zertifikat bekommt eine neue CA, eine importierte tls_ca.crt muss neu importiert werden. Ein Teleporter-Import aus v5 ersetzt Upstreams statt sie zu ergänzen. Und der alte Befehl arpflush ist weg, er heißt jetzt networkflush.

Die Gravity-Datenbank wandert beim Update automatisch auf Schema-Version 21, mit neuen Indizes für Gruppenabfragen. Dazu gibt es ein paar Dinge, über die ich mich freue, ohne dass sie einen Beitrag verdienen: Das Live-Log läuft als Ringpuffer und kostet pro Antwort weniger CPU, Domainnamen mit Umlauten in Listen werden jetzt in Punycode übersetzt statt abgelehnt, und zwei überflüssige Indizes im Arbeitsspeicher sind weg, was laut Release Notes rund 22 MB pro Million Anfragen spart. Auf einem Raspberry Pi mit einem Gigabyte ist das keine Fußnote.

Update: pihole -up oder ein neues Image

Vorher der Backup-Tick, du kennst ihn: Im Dashboard unter Settings, Teleporter auf Export, das Archiv landet in deinen Downloads. Oder in der Shell:

sudo pihole-FTL --teleporter

Das ist auch der Weg, den der Pi-hole-Blog selbst vor dem Update empfiehlt. Auf einer normalen Installation, auf dem Raspberry Pi wie im LXC-Container auf Proxmox, bleibt dann ein Befehl:

sudo pihole -up

Er holt Core, Web und FTL nacheinander. Danach zeigt pihole -v Core v6.5, Web v6.6.1 und FTL v6.8; steht da noch 6.4.3, ist das Update nicht durchgelaufen, und die Ausgabe von pihole -up sagt, woran es lag. Debian 11 hat das Team übrigens aus seiner Testmatrix genommen, die Distribution bekommt seit dem 31-08-2026 keine Sicherheitsupdates mehr. Wer noch darauf läuft, hat ein größeres Problem als Pi-hole.

In Docker ist pihole -up im Container abgeschaltet; dort tauschst du das Image. Wer Pi-hole nach der Anleitung mit Unbound laufen hat, geht in den Ordner ~/pihole und macht, was die Docker-Doku vorgibt:

cd ~/pihole
docker compose pull
docker compose down
docker compose up -d

Mit dem Tag latest aus der Anleitung kommt 2026.10.0 beim Pull von selbst; wer die Version festgepinnt hat, trägt pihole/pihole:2026.10.0 ein. Die Einstellungen liegen im Volume und überleben das down, solange das Volume nicht als nur-lesen eingebunden ist. Für den Container gibt es zwei eigene Änderungen, die zum Thema passen: Schlägt der Download von FTL fehl, bricht der Build jetzt ab, statt mit einem halben Image weiterzumachen, und das Web-Passwort aus einem Docker-Secret landet nicht mehr im Debug-Log.

Nach dem Update, in dieser Reihenfolge: Hat dein Pi-hole kein Passwort, setz jetzt eins, mit sudo pihole setpassword; der Befehl fragt es ab, ohne es auf dem Bildschirm zu zeigen. Im Container gehört es stattdessen als FTLCONF_webserver_api_password in die Compose-Datei, so wie in der Anleitung. Nutzt du das App-Passwort, entfernst du es unter Settings, Web Interface / API, Configure app password und legst dort ein neues an. Und wer das Dashboard aus dem Internet erreichbar gemacht hat, ohne VPN oder Reverse Proxy davor, hatte ein Pi-hole, auf das ein angemeldeter Angreifer vorher beliebige Dateien lesen konnte; da würde ich zusätzlich das Admin-Passwort tauschen.

Warten würde ich mit diesem Update nicht. Die Verhaltensänderungen sind dokumentiert, keine davon zerlegt eine normale Installation, und auf der anderen Seite stehen fünf High-Lücken, von denen eine die Umgehung eines Fixes ist, den du vielleicht im Sommer schon eingespielt hast. Ein Release, das zehn Forschern namentlich dankt und jede Lücke mit Vektor aufführt, ist die Sorte Release Notes, die ich mir von Herstellern wünsche, die das Zehnfache verlangen.

Hat dein Pi-hole bis heute ein Passwort gehabt, oder war das einer der Punkte auf der Liste für irgendwann? Und wie voll war deine Datenbank, bevor die erste Nacht sie aufgeräumt hat? Schreib's in die Kommentare.

Wer Pi-hole noch gar nicht laufen hat oder das Upgrade zum Anlass nimmt, es neu aufzusetzen: Die Compose-Datei mit Unbound und die FritzBox-Einrichtung stehen hier auf sakis.tech und passen zu 6.5 unverändert.

Quellen