Sicherheit · 24. Oktober 2026
PHP veröffentlicht Notfall-Patches für kritische PHP2Shell-Schwachstellen
Das PHP-Projekt hat dringende Sicherheitsupdates veröffentlicht, um zwei kritische Schwachstellen im PHP-Laufzeitumfeld zu beheben, die gemeinsam als PHP2Shell bezeichnet werden. Diese Sicherheitslücken ermöglichen es Angreifern ohne gültige Benutzerkonten, beliebigen Code auf Webservern auszuführen. Die Sicherheitsfirmen watchTowr und Cloudflare haben bereits erste Angriffsversuche gegen diese Schwachstellen dokumentiert.
Die beiden identifizierten Sicherheitslücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Beide Schwachstellen wurden mit einem Score von 9,2 nach der CVSS v4.0-Skala bewertet. Die Entdeckung geht auf die Forschungsabteilungen von Wiz, Calif und das Codex Security Team von OpenAI zurück. Die Lücken betreffen nahezu alle PHP-Versionen, die bis auf PHP 5.4 zurückreichen. Die behobenen Versionen umfassen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Die besondere Gefährlichkeit dieser Schwachstellen liegt darin, dass sie im Kern der PHP-Engine selbst sitzen und nicht im Anwendungscode. Dadurch sind selbst Websites, die nur eine einfache Begrüßungsseite anzeigen oder besonders sicher codiert sind, angreifbar. Laut der Sicherheitsmeldung des PHP-Projekts sind alle PHP-Installationen, die Webdienste bereitstellen, betroffen. Dies gilt für PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed.
Systeme, die Apache mod_php verwenden, gelten als am stärksten gefährdet. Es wurde ein Exploit demonstriert, der mit nur einer einzigen Anfrage auskommt, keine Authentifizierung erfordert und bereits vor der Ausführung des Anwendungscode greift. PHP-FPM verhält sich anders, da es Worker-Prozesse schließt, wenn eine Anfrage frühzeitig fehlschlägt. Für CVE-2026-109618 ist PHP-FPM zwar gefährdet, es wurde jedoch noch kein vollständiger Exploit nachgewiesen. Bei CVE-2026-109619 konnte die Codeausführung sowohl auf mod_php als auch auf PHP-FPM nachgewiesen werden, wobei der Weg über FPM bestimmte interne Abläufe der Anwendung voraussetzt.
Zusätzlich können Angreifer den Arbeitsspeicher der PHP-Worker-Prozesse lesen, ohne vorher Code auszuführen. In diesem Speicher können sensible Daten wie Authentifizierungstokens, API-Schlüssel und Zertifikate von anderen Anfragen enthalten sein. Die Forscher haben das Auslesen dieses Speichers an Anwendungen demonstriert, die nicht unter ihrer Kontrolle standen.
Administratoren sollten das PHP-Laufzeitumfeld umgehend aktualisieren und anschließend Apache, PHP-FPM und alle dauerhaft laufenden PHP-Worker neu starten. Es ist wichtig zu beachten, dass das Aktualisieren von Anwendungen wie WordPress oder Laravel das PHP-Laufzeitumfeld nicht mit aktualisiert, da dieses aus Server-Paketen, Hosting-Diensten oder Container-Images stammt. Für PHP 8.1 und ältere Versionen, die keine offiziellen Updates mehr erhalten, hat das PHP-Team Quellcode-Backports für PHP 7.4, 8.0 und 8.1 bereitgestellt. Die Unterstützung für PHP 8.2 endet am 31. Dezember 2026.
Linux-Distributionen und Anbieter von Langzeit-Support haben die Patches vorab erhalten. Daher können die Pakete der Distributionen bereits behoben sein, selbst wenn die Versionsnummer alt aussieht. Es wird empfohlen, die Änderungsprotokolle auf die entsprechenden CVE-Nummern zu prüfen, anstatt sich nur auf die Versionsnummer zu verlassen. Nach dem Update sollten die Parameter memory_limit und post_max_size überprüft werden, da der Patch eine neue harte Speicherbeschränkung einführt, die Prozesse sofort beendet, wenn das Limit erreicht ist, wodurch Shutdown-Handler nicht mehr ausgeführt werden.
Das PHP-Projekt betont, dass das Update die einzige vollständige Lösung ist. Temporäre Maßnahmen können nur bestimmte Angriffswege abschwächen. Für CVE-2026-109618 wird empfohlen, memory_limit auf -1 zu setzen, post_max_size niedrig zu halten und die Anfragegröße auf Webserver-Ebene zu begrenzen. Die Verwendung von RLIMIT_AS oder RLIMIT_DATA ist zu vermeiden, da dies den fehlerhaften Codepfad auslösen könnte. Für CVE-2026-109619 sollte session.upload_progress.enabled auf 0 gesetzt und alle Worker neu gestartet werden. Auf PHP 8.5 sollte zusätzlich fatal_error_backtraces auf 0 gesetzt werden. Diese Maßnahme blockiert jedoch nur den Pfad über authentizierte Sessions und deckt andere Angriffsformen nicht ab.
watchTowr berichtet über Angriffsversuche gegen beide Schwachstellungen. Cloudflare hat festgestellt, dass Angreifer ihre Nutzlasten anpassen, um die WAF-Regeln von Cloudflare zu umgehen. Es liegen noch keine bestätigten Berichte über erfolgreiche Systemkompromittierungen vor. Die Forscher empfehlen, ungewöhnliche multipart-Requests zu überwachen, die von Fehlern bezüglich der Speicherbeschränkung oder wiederholten HTTP-500-Fehlern gefolgt sind. Auch ungewöhnlich große PHPSESSID-Cookies und unerklärliche Neustarts von PHP-Worker-Prozessen sollten als Warnsignale beachtet werden.