Caddy 2.11.8 und 2.11.9: Fünf Lücken rund um Dateiserver und PHP, und warum ein reiner Reverse-Proxy sie nicht hat

Caddy hat am 4. November Version 2.11.8 und einen Tag später 2.11.9 veröffentlicht. Beide enthalten Sicherheitskorrekturen. Fünf davon sind GitHub-Advisories vom 4. November, alle in 2.11.8 behoben und für Version 2.11.7 und älter gültig. Keine hat eine CVE-Nummer. Die Einstufung auf den Advisory-Seiten: eine als hoch, vier als mittel.

Die fünf Hinweise und ihre Vorbedingungen

Für jede Lücke muss eine bestimmte Direktive im Caddyfile stehen. Das ist der Punkt, an dem sich die Betroffenheit entscheidet. Die Angaben unten stammen aus den Advisory-Seiten auf GitHub, die wir am 8. November gelesen haben.

Advisory	Einstufung	Vorbedingung
GHSA-r766-rf9f-588h	hoch	`root` aus `{host}` gebaut, zum Beispiel `root /srv/sites/{host}`, auf einer Seite für beliebige Hostnamen oder mit On-Demand-TLS, dazu `file_server` oder `php_fastcgi` (laut Advisory auch FrankenPHP). Seiten mit fest eingetragenen Hostnamen sind nicht betroffen. Keine Anmeldung nötig.
GHSA-f278-mgc7-46j3	mittel (CVSS 5.9)	`php_fastcgi` oder ein FastCGI-Transport, im Seiten-Root liegt keine `index.php` (und keine `index`-Unteroption), und eine Zugriffsregel (`basic_auth` oder `handle`) schützt einen PHP-Pfad: Die Lücke umgeht genau diese Regel. Der Angreifer muss den Namen einer vorhandenen PHP-Datei kennen. Seiten mit `index.php` sind laut Advisory nicht betroffen.
GHSA-25cw-38mq-q7m6	mittel	`try_files {path}` zusammen mit `file_server` und einer Sperrregel für Pfade davor, etwa `path *.env`. `php_fastcgi` und FrankenPHP `php_server` bringen diese `try_files`-Route laut Advisory selbst mit.
GHSA-69hv-5jfc-mvmv	mittel	`try_files` mit `split_path` und eine Umschreibung, die `{http.matchers.file.remainder}` verwendet (FrankenPHP `php_server` erzeugt sie), Das Umgehen einer Sperrregel braucht eine solche Regel für Pfade vor der Umschreibung; Eingriffe in Query-String und Pfad brauchen nur die Umschreibung.
GHSA-jf74-f69g-hcj9	mittel	`file_server` liefert das Arbeitsverzeichnis aus, und weder `HOME` noch `XDG_DATA_HOME` sind gesetzt. Der Kommandozeilenaufruf `caddy file-server` ist ebenfalls betroffen.

Zwei weitere Hinweise, die in den Release-Notes von 2.11.9 stehen, konnten wir nicht lesen: GHSA-q34h-28rj-5hjm (Header des Clients überschreiben die FastCGI-Umgebung) und GHSA-9cr8-wmhh-39pm (Windows-Kurznamen und alternative Datenströme). Beide sind am 8. November noch nicht veröffentlicht: Die Advisory-Seite lieferte einen 404. Zu Einstufung und betroffenem Bereich können wir deshalb nichts sagen, nur der Text der Release-Notes liegt vor.

CVE-2026-55458 gehört nicht zu diesen fünf. Der Hinweis GHSA-8qx7-j2v2-x6q5 ist niedrig eingestuft und vom 13. Oktober: Hop-by-hop-Header geraten bei WebSocket-Antworten (Status 101) durch reverse_proxy nach außen. Laut Advisory gilt er bis 2.11.4 und ist ab 2.11.5 behoben; die Release-Notes von 2.11.8 nennen ihn ebenfalls.

Was sich mit dem Update ändert

Version 2.11.8 liefert für Hostnamen, die ungültig sind oder nur aus Punkten bestehen, jetzt den Status 400 aus. Bei php_fastcgi ohne index.php laufen fehlende Pfade auf index.php, und try_files-Kandidaten mit einem Schrägstrich am Ende passen nur noch auf Verzeichnisse. Die Konfiguration wird strenger geprüft.

Version 2.11.9 ist ein Hotfix für eine Regression aus 2.11.8: Anfragen auf Verzeichnisse mit Schrägstrich am Ende übersprangen index.php, zum Beispiel /wp-admin/ bei WordPress. Dazu kommen drei Änderungen. Widersprüchliche client_auth-Einstellungen in mehreren Seitenblöcken sind jetzt ein Fehler. FastCGI antwortet mit 400, wenn die Skriptauswahl mehrdeutig ist. Und FastCGI-Umgebungswerte überschreiben jetzt gleichnamige HTTP_*-Header des Clients. Die Aufzählung stammt aus den Release-Seiten vom 8. November.

Was unser Gateway-Caddyfile zeigt

Wir haben am 8. November das Caddyfile unseres Caddy-Gateways im Homelab (der Reverse Proxy vor den internen Webdiensten) nach den Direktiven durchsucht, je Direktive ein grep -c <Direktive> Caddyfile. Das Ergebnis: file_server 0, try_files 0, php_fastcgi 0, root 0, on_demand 0. Der Platzhalter {host} kommt 8-mal vor, aber nicht in einem root. Auf diesem Gateway fehlt damit die Vorbedingung aller fünf Advisories. Das ist eine Ableitung aus der Konfiguration und kein Angriffsversuch.

Anders sieht es bei Servern aus, die Seiten selbst ausliefern. Wer Caddy mit php_fastcgi betreibt, prüft GHSA-f278, aber nur, wenn im Seiten-Root keine index.php liegt und eine Zugriffsregel einen PHP-Pfad schützt. Das Advisory nennt Seiten mit index.php oder gesetzter index-Unteroption ausdrücklich nicht betroffen und schreibt, Front-Controller-Anwendungen wie WordPress, Laravel und Symfony seien maskiert, weil die Umschreibung dort läuft. Bei try_files oder FrankenPHP php_server sind GHSA-25cw und GHSA-69hv die Prüfung. Wer mehrere Kundenseiten über einen Platzhalter-Block bedient, prüft zuerst, ob dort ein root mit {host} steht. Die Prüfung dauert eine Minute.

Was jetzt zu tun ist

caddy version auf jedem Host. Alles unter 2.11.9 steht zur Aktualisierung an.
grep -n -E "file_server|php_fastcgi|php_server|try_files|^\s*root |on_demand" Caddyfile. Ohne Treffer fehlt im Caddyfile die Vorbedingung der fünf Advisories. Aufrufe von caddy file-server (GHSA-jf74) stehen in keinem Caddyfile, die suchen Sie in Systemd-Units, Skripten und Containerdefinitionen.
Bei Treffern: Steht in einem root der Platzhalter {host}, ist GHSA-r766 die dringendste Prüfung, weil sie ohne Anmeldung ausnutzbar ist.
Vor dem Update die Breaking Changes lesen. Ein Test mit einer Kopie des Caddyfiles zeigt, ob die strengere Validierung etwas ablehnt: caddy validate --config Caddyfile.

Bei einem Caddy im Container ohne Admin-Schnittstelle gilt die übliche Regel: Die Konfiguration lässt sich nicht nachladen, das Update heißt Neustart des Containers.

Dazu passt

Wie wir Zugriffe am Gateway sperren, steht im Beitrag Intrusion Prevention: CrowdSec statt fail2ban. Den Reverse Proxy selbst beschreibt Reverse Proxy mit Caddy: HTTPS per Default.

Weiterführende Quellen

Primärquellen

Caddy, Release v2.11.8, 4. November 2026: github.com
Caddy, Release v2.11.9, 5. November 2026: github.com
Caddy, Liste der Security-Advisories: github.com
Caddy, Advisory GHSA-r766-rf9f-588h, 4. November 2026: github.com
Caddy, Advisory GHSA-f278-mgc7-46j3, 4. November 2026: github.com
Caddy, Advisory GHSA-25cw-38mq-q7m6, 4. November 2026: github.com
Caddy, Advisory GHSA-69hv-5jfc-mvmv, 4. November 2026: github.com
Caddy, Advisory GHSA-jf74-f69g-hcj9, 4. November 2026: github.com
Caddy, Advisory GHSA-8qx7-j2v2-x6q5, 13. Oktober 2026, CVE-2026-55458: github.com

Eigene Messung

Die Zählung der Direktiven im Caddyfile des Homelab-Caddy-Gateways stammt vom 8. November 2026 (grep -c je Direktive). GHSA-q34h und GHSA-9cr8 waren am selben Tag noch nicht veröffentlicht (404); es lagen nur die Texte der Release-Notes vor.

Fragen?

Ist ein Caddy, der nur reverse_proxy macht, von diesen Lücken betroffen?+

Nach den Vorbedingungen in den Advisories nicht. Alle fünf Lücken brauchen file_server, php_fastcgi, FrankenPHP php_server, try_files mit einer Umschreibung oder ein root, das aus {host} gebaut wird (der Kommandozeilenaufruf caddy file-server zählt zu file_server). Das ist eine Ableitung aus den Vorbedingungen, kein Test mit einem Angriff. Eine Ausnahme bleibt CVE-2026-55458, die auch reverse_proxy berührt (niedrig, siehe unten).

Warum sollte man trotzdem auf 2.11.9 gehen?+

Die Version 2.11.9 behebt eine Regression aus 2.11.8 und härtet FastCGI zusätzlich. Wer Version 2.11.8 überspringt, spart sich die Regression. Es gibt auch Breaking Changes, die vor dem Update zu testen sind.

Wie prüfe ich in einer Minute, ob mein Caddyfile betroffen ist?+

Mit grep nach den Direktiven file_server, php_fastcgi, php_server, try_files und root im Caddyfile, dazu ein Blick auf Aufrufe von caddy file-server. Ohne Treffer fehlt die Vorbedingung. Bei Treffern prüfen Sie, ob das root einen Platzhalter wie {host} enthält.

Zurück zum Blog Security und Datenschutz