Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die unter dem Namen PHP2Shell bekannt geworden sind. Über CVE-2026-109618 und CVE-2026-109619 können Angreifer ohne Anmeldung eigenen Code auf einem Webserver ausführen, im schlimmsten Fall schon bevor die eigentliche Anwendung startet. Beide Lücken sind mit 9.2 von 10 Punkten als kritisch eingestuft und betreffen praktisch jede PHP-Installation, die Webseiten ausliefert. Abhilfe schaffen die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das BSI rät, sofort zu aktualisieren oder betroffene Server notfalls vom Netz zu nehmen.

PHP2Shell. Was die kritischen PHP-Lücken CVE-2026-109618 und CVE-2026-109619 für Ihre Website bedeuten

Was ist PHP2Shell?

PHP2Shell ist der Sammelname für zwei Schwachstellen im Kern von PHP. Sie stecken also weder in einem Plugin noch in WordPress selbst, sondern in der Programmiersprache, auf der diese Systeme laufen. Laut W3Techs nutzen 69,3 Prozent aller Websites, deren Serversprache bekannt ist, PHP. Allein WordPress betreibt 39,6 Prozent aller Websites weltweit.

Entdeckt haben die Fehler mehrere Teams unabhängig voneinander. Ryan Austin von Calif und Amy Burnett von OpenAI meldeten die Ursache am 11. August 2026, Wiz Research folgte am 24. August. Ursprünglich war die Veröffentlichung für den 22. Oktober geplant. Weil die CVE-Nummern am 20. Oktober vorzeitig durchsickerten, hat das PHP-Projekt die Updates einen Tag früher freigegeben, am 21. Oktober um 16 Uhr deutscher Zeit.

Die Forscher haben Angriffe ohne Anmeldung gegen WordPress, Drupal und Joomla vorgeführt. Calif nennt zusätzlich Magento, MediaWiki und Nextcloud.

Wie funktionieren die beiden Lücken?

Beide Fehler drehen sich darum, wie PHP mit Speicher umgeht, wenn eine Anfrage abbricht.

CVE-2026-109618 betrifft den Fall, dass PHP der Arbeitsspeicher ausgeht. PHP bricht dann die Anfrage ab. Passiert das in einem ungünstigen Moment, etwa während die Daten einer Anfrage gerade erst eingelesen werden, behandelt das anschließende Aufräumen ungültigen Speicher wie gültigen. Ein Angreifer kann das mit präparierten Formular- oder Upload-Anfragen gezielt auslösen. Bei Apache mit mod_php reicht dafür eine einzige Anfrage mit Standardeinstellungen, noch bevor ein einziges Skript Ihrer Anwendung läuft.

CVE-2026-109619 nutzt aus, dass ein PHP-Prozess nach einer abgebrochenen Anfrage noch Verweise auf bereits freigegebenen Speicher behalten kann. Landet danach eine zweite Anfrage beim selben Prozess, greift sie auf diesen veralteten Zustand zu. So lassen sich Speicherinhalte auslesen und Code ausführen. Bestätigte Wege führen über die Funktion für den Upload-Fortschritt von Sessions und unter PHP 8.5 über erweiterte Fehlerberichte.

Für beide Lücken braucht ein Angreifer weder ein Konto noch die Mithilfe eines Nutzers. Ein Zugang über das Netz genügt.

Welche Server sind betroffen?

Das PHP-Projekt schreibt, dass alle PHP-Installationen betroffen sind, die Webanfragen verarbeiten. Das Risiko unterscheidet sich allerdings je nachdem, wie PHP eingebunden ist.

Betriebsart	Risiko laut Advisory
Apache mit mod_php	am höchsten, Angriff vor jedem Anwendungscode nachgewiesen
PHP-FPM (typisch mit nginx)	Angriff über Upload-Fortschritt bestätigt, weitere Wege über die Anwendung möglich
FrankenPHP	wahrscheinlich anfällig
LiteSpeed	wahrscheinlich oder unter Bedingungen anfällig
php-cgi	betroffen

Viele günstige Webhosting-Pakete und ältere Server setzen noch auf Apache mit mod_php. Wer hier eine Website betreibt, sollte besonders schnell handeln. Bei Shared Hosting liegt das Update beim Anbieter. Der Hoster Uberspace hat laut heise PHP vorübergehend ganz abgeschaltet, bis die Updates installiert waren.

Welche PHP-Versionen schließen die Lücken?

Das PHP-Projekt hat für alle noch unterstützten Versionszweige Updates veröffentlicht.

Zweig	Sichere Version	Sicherheitsupdates bis
PHP 8.5	8.5.12	31. Dezember 2029
PHP 8.4	8.4.27	31. Dezember 2028
PHP 8.3	8.3.36	31. Dezember 2027
PHP 8.2	8.2.35	31. Dezember 2026

Wichtig ist, dass Linux-Distributionen eigene Versionsnummern verwenden. Debian, Ubuntu und Red Hat übernehmen die Korrekturen oft in ältere Versionen. Ubuntu hat am 21. Oktober Updates für die Versionen 22.04 bis 26.10 veröffentlicht, für ältere Versionen über Ubuntu Pro. Debian hat die Korrekturen für Debian 13 sofort ausgeliefert, für Debian 12 war das Update angekündigt, aber am Nachmittag des 21. Oktober noch nicht für alle Prozessorarchitekturen im Archiv. Die offiziellen Docker-Images von PHP sind ebenfalls aktualisiert.

Für PHP 8.2 ist außerdem Ende in Sicht. Am 31. Dezember 2026 laufen die Sicherheitsupdates aus. Wer jetzt ohnehin patcht, sollte den Umstieg auf 8.3 oder 8.4 gleich mit einplanen.

Was ist mit PHP 8.1, 7.4 und älter?

Für PHP 8.1 und ältere Versionen gibt es keine offiziellen Updates. PHP 8.1 bekommt seit dem 31. Dezember 2025 keine Sicherheitskorrekturen mehr. Das PHP-Projekt hat für 7.4, 8.0 und 8.1 zwar die Korrekturen im Quellcode bereitgestellt, eine fertige Version zum Installieren gibt es dafür aber nicht.

Das Problem ist groß. Nach den Zahlen von W3Techs laufen 27 Prozent der PHP-Websites noch auf PHP 7 und 7,7 Prozent sogar auf PHP 5. Rechnet man die nicht mehr unterstützten Versionen von PHP 8 hinzu, arbeitet fast die Hälfte aller PHP-Websites mit einer Version ohne offiziellen Support. Wer eine solche Website betreibt, sollte das Update auf eine aktuelle PHP-Version nicht länger aufschieben. Oft hängt daran auch ein veraltetes CMS oder Plugin, das dabei gleich mit erneuert werden muss.

Wird PHP2Shell schon ausgenutzt?

Die Lage ist am Tag der Veröffentlichung uneinheitlich. Die Sicherheitsfirma watchTowr meldet Angriffe auf ihre Testsysteme seit dem 21. Oktober, Cloudflare hat nach eigenen Angaben Angriffsversuche auf Kunden beobachtet. Das BSI und die Sicherheitsfirma Huntress sprechen dagegen noch von unbestätigten Berichten. In der US-Liste der aktiv ausgenutzten Schwachstellen der Behörde CISA stehen die Lücken bisher nicht.

Für die Praxis spielt das kaum eine Rolle. Angriffscode kursiert bereits, und das BSI rechnet mit breiter Ausnutzung innerhalb von Stunden. Wie schnell so etwas gehen kann, hat zuletzt die Exchange-Lücke CVE-2026-62911 gezeigt.

Was sollten Betreiber jetzt sofort tun?

1. Version prüfen. Auf dem Server zeigt der Befehl php -v die installierte Version. Bei PHP-FPM prüfen Sie zusätzlich den laufenden Dienst, etwa mit php-fpm8.2 -v. Bei Shared Hosting finden Sie die Version im Kundenmenü Ihres Anbieters.
2. Updates einspielen. Installieren Sie die Pakete Ihrer Distribution oder die neuen Versionen von php.net. Auf Debian und Ubuntu reicht in der Regel apt update und apt upgrade.
3. Dienste neu starten. Ein installiertes Update wirkt erst, wenn PHP-FPM beziehungsweise Apache neu gestartet wurde. Alte Prozesse laufen sonst mit dem verwundbaren Code weiter.
4. mod_php abschalten, wo es nicht gebraucht wird. Ist auf einem Server noch Apache mit mod_php installiert, obwohl die Seiten längst über nginx und PHP-FPM laufen, sollten Sie das Modul deaktivieren. So verschwindet die Variante mit dem höchsten Risiko.
5. Automatische Sicherheitsupdates einrichten. Unter Debian und Ubuntu übernimmt das Paket unattended-upgrades das Einspielen von Sicherheitsupdates. Damit landet ein verspäteter Patch automatisch auf dem Server, sobald er erscheint.
6. Nach Spuren suchen. Ein Update entfernt keine Hintertür, die schon installiert wurde. Mehr dazu im nächsten Abschnitt.

Was tun, wenn das Update noch nicht verfügbar ist?

Genau diesen Fall hatten wir am 21. Oktober selbst. Auf Servern mit Debian 12, die wir betreuen, war das korrigierte Paket am Nachmittag angekündigt, aber noch nicht installierbar. Die offiziellen Hinweise nennen für diese Zeit einige Übergangsmaßnahmen. Sie ersetzen das Update nicht, verkleinern aber die Angriffsfläche.

• Upload-Fortschritt abschalten. Mit session.upload_progress.enabled = 0 in der php.ini oder der Pool-Konfiguration schließen Sie die bestätigten Angriffswege für CVE-2026-109619. Danach müssen alle PHP-Prozesse neu starten. Die Einstellung per ini_set oder .user.ini reicht nicht.
• Fehlerberichte begrenzen. Unter PHP 8.5 sollte fatal_error_backtraces auf 0 stehen.
• Anfragegrößen begrenzen. Halten Sie post_max_size so klein wie möglich, etwa 8 MB ohne Uploads oder 32 MB mit Uploads. Begrenzen Sie zusätzlich im Webserver oder Proxy die Größe und Struktur von Anfragen.
• Keine Speicherlimits über das Betriebssystem setzen. Die Advisories warnen ausdrücklich davor, den Speicher über RLIMIT_AS oder RLIMIT_DATA zu begrenzen, weil genau das den fehlerhaften Pfad auslöst. Grenzen über Container oder cgroups sind dagegen in Ordnung.
• Web Application Firewall nutzen. Cloudflare hat seit dem 21. Oktober Schutzregeln für alle Tarife aktiv, auch für den kostenlosen. Cloudflare selbst bezeichnet sie nur als Ergänzung zum Update.
• Im Notfall vom Netz nehmen. Das BSI empfiehlt, Server ohne Update vorübergehend vom Internet zu trennen oder nur noch reine Leseanfragen zuzulassen.

Woran erkennen Sie einen Angriff?

Die Forscher hinter PHP2Shell nennen einige Warnzeichen, auf die Sie in den Logs Ihres Webservers achten sollten.

• auffällig große oder fehlerhafte Session-Cookies mit dem Namen PHPSESSID
• Formular- oder Upload-Anfragen, auf die Fehlermeldungen zum Speicherlimit oder HTTP-Fehler 500 folgen
• abstürzende PHP-Prozesse in den Logs von PHP-FPM oder Apache
• unbekannte PHP-Dateien in Upload-Ordnern oder im Webverzeichnis
• neue Administratorkonten im CMS, die niemand angelegt hat

Finden Sie solche Spuren, trennen Sie den Server vom Netz, sichern Sie die Logs, setzen Sie alle Zugangsdaten zurück und ziehen Sie eine Fachfirma hinzu. Sind personenbezogene Daten betroffen, kann eine Meldepflicht nach DSGVO bestehen.

Wie unterstützt 0x.systems bei PHP-Updates und Serversicherheit?

Bei 0x.systems betreiben und betreuen wir Websites, Shops und Webanwendungen auf eigenen Servern in Deutschland. Am Tag der Veröffentlichung haben wir unsere Systeme geprüft, die PHP-Pakete aktualisiert, nicht benötigtes mod_php abgeschaltet, die Übergangsmaßnahmen gesetzt und automatische Sicherheitsupdates eingerichtet, damit der endgültige Patch ohne Verzögerung ankommt.

Das Gleiche übernehmen wir gerne für Ihre Server. Wir prüfen kurzfristig Ihre PHP-Version und Konfiguration, spielen Updates ein, suchen nach Spuren eines Angriffs und planen mit Ihnen den Umstieg von PHP 7 oder 8.1 auf eine aktuelle Version, inklusive der Anpassungen an CMS und Plugins. Auf Wunsch übernehmen wir danach Monitoring und Updates dauerhaft.

Schreiben Sie uns über unser Kontaktformular, wir melden uns schnell. Einen Überblick über die allgemeine Bedrohungslage finden Sie in unserem Beitrag zur IT-Sicherheit 2026.

Häufige Fragen

Was ist PHP2Shell?

PHP2Shell ist der Name für die beiden kritischen PHP-Lücken CVE-2026-109618 und CVE-2026-109619. Sie erlauben es Angreifern, ohne Anmeldung eigenen Code auf Webservern auszuführen. Das PHP-Projekt hat sie am 21. Oktober 2026 geschlossen.

Welche PHP-Versionen sind sicher?

Sicher sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie die entsprechend korrigierten Pakete von Linux-Distributionen wie Debian und Ubuntu. Alle älteren Versionen dieser Zweige sind verwundbar.

Ist meine WordPress-Website betroffen?

Ja, wenn der Server eine verwundbare PHP-Version nutzt. Die Lücke steckt in PHP selbst, nicht in WordPress. Ein WordPress-Update hilft deshalb nicht, aktualisiert werden muss PHP auf dem Server.

Was ist mit PHP 7.4 und 8.1?

Für diese Versionen gibt es keine offiziellen Updates mehr, nur Korrekturen im Quellcode. Einige Anbieter wie Ubuntu Pro liefern eigene Updates. Die sinnvollste Lösung ist der Umstieg auf PHP 8.3 oder 8.4.

Reicht eine Web Application Firewall?

Nein. Eine Firewall wie die von Cloudflare filtert bekannte Angriffsmuster und verschafft Zeit. Sie ersetzt das Update aber nicht, das betont auch Cloudflare selbst.

Ich habe Shared Hosting. Muss ich etwas tun?

Bei Shared Hosting spielt der Anbieter die PHP-Updates ein. Prüfen Sie im Kundenmenü, welche PHP-Version Ihre Website nutzt, und stellen Sie auf eine aktuelle Version um, falls dort noch PHP 7 oder 8.1 eingestellt ist.