Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßige Sicherheitsupdates veröffentlicht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie schließen zwei Lücken, die unter dem Namen „PHP2Shell“ die Runde machen – CVE-2026-109618 und CVE-2026-109619, beide mit dem Schweregrad 9.2 von 10 bewertet. Wenige Stunden nach der Veröffentlichung wurden bereits Angriffsversuche beobachtet.
Wir haben die Lücken bei allen von uns betreuten Kunden-Systemen in weniger als 24 Stunden nach Bekanntgabe geschlossen – auf Docker-Umgebungen genauso wie auf klassischen Ubuntu-Servern. In diesem Beitrag erklären wir, was hinter den Lücken steckt, wie wir vorgegangen sind und was Sie prüfen sollten, wenn Sie selbst PHP-Anwendungen betreiben.
Was ist passiert?
- 20. Oktober: Details zu den Lücken gelangen vorzeitig an die Öffentlichkeit. Das PHP-Projekt kündigt daraufhin für den Folgetag ein Sicherheitsupdate an.
- 21. Oktober, 14:00 Uhr UTC: Die gepatchten Versionen erscheinen.
- Am selben Nachmittag melden Sicherheitsfirmen die ersten Angriffsversuche auf beide Lücken.
Warum diese Lücken so gefährlich sind
Sie stecken in PHP selbst, nicht in Ihrer Anwendung. Auch eine fehlerfrei programmierte Website ist betroffen, wenn die PHP-Laufzeit darunter verwundbar ist. Ein Update von WordPress, Laravel oder einem Shop-System ändert daran nichts – aktualisiert werden muss PHP selbst.
Ein Angreifer braucht keine Anmeldung. Beide Lücken erlauben es im schlimmsten Fall, aus der Ferne und ohne Zugangsdaten eigenen Code auf dem Server auszuführen. Zusätzlich können unter Umständen Daten aus anderen Anfragen ausgelesen werden – etwa Passwörter, Tokens oder API-Schlüssel.
Fast alle Installationen sind betroffen. Verwundbar sind nahezu alle PHP-Versionen bis zurück zu 5.4 und alle gängigen Betriebsarten, mit denen PHP Webseiten ausliefert: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Am stärksten gefährdet ist Apache mit mod_php.
Kurz zur Technik: CVE-2026-109618 wird ausgelöst, wenn PHP beim Aufbau einer Anfrage der Speicher ausgeht. CVE-2026-109619 betrifft internen Zustand, der eine Anfrage überdauert und dann von der nächsten Anfrage im selben Prozess weiterverwendet werden kann. Einer der bekannten Angriffswege nutzt dabei die Funktion „Session Upload Progress“, die standardmäßig aktiviert ist.
Wie wir vorgegangen sind
1. Wissen, was wo läuft. Für jedes betreute System ist dokumentiert, welche PHP-Version in welcher Betriebsart läuft. Damit stand innerhalb weniger Minuten fest, welche Systeme betroffen sind und in welcher Reihenfolge wir vorgehen – zuerst alles, was direkt aus dem Internet erreichbar ist.
2. Sofortmaßnahmen bis zum Patch. Wo es sinnvoll war, haben wir schon vor dem Update die vom PHP-Projekt empfohlenen Übergangsmaßnahmen gesetzt, unter anderem session.upload_progress.enabled = 0 und enge Größenlimits für Anfragen. Das schließt die Lücken nicht vollständig, erschwert aber die bekannten Angriffswege.
3. Docker-Umgebungen: Image neu bauen statt Container flicken. Bei containerisierten Anwendungen haben wir das PHP-Basis-Image auf die gepatchte Version angehoben, das Image über die CI-Pipeline neu gebaut, automatisiert getestet und die laufenden Container ersetzt. Wichtig: Einen laufenden Container „von innen“ zu aktualisieren reicht nicht – beim nächsten Neustart würde wieder das alte, verwundbare Image gestartet.
4. Ubuntu-Server: Sicherheitsupdates einspielen und alle Prozesse neu starten. Auf klassischen Servern haben wir die aktualisierten PHP-Pakete aus der jeweiligen Paketquelle eingespielt. Entscheidend ist der zweite Schritt: PHP-FPM, Apache und alle dauerhaft laufenden PHP-Prozesse – etwa Queue-Worker – neu starten. Solange ein alter Prozess läuft, läuft auch der alte, verwundbare Code.
5. Prüfen, was wirklich läuft. php -v zeigt nur die Version auf der Kommandozeile – die kann sich von der Version unterscheiden, mit der PHP-FPM oder Apache tatsächlich Ihre Website ausliefern. Wir haben deshalb die Version geprüft, die im Webserver-Prozess aktiv ist. Bei Distributionspaketen kann eine korrigierte Version zudem eine „alt aussehende“ Versionsnummer tragen; maßgeblich ist, ob das Paket-Changelog die beiden CVE-Nummern nennt.
6. Nacharbeit. Der Fix führt eine harte Speichergrenze ein: Erreicht ein Prozess sie, wird er beendet. Wir haben deshalb memory_limit und post_max_size gegen die Anforderungen der jeweiligen Anwendung geprüft und die Logs auf Auffälligkeiten durchgesehen – etwa ungewöhnliche Multipart-Anfragen, gefolgt von Speicherfehlern oder auffällig vielen 500-Fehlern.
Warum das so schnell ging
Schnelligkeit war hier kein Glück, sondern eine Folge davon, wie die Systeme aufgebaut sind: Wir wissen, was wo läuft. Container-Images entstehen reproduzierbar in einer Pipeline und lassen sich in Minuten neu bauen und ausrollen. Und es gibt eine klare Zuständigkeit – niemand musste erst herausfinden, wer sich um welchen Server kümmert.
Was Sie jetzt prüfen sollten
- Läuft auf Ihrem Server eine gepatchte Version? Mindestens 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 – oder ein Distributionspaket, dessen Changelog CVE-2026-109618 und CVE-2026-109619 nennt.
- Wurden nach dem Update alle PHP-Prozesse neu gestartet? PHP-FPM, Apache, Worker.
- Wurden Container-Images neu gebaut – nicht nur laufende Container aktualisiert?
- Läuft noch PHP 8.1 oder älter? Für diese Versionen gibt es keine offiziellen Updates mehr. Hier hilft auf Dauer nur ein Upgrade. Auch PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitsupdates.
- Gibt es Hinweise auf einen Angriff? Bei Verdacht sollten Zugangsdaten, Tokens und Schlüssel ausgetauscht werden, die auf dem Server gespeichert sind.
Wenn Sie unsicher sind, wie es um Ihre Systeme steht, oder Ihre Anwendung noch auf einer veralteten PHP-Version läuft: Software-Rettung & Upgrade ist genau unser Thema – sprechen Sie uns an.
Quellen: php.net – Ankündigungen und Sicherheitshinweise vom 20. und 21. Oktober 2026 · The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws · watchTowr: CVE-2026-109618 FAQ · Aikido: PHP2Shell – how to fix
