PHP2Shell: Kritische PHP Sicherheitslücken

Am 21. Oktober 2026 hat das PHP-Projekt ein Notfall-Sicherheitsupdate veröffentlicht, das praktisch jede WordPress-Website und jeden WooCommerce-Shop weltweit betrifft. Zwei kritische Schwachstellen direkt im PHP-Kern, bekannt als PHP2Shell (CVE-2026-109618 und CVE-2026-109619, jeweils CVSS 9.2), erlauben unauthentifizierte Codeausführung auf dem Server. Weil die Lücken vor der eigentlichen Anwendung liegen, hilft kein WordPress-Update und kein Plugin-Update allein. Was jetzt zu tun ist, erklären wir in diesem Beitrag.

Was ist PHP2Shell genau?

Die PHP-Sicherheitsabteilung hatte den Patch bereits am 20. Oktober angekündigt, geplant für den 21. Oktober, 14:00 UTC. Noch vor diesem Termin sickerten jedoch Details durch, ein Screenshot des gleichnamigen Exploit-Tools PHP2Shell kursierte im Netz, und Cloudflare beobachtete erste Angriffe bereits um 07:43 UTC, also rund sechs Stunden vor dem offiziellen Release. Angreifer hatten damit einen zeitlichen Vorsprung vor vielen Betreibern.

Das macht PHP2Shell zu einem Sonderfall gegenüber früheren Vorfällen wie Click2Shell oder den WordPress 7.1.1 und 7.1.2 Sicherheitsupdates: Dort ging es um Lücken im WordPress-Core, PHP2Shell sitzt eine Ebene darunter, im Interpreter, der WordPress überhaupt erst ausführt.

Entdeckt von einer KI, nicht von klassischen Security-Spezialisten

Die Lücken wurden mit Unterstützung von Künstlicher Intelligenz von OpenAI aufgedeckt, in Zusammenarbeit mit den Cybersecurity-Unternehmen Calif und Wiz sowie laut Cloudflare auch Quarkslab. Wiz bezeichnete die Funde als die schwerwiegendsten Sicherheitslücken, die jemals von dieser Technologie entdeckt wurden.

Der verwundbare Code existiert laut mehreren Quellen bereits seit PHP 5.4.0, veröffentlicht 2012. Mehr als ein Jahrzehnt lang blieb die Lücke im meistgenutzten Web-Programmiersystem der Welt unbemerkt, bis eine KI sie fand.

Der technische Kern: Use After Free im PHP-Kern

Beide Lücken sind sogenannte Use-After-Free-Fehler. Sie treten auf, wenn eine PHP-Anfrage durch einen schwerwiegenden Fehler, etwa Speichererschöpfung, unterbrochen wird, bevor interne Daten korrekt aufgeräumt wurden. PHP behandelt diesen Speicher danach fälschlich weiterhin als gültig. Ein Angreifer kann diesen Zustand gezielt herbeiführen und mit präparierten Daten füllen, was am Ende zur Ausführung von eigenem Code auf dem Server führt.

CVE-2026-109618

Diese Lücke tritt auf, wenn PHP während der Verarbeitung einer Anfrage, insbesondere bei mehrteiligen multipart/form-data-Anfragen wie sie Browser für Datei-Uploads nutzen, in einen Speichermangel läuft, bevor interne Daten vollständig initialisiert sind. PHP nutzt diese unvollständigen Daten danach fälschlich weiter. Zusätzlich kann diese Lücke, ähnlich wie beim bekannten Fall Heartbleed, Arbeitsspeicher-Inhalte auslesen und über ein Antwort-Cookie an den Angreifer zurückgeben, darunter potenziell Passwörter, Session-Tokens, API-Schlüssel und sogar TLS-Zertifikats-Schlüssel anderer, gleichzeitig bearbeiteter Anfragen.

CVE-2026-109619

Hier unterbricht ein schwerwiegender Fehler eine Anfrage, PHP behält jedoch interne Verweise auf den dabei freigegebenen Speicher. Bearbeitet derselbe PHP-Worker danach eine weitere Anfrage, kann dieser veraltete Verweis genutzt werden, um auf längst freigegebenen, jetzt ungültigen Speicher zuzugreifen. Auch das kann zur Codeausführung führen.

Entscheidend ist: Beide Lücken greifen, bevor WordPress, ein Plugin oder sonstiger Anwendungscode überhaupt zum Zug kommt. Deshalb kann kein WordPress-Update, kein Plugin-Update und keine Anwendungs-Firewall-Regel innerhalb der Anwendung diese Lücken schließen. Die einzige vollständige Lösung ist ein aktualisierter PHP-Interpreter selbst.

Wer ist betroffen?

Praktisch jede Website, die PHP nutzt, ist potenziell betroffen, unabhängig von installierten Plugins oder Themes. Laut Cloudflare läuft rund 70 Prozent aller Websites weltweit auf PHP. Laut ORF basieren weltweit zwischen 400 und 500 Millionen Websites allein auf WordPress, zusätzlich bauen auch Moodle, Joomla, Typo3 und Drupal auf PHP auf. Sansec dokumentierte erfolgreiche, unauthentifizierte Codeausführung unter anderem gegen Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony und WHMCS, also quer durch praktisch das gesamte PHP-Ökosystem.

Die Falle für ältere PHP-Versionen

Das PHP-Projekt pflegt offiziell nur noch die Versionszweige 8.2, 8.3, 8.4 und 8.5, diese erhielten die gepatchten Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. PHP 8.1 erreichte bereits am 31. Dezember 2025 das Ende des offiziellen Supports, PHP 8.0 sowie alle 7.x- und 5.x-Versionen sind längst nicht mehr offiziell gepflegt. Für all diese älteren Versionen gibt es kein offizielles Update von php.net. Das europäische CERT-EU erklärte laut ORF, dass potenziell alle PHP-Versionen seit PHP 5 aus dem Jahr 2004 betroffen sein könnten, da der anfällige Code bis PHP 5.4.0 zurückreicht.

Betreiber auf veralteten PHP-Versionen sind daher auf einen Backport ihres Hosting-Anbieters angewiesen, oder müssen ihre PHP-Version dringend anheben. Das deutsche Bundesamt für Sicherheit in der Informationstechnik, kurz BSI, stufte das Risiko mit der Warnstufe 3/Orange als außergewöhnlich hoch ein und empfahl, bei fehlender sofortiger Patch-Möglichkeit betroffene Webserver vorübergehend komplett vom Internet zu trennen.

Bist du dir nicht sicher, welche PHP-Version deine Website aktuell nutzt oder ob dein Hosting-Anbieter bereits reagiert hat? Dann nimm jetzt über unser Kontaktformular Kontakt mit uns auf, wir prüfen das gemeinsam mit dir.

Wie die Welt auf PHP2Shell reagiert hat

Neben zahlreichen Regierungswebsites waren auch Universitäten zeitweise nicht erreichbar. In den Niederlanden gingen mehrere bekannte Websites vorsorglich komplett offline, darunter das Nachrichtenportal Tweakers, die niederländische Zweite Kammer und die Cybersicherheitsbehörde NCSC selbst, sowie das Portal Security.NL. Das zeigt, dass selbst Sicherheitsbehörden die Lage als so ernst einschätzten, dass sie lieber komplett offline gingen, statt ein Restrisiko zu tragen.

Gleichzeitig zeigt das Beispiel des europäischen Hosting-Anbieters Hetzner, wie schnell eine professionelle Reaktion aussehen kann: Hetzner stufte den Vorfall um 13:04 MESZ als Vorfall ein und hatte bereits bis 19:50 MESZ desselben Tages gepatchte PHP-Versionen von 7.4 bis 8.5 auf allen Webhosting- und Managed-Server-Produkten ausgerollt, inklusive eigener Backports für die eigentlich nicht mehr offiziell unterstützten Versionen 7.4 bis 8.1. Auch Cloudflare reagierte früh und rollte rund neun Stunden vor der öffentlichen Bekanntgabe eigene Web-Application-Firewall-Regeln für alle Kunden aus, auch kostenlose Tarife. Diese Regeln bieten eine zusätzliche Schutzebene, ersetzen laut Cloudflare aber ausdrücklich nicht das eigentliche PHP-Update.

Sofortmaßnahmen, wenn ein Update nicht sofort möglich ist

Wenn die eigene PHP-Version nicht sofort aktualisiert werden kann, gibt es laut Sansec und PatchMon einige Übergangsmaßnahmen. Diese ersetzen ausdrücklich nicht das eigentliche PHP-Update, sie verringern nur vorübergehend das Risiko:

• Mehrteilige multipart/form-data-Anfragen am Webserver blockieren. Das betrifft zum Beispiel Datei-Uploads, Kontaktformulare mit Anhang oder Checkout-Formulare mit Datei-Upload. Diese Maßnahme kann legitime Funktionen stören, nach der Einrichtung daher unbedingt testen.
• Die Website vorübergehend komplett offline nehmen oder auf reinen Lesezugriff beschränken, also nur GET und HEAD, kein Login und kein Checkout. Der Wartungsmodus von WordPress oder dem Shop-System hilft hier nicht, weil PHP jede Anfrage bereits verarbeitet, bevor die Anwendung prüfen kann, ob der Wartungsmodus aktiv ist.
• Serverweite PHP-Einstellungen anpassen, etwa session.upload_progress.enabled deaktivieren und ein alternatives Speicherlimit-Handling nutzen. Memory_limit pauschal auf unbegrenzt zu setzen, schafft laut GitHub-Advisory selbst neue Risiken. Diese Anpassung sollte von einem erfahrenen Entwickler oder Administrator durchgeführt werden.

Das musst du als Website-Betreiber jetzt konkret tun

Für die meisten unserer Kunden ist die Lage beherrschbar, wenn jetzt gehandelt wird. Die folgenden Schritte sind der wichtigste Teil dieses Beitrags:

1. Prüfe sofort, welche PHP-Version deine Website beziehungsweise dein Server aktuell nutzt. Das findest du im Hosting-Panel, bei Managed-WordPress-Hosting erfährst du es direkt beim Provider.
2. Läuft deine Seite auf PHP 8.2, 8.3, 8.4 oder 8.5, prüfe aktiv, ob bereits auf die gepatchten Versionen 8.2.35, 8.3.36, 8.4.27 beziehungsweise 8.5.12 oder neuer aktualisiert wurde.
3. Läuft deine Seite noch auf PHP 8.1 oder älter, was häufiger vorkommt als man denkt, kontaktiere umgehend deinen Hosting-Anbieter und frage nach einem Sicherheits-Backport, wie es Hetzner vorgemacht hat. Alternativ hebe die PHP-Version so schnell wie möglich auf einen aktuell unterstützten Zweig an. Das kann bei älteren WordPress-Installationen Kompatibilitätsprobleme mit Theme und Plugins auslösen, eine Anhebung sollte daher idealerweise mit fachlicher Unterstützung erfolgen.
4. Starte nach jedem Update unbedingt PHP-FPM beziehungsweise den Apache-Dienst neu. Ein aktualisiertes Paket auf der Festplatte allein bringt nichts, solange laufende PHP-Worker-Prozesse weiterhin den alten, ungepatchten Code im Speicher halten.
5. Prüfe bei Unsicherheit, ob deine Website bereits angegriffen wurde: Achte auf ungewohnte neue Administrator-Konten, unbekannte Dateien oder Plugins und auffällige Logeinträge.

Wer bei einem seriösen Hosting-Anbieter ist und seine PHP-Version aktuell hält, ist in der Regel zeitnah geschützt. Wer dagegen auf veralteten PHP-Versionen unterwegs ist, trägt jetzt ein ernstes, konkretes Risiko und sollte das nicht aufschieben. Melde dich jetzt bei uns über unsere Anfrage-Seite, wenn du dir bei der eigenen PHP-Version unsicher bist oder Unterstützung bei der Anhebung brauchst.

8 FAQs zu PHP2Shell (CVE-2026-109618, CVE-2026-109619)