Am 21. Oktober 2026 veröffentlichte das PHP-Projekt außerplanmäßig einen Fix für zwei
kritische, nicht authentifizierte Schwachstellen zur Remotecodeausführung, geführt als
CVE-2026-109618 und CVE-2026-109619 und mit 9,2 auf der CVSS-v4.0-Skala bewertet. Die
Forscher, die sie entdeckten, nannten das Duo „PHP2Shell“. Die korrigierten Versionen 8.5.12,
8.4.27, 8.3.36 und 8.2.35 sind seit dem 22. Oktober verfügbar.
Zwei nicht authentifizierte Lücken, bereits angegriffen
Beide Schwachstellen betreffen die Verarbeitung eingehender Anfragen durch exponierte
PHP-Installationen, ganz ohne vorherige Authentifizierung. Cloudflare und das
Sicherheitsunternehmen watchTowr berichten von aktiven Ausnutzungsversuchen bereits wenige
Stunden nach der Offenlegung, weshalb die US-Behörde CISA am 21. Oktober eine Warnung mit der
dringenden Empfehlung zum sofortigen Update veröffentlichte. Ein Sicherheitsanbieter schätzt,
dass fast zwei Millionen PHP-Server potenziell betroffen sind.
Keine Konfigurationsänderung reicht aus
Das PHP-Projekt stellt klar, dass keine Konfigurationseinstellung beide Lücken vollständig
neutralisiert: Das Binär-Update ist der einzige vollständige Schutz. Nach der Installation des
Patches müssen die PHP-FPM-Worker oder der Anwendungsserver neu gestartet werden, sonst läuft
der alte, verwundbare Code weiter im Speicher.
| Zweig | Korrigierte Version | Patch-Status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Aktiver Zweig, vollständiger Fix |
| PHP 8.4 | 8.4.27 | Aktiver Zweig, vollständiger Fix |
| PHP 8.3 | 8.3.36 | Nur Sicherheitsupdates, vollständiger Fix |
| PHP 8.2 | 8.2.35 | Nur Sicherheitsupdates, vollständiger Fix |
| PHP 8.1 und älter | Keine offizielle Version | End of Life, einige Anbieter liefern Quell-Patches |
Einen Produktionsserver aktualisieren
Auf einer Debian- oder Ubuntu-Maschine mit den offiziellen PHP-Repositories läuft die
Behebung auf ein Paket-Upgrade mit anschließendem Neustart der betroffenen Dienste hinaus:
php -v
sudo apt update
sudo apt install --only-upgrade php8.4 php8.4-fpm
sudo systemctl restart php8.4-fpm nginx
Shared-Hoster und Panels wie Plesk haben eigene korrigierte Builds veröffentlicht; Teams,
die einen selbst gehosteten Server
betreiben, sollten vor der Entwarnung die von php -v gemeldete Version prüfen,
auch auf Instanzen, auf denen PHP unauffällig hinter einem CMS läuft.
Keine Konfigurationsänderung neutralisiert beide Lücken vollständig: Nur das Binär-Update, gefolgt von einem Neustart der PHP-Prozesse, schließt das Zeitfenster der Verwundbarkeit.
Ein bereits bekanntes Muster aus dem WordPress-Ökosystem
Die Geschwindigkeit der Ausnutzung erinnert an ein Muster, das auf dieser Seite bereits
dokumentiert wurde: eine
kritische WordPress-Lücke, die fünf Tage nach ihrem Patch aktiv angegriffen wurde.
Websites, deren PHP-Unterbau nicht gehärtet ist, bleiben die ersten Ziele, sobald ein Exploit
öffentlich wird, unabhängig vom aufgesetzten CMS; die Grundlagen einer
minimalen WordPress-Härtung
verkleinern die Angriffsfläche, ersetzen aber nicht das Update des Interpreters selbst.
PHP-Projekt. Websites, die noch darauf laufen, bleiben verwundbar, solange sie nicht auf einen
gepflegten Zweig migrieren.
Was bleibt
Zwei kritische Schwachstellen, ohne Authentifizierung ausnutzbar und bereits aktiv
angegriffen, betreffen jeden gepflegten PHP-Zweig. Die Behebung erfordert ein Update auf
8.5.12, 8.4.27, 8.3.36 oder 8.2.35 je nach verwendetem Zweig, gefolgt von einem Neustart der
PHP-Prozesse. Versionen vor 8.2, inzwischen End of Life, haben keinen offiziellen Patch und
sollten vorrangig migriert werden.
Bei Projekten, bei denen ich die Infrastruktur verwalte, gehört diese Art von
außerplanmäßiger Warnung zu den seltenen Fällen, in denen ich die Deployment-Queue des Tages
anhalte, um den Patch vor allem anderen einzuspielen. Die Erfahrung mit blitzschnellen
Ausnutzungen bei WordPress in den vergangenen Monaten zeigt, dass die Zeitspanne zwischen
Offenlegung und automatisiertem Angriff inzwischen in Stunden, nicht in Tagen gemessen wird.
Ein einfacher Cron-Job zur Prüfung der PHP-Version, kombiniert mit einer Warnmeldung, kostet
deutlich weniger als ein kompromittierter Server an einem Sonntagabend. —
Simon Janvier
Weiterführend: das offizielle PHP-8.x-Changelog.
