PHP2Shell ist der Name für zwei kritische Lücken in PHP mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Beide sind nach CVSS 4.0 mit 9,2 von 10 bewertet. Angreifer können darüber ohne Anmeldung Code auf einem Webserver ausführen, auf dem PHP läuft. Das PHP-Projekt hat sie am 21. Oktober 2026 mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen.

Bin ich betroffen, wenn ich WordPress nutze?

Wenn Ihre Website mit PHP läuft, also auch mit WordPress, Shopware, TYPO3 oder Joomla, ist die PHP-Version auf dem Server betroffen, nicht WordPress selbst. Ein Update von WordPress, einem Theme oder einem Plugin schließt die Lücke deshalb nicht. Entscheidend ist, dass auf dem Server eine korrigierte PHP-Version läuft.

Muss ich bei Webhosting selbst etwas tun?

Beim klassischen Webhosting spielt der Hoster das PHP-Update ein. Sie sollten sich aber bestätigen lassen, dass Ihre Website auf einer korrigierten Version läuft, und prüfen, welche PHP-Version im Kundenmenü eingestellt ist. Für PHP 8.1 und älter liefert das PHP-Projekt keine Updates mehr. Dort hängt es davon ab, ob der Hoster selbst nachbessert.

Reicht es, eine Schutzregel zu setzen statt zu aktualisieren?

Nein. Das PHP-Projekt nennt einige Einstellungen, die bestimmte Angriffswege erschweren, schreibt aber ausdrücklich, dass sie eine Installation nicht sicher machen. Die einzige vollständige Lösung ist das Update.

Was hat KI mit diesen Lücken zu tun?

Laut Fortune haben mehrere Forschungsteams die Lücken im August gefunden, alle mit KI-Modellen zur Fehlersuche. OpenAIs GPT-5.6 Sol soll dabei eine Schlüsselrolle gespielt haben. Das BSI nennt Wiz, Calif und OpenAI als an der Entdeckung beteiligt. Angegriffen wurden die Lücken nach Angaben von Amazon Web Services schon ab dem 17. Oktober, vier Tage vor dem Patch.

PHP2Shell: Bin ich betroffen? Was Firmen jetzt prüfen sollten

Am Mittwoch, 21. Oktober, um 16 Uhr deutscher Zeit hat das PHP-Projekt vier neue Versionen veröffentlicht: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie schließen zwei Lücken, über die ein Angreifer ohne Anmeldung eigenen Code auf einem Webserver ausführen kann. Beide sind mit 9,2 von 10 bewertet. Das PHP-Projekt schreibt dazu ungewöhnlich deutlich: Es gibt keinen vollständigen Schutz außer dem Update.

PHP steckt in einem großen Teil des Webs, Fortune schätzt rund 70 Prozent. Darunter sind fast alle Websites mit WordPress, viele Shops und unzählige Kundenportale, Formulare und interne Werkzeuge. Für die meisten Betriebe ist die Frage deshalb nicht, ob sie PHP nutzen, sondern wo und wer es aktualisiert.

Was passiert ist

Am 20. Oktober kündigte das PHP-Projekt für den Folgetag ein kritisches Sicherheitsupdate an. Am 21. Oktober um 14 Uhr UTC erschienen die korrigierten Versionen. Linux-Distributionen und Anbieter mit Langzeitpflege hatten die Korrekturen vorab bekommen.

Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. In Berichten heißen sie PHP2Shell, in Anlehnung an Log4Shell. Die erste entsteht, wenn PHP mitten in einer Anfrage der Speicher ausgeht und interne Daten nur halb angelegt sind. Die zweite entsteht, wenn interne Daten einer Anfrage den Speicher überleben, zu dem sie gehören, und eine spätere Anfrage desselben Prozesses sie weiterverwendet. Beides klingt nach Feinheiten, reicht aber für die Übernahme des Servers.

Betroffen ist laut PHP-Projekt jede PHP-Installation, die Webanfragen beantwortet. Genannt werden PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das PHP-Projekt das Risiko bei mod_php ein.

Das BSI hat am 22. Oktober seine Warnung in Version 1.2 aktualisiert und rät, den Patch unverzüglich einzuspielen. Eine erfolgreiche Ausnutzung in der Breite war dem BSI zu diesem Zeitpunkt noch nicht bekannt. Fortune berichtet dagegen unter Berufung auf Amazon Web Services, dass Angreifer die Lücken schon ab dem 17. Oktober ausgenutzt haben, also vier Tage vor dem Patch, und dass es seit der Veröffentlichung Millionen Versuche gab. Einige Behörden und Unternehmen haben ihre Dienste vorsorglich vom Netz genommen.

Wer was tun muss

Der wichtigste Satz vorweg: Die Lücke sitzt in PHP auf dem Server, nicht in WordPress, nicht im Shop-System und nicht in einem Plugin. Ein Update im WordPress-Dashboard schließt sie nicht. Was zu tun ist, hängt davon ab, wo Ihre Website läuft.

Klassisches Webhosting. Hier aktualisiert der Hoster PHP. Lassen Sie sich trotzdem bestätigen, dass Ihre Website auf einer korrigierten Version läuft, und schauen Sie im Kundenmenü nach, welche PHP-Version eingestellt ist. Steht dort 8.1 oder älter, ist das jetzt ein echtes Problem: Für diese Versionen liefert das PHP-Projekt keine Updates mehr. Es gibt zwar minimale Nachbesserungen für 7.4, 8.0 und 8.1 im Quellcode, ob Ihr Hoster sie einspielt, müssen Sie aber erfragen. Der sicherere Weg ist der Wechsel auf 8.3 oder 8.4, nachdem Sie geprüft haben, dass Ihre Website damit läuft.

Eigener Server oder gemieteter V-Server. Spielen Sie die PHP-Pakete Ihrer Distribution ein und starten Sie danach PHP-FPM beziehungsweise den Webserver neu. Ohne Neustart läuft der alte, verwundbare Code weiter. Achtung bei der Versionsnummer: Debian, Ubuntu und andere übernehmen Korrekturen oft in ihre eigene Paketversion, ohne die PHP-Nummer zu ändern. Ob ein Paket die Lücken schließt, steht in der Sicherheitsmeldung der Distribution, nicht in der Ausgabe von php -v.

Docker und Container. Ein Container bringt sein eigenes PHP mit. Ein Update auf dem Server ändert daran nichts. Die Images müssen mit einer korrigierten PHP-Version neu gebaut und die Container neu gestartet werden. Das gilt auch für fertige Images von Herstellern, etwa für Webshops, Ticketsysteme oder Intranets.

Website über eine Agentur oder einen Dienstleister. Fragen Sie konkret nach, auf welcher PHP-Version Ihre Website seit wann läuft. Die Antwort „WordPress ist aktuell“ beantwortet die Frage nicht.

Nach dem Update. Weil Angriffe schon vor dem 21. Oktober begannen, lohnt ein Blick in die Zugriffs- und Fehlerprotokolle der letzten Tage. Auffällig wären neue Dateien im Webverzeichnis, unbekannte Admin-Konten oder Abstürze von PHP-Prozessen ab dem 17. Oktober. Wer etwas findet, sollte den Server nicht nur patchen, sondern als möglicherweise übernommen behandeln.

Das PHP-Projekt nennt einige Einstellungen, die bestimmte Angriffswege erschweren, darunter ein kleineres post_max_size und das Abschalten von session.upload_progress.enabled. Es schreibt aber selbst, dass diese Maßnahmen eine Installation nicht sicher machen. Sie sind höchstens eine Brücke für die Stunden bis zum Update.

Wie wir es bei uns geprüft haben

Wir haben am 22. Oktober beide Server aktualisiert, auf denen unsere Dienste laufen. Dabei kam die Frage auf, wo bei uns überhaupt PHP läuft. Die Antwort war ernüchternd einfach: auf den Servern selbst nirgends, es ist kein PHP-Paket installiert. Damit war die Prüfung aber nicht fertig, denn die meisten unserer Dienste laufen in Containern.

Heute haben wir deshalb in jedem laufenden Container nachgesehen, ob dort ein PHP steckt: 35 Container auf zwei Servern, in keinem ein PHP. Unsere Website ist statisch gebaut und enthält keine einzige PHP-Datei. Für uns ist PHP2Shell damit kein Thema. Die Prüfung hat trotzdem ihren Wert, denn genau in den Containern hätten wir ohne Nachsehen nicht gewusst, woran wir sind. Container, die keine eigene Kommandozeile mitbringen, lassen sich so übrigens nicht prüfen. Bei ihnen hilft nur ein Blick in das Image oder die Angaben des Herstellers.

Für Ihren Betrieb heißt das: Die schnellste Antwort auf „Sind wir betroffen?“ ist eine Liste, wo überall Webanwendungen laufen und wer sie betreut. Website, Shop, Kundenportal, Bewerbungsformular, Zeiterfassung, Ticketsystem. Erst mit dieser Liste kann man gezielt nachfragen.

Warum ausgerechnet KI die Lücken gefunden hat

Laut Fortune haben mehrere Forschungsteams die beiden Lücken schon im August gefunden, unabhängig voneinander und alle mit Hilfe von KI-Modellen für die Fehlersuche. OpenAIs GPT-5.6 Sol soll dabei eine Schlüsselrolle gespielt haben. Das BSI nennt die Sicherheitsfirmen Wiz und Calif sowie OpenAI als an der Entdeckung beteiligt. Eine Gruppe aus Unternehmen und dem PHP-Projekt hat die Korrektur danach im Stillen vorbereitet und am 21. Oktober gemeinsam veröffentlicht.

Das ist die gute Nachricht: Ein Fehler, der jahrelang unentdeckt im Speichermanagement von PHP lag, wurde von Verteidigern gefunden, bevor er breit ausgenutzt wurde. Die schlechte Nachricht steckt im Datum 17. Oktober. Zwischen der Entdeckung durch die einen und dem Angriff durch die anderen lag diesmal kaum Abstand, und die Angriffe begannen vor dem Patch. Wenn Werkzeuge, die solche Fehler finden, breiter verfügbar werden, wird die Zeit zwischen Veröffentlichung und Angriff eher kürzer als länger.

Für Betriebe folgt daraus kein Grund zur Panik, aber eine klare Regel: Sicherheitsupdates für alles, was aus dem Internet erreichbar ist, gehören in Stunden eingespielt, nicht in Wochen. Wer dafür auf einen Dienstleister angewiesen ist, sollte die Reaktionszeit vertraglich festhalten.

Was Sie jetzt tun können

Wenn Sie nur eines tun: Fragen Sie heute bei Hoster, Agentur oder IT-Dienstleister nach, auf welcher PHP-Version Ihre Website und Ihre anderen Webanwendungen laufen und ob die Korrekturen vom 21. Oktober drin sind. Läuft irgendwo noch PHP 8.1 oder älter, planen Sie den Wechsel jetzt.

Wie ein Sicherheitstest abläuft, der solche Lücken findet, bevor es Angreifer tun, beschreiben wir in KI-Pentest: Was ein Sicherheitstest prüft und auf unserer Seite zu AI Security und Pentesting. Für Entsorgungsbetriebe, die unter NIS2 fallen, gehört eine solche Lücke in die eigene Risikobewertung, dazu mehr bei NIS2 für Entsorger.

Wenn Sie wissen wollen, wo in Ihrem Betrieb überall Webanwendungen laufen und wie verwundbar sie sind, sprechen Sie uns an.

Quellen

Alle abgerufen am 23.10.2026.

PHP: Security advisory: Critical remote code execution vulnerabilities, update now, 21.10.2026, dazu die Release-Meldungen zu 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie die Vorankündigung vom 20.10.2026
PHP auf GitHub: Advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) und GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
BSI: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit, Version 1.2 vom 22.10.2026
Fortune: The PHP bug marks a dangerous new era for the internet, 22.10.2026 (Entdeckung im August mit KI-Modellen, Angriffe ab 17.10. laut AWS, Anteil von PHP am Web)
Eigene Prüfung vom 22. und 23.10.2026 (PHP-Pakete auf zwei Servern, PHP in 35 laufenden Containern, Website-Build)

Stand: 23. Oktober 2026. Zur Ausnutzung gibt es noch wenig gesicherte Angaben. Wenn das BSI oder das PHP-Projekt neue Hinweise veröffentlichen, ergänzen wir den Beitrag.

PHP2Shell: Was Betriebe mit Website, Shop oder eigenem Server jetzt prüfen sollten