Kurz gesagt: FrankenPHP ist ein Anwendungsserver auf Basis von Caddy, der PHP in sein eigenes Programm einbettet. Für die FrankenPHP Sicherheit nach PHP2Shell heißt das: Nicht die PHP-Pakete der Distribution zählen, sondern die PHP-Version im FrankenPHP-Binary oder Container-Image. Bauen oder laden Sie eine Fassung mit behobenem PHP und starten Sie alle Worker neu.
Warum FrankenPHP anders gepatcht wird
Bei klassischen Setups liefert die Distribution PHP als Paket, und ein Update tauscht die Dateien aus. FrankenPHP dagegen enthält PHP als eingebettete Bibliothek. Wer das offizielle Binary oder ein darauf aufbauendes Container-Image nutzt, bekommt PHP mitgeliefert. Ein apt upgrade auf dem Host ändert daran nichts.
PHP2Shell umfasst CVE-2026-109618 und CVE-2026-109619, jeweils mit CVSS v4.0 9.2. Das PHP-Projekt führt FrankenPHP ausdrücklich unter den betroffenen Betriebsarten. Behoben sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Entscheidend ist also, gegen welche PHP-Version Ihr FrankenPHP gebaut wurde.
Worker-Modus und PHP2Shell
FrankenPHP kann Anwendungen im Worker-Modus betreiben. Dabei wird die Anwendung einmal geladen und bearbeitet dann viele Anfragen hintereinander im selben Prozess. Das bringt Geschwindigkeit, verlängert aber die Lebensdauer jedes Prozesses.
CVE-2026-109619 beschreibt internen Zustand einer Anfrage, der nach dem Freigeben des Speichers bestehen bleiben kann; eine spätere Anfrage im selben Worker kann ihn nutzen, bevor er zurückgesetzt wird. Im Worker-Modus ist das Zusammenspiel vieler Anfragen in einem Prozess der Normalfall. Das ist kein Grund, auf den Worker-Modus zu verzichten, aber ein klarer Grund, Updates und Neustarts besonders sorgfältig umzusetzen. Technische Details stehen unter CVE-2026-109619.
FrankenPHP Sicherheit: Version prüfen
Prüfen Sie die eingebettete PHP-Version direkt im laufenden System. Die folgenden Befehle lesen nur; Namen von Diensten und Containern sind Beispiele.
# Installiertes Binary
frankenphp version
# Im laufenden Container (Containername als Beispiel)
docker exec app frankenphp version
docker exec app php -v
# Welches Image läuft tatsächlich? (Digest zeigt den exakten Stand)
docker inspect --format '{{.Image}} {{.Config.Image}}' app
Notieren Sie die PHP-Version aus der Ausgabe. Liegt sie vor den behobenen Ständen, ist das System verwundbar. Prüfen Sie immer den laufenden Container, nicht nur das zuletzt gebaute Image, denn ein neues Image wirkt erst nach dem Austausch der Container.
Update einspielen und alle Worker neu starten
Wie das Update aussieht, hängt von Ihrer Installation ab:
- Binary auf dem Host: neues FrankenPHP-Release mit behobener PHP-Version installieren, Dienst neu starten.
- Container: Basis-Image mit behobener PHP-Version beziehen, eigenes Image neu bauen, ohne Cache für die Basisschicht, Container ersetzen.
- Selbst kompiliert: gegen die behobene PHP-Version neu bauen, alle Erweiterungen mit derselben Version neu erzeugen.
# Beispiel Host-Installation als systemd-Dienst
systemctl restart frankenphp
# Beispiel Docker Compose: neu bauen ohne Cache und Container ersetzen
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Danach prüfen Sie erneut die PHP-Version im laufenden Container und die Startzeit der Prozesse. Im Worker-Modus muss jeder Worker neu gestartet sein. Bei Kubernetes gelten zusätzliche Schritte, beschrieben unter PHP in Kubernetes patchen, für Container allgemein unter PHP in Docker-Containern patchen.
Ein Tag wie latest oder eine Hauptversion im Image-Namen garantiert nicht, dass Sie den neuesten Stand haben. Ziehen Sie das Basis-Image aktiv neu und prüfen Sie danach die PHP-Version im laufenden Container.
Übergangsmaßnahmen und Härtung
Kann das Update nicht sofort erfolgen, empfiehlt php.net Übergangsmaßnahmen, die keinen vollständigen Schutz bieten. Bei FrankenPHP setzen Sie die Werte in der php.ini, die FrankenPHP lädt, oder über die PHP-Einstellungen in der Caddy-Konfiguration, nicht per ini_set() in der Anwendung.
; php.ini im Container oder auf dem Host
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Mit Upload-Funktion nennt php.net post_max_size = 32M. Auf PHP 8.5 kommt fatal_error_backtraces=0 hinzu. Die Speichergrenze gehört auf Container-Ebene, etwa per Speicherlimit des Containers, nicht über RLIMIT_AS oder RLIMIT_DATA. Nach jeder Änderung alle Worker neu starten.
Für den Dauerbetrieb lohnt es sich, Images mit festem Digest zu referenzieren, regelmäßig automatisiert neu zu bauen und einen Image-Scanner in die Build-Kette zu nehmen. Ein Patch entfernt außerdem keine Schadsoftware, die vorher eingeschleust wurde. Bewahren Sie Logs ab dem 20.10.2026 auf; bei Containern heißt das, sie vor dem Ersetzen zu sichern.
Wer FrankenPHP als statisch gebautes Binary nutzt, sollte wissen, dass dort neben PHP auch alle Erweiterungen fest eingebaut sind. Ein Update bedeutet deshalb immer, das gesamte Binary zu ersetzen. Prüfen Sie nach dem Austausch die Version und die Liste der geladenen Erweiterungen, ob alles wie zuvor verfügbar ist, und testen Sie die Anwendung, bevor Sie den alten Stand verwerfen. In Container-Umgebungen empfiehlt sich, jedes Image mit dem Datum des Builds zu kennzeichnen. So können Sie jederzeit nachvollziehen, welcher Stand wann lief, und im Zweifel gezielt zurückgehen, ohne erneut auf einen verwundbaren Stand zu fallen. Halten Sie die Zuordnung von Image, PHP-Version und Zeitpunkt in Ihrer Dokumentation fest.
Wie hilft PHP SOS konkret?
- Wir prüfen, welche PHP-Version in Ihren FrankenPHP-Binaries und laufenden Containern tatsächlich steckt.
- Über den PHP-Patch-Service bauen wir Images neu, ersetzen Container und starten alle Worker neu, mit Nachweis.
- Wir sichern Logs vor dem Austausch und prüfen die Anwendung auf Spuren.
- Für den Dauerbetrieb richten wir automatisierte Rebuilds und Image-Prüfungen im Rahmen der Server-Härtung ein.
Häufige Fragen
Hilft ein apt- oder dnf-Update bei FrankenPHP?
Nur, wenn FrankenPHP selbst aus diesen Paketquellen stammt und gegen das gepatchte PHP gebaut ist. Häufig ist PHP fest im FrankenPHP-Binary oder im Container-Image enthalten. Dann müssen Sie Binary oder Image aktualisieren.
Warum ist der Worker-Modus bei PHP2Shell besonders wichtig?
Im Worker-Modus bleibt die Anwendung im Speicher und bearbeitet viele Anfragen nacheinander im selben Prozess. CVE-2026-109619 betrifft genau internen Zustand, der zwischen Anfragen im selben Worker bestehen bleiben kann. Ein Neustart aller Worker nach dem Update ist deshalb Pflicht.
Wie prüfe ich, welche PHP-Version in FrankenPHP steckt?
Das FrankenPHP-Binary gibt beim Versionsaufruf die eingebettete PHP-Version aus. Im Container können Sie den Befehl über docker exec ausführen. Achten Sie darauf, die Version im tatsächlich laufenden Container zu prüfen, nicht im neu gebauten Image.
Gibt es für FrankenPHP eigene Übergangsmaßnahmen?
Es gelten die allgemeinen Hinweise von php.net. Sie setzen die Werte in der php.ini, die FrankenPHP lädt, oder in der PHP-Konfiguration der Caddy-Datei, nicht per ini_set() in der Anwendung. Danach alle Worker neu starten.