Am Morgen des 23. Oktober fand sich im Nachrichtenarchiv von PHP ein unscheinbarer technischer Hinweis: Betreiber sollten eine Funktion namens session.upload_progress vorläufig abschalten. Erst mit dem nächsten regulären Update werde ein weiterer, allerdings nur unter ungewöhnlichen Bedingungen nutzbarer Angriffsweg vollständig geschlossen.
Zwei Tage zuvor hatte das PHP-Projekt bereits Notfallupdates gegen zwei kritische Schwachstellen veröffentlicht. Nun folgte ein Nachtrag. Kein Alarmgong, eher das metallische Klicken einer Tür, bei der noch einmal geprüft wird, ob sie wirklich verriegelt ist. Der Fall, den Sicherheitsforscher PHP2Shell nennen, war noch nicht ganz vorbei. Recherchequelle: php.net
Das unsichtbare Fundament von 70 Prozent des Webs
PHP gehört zu den stillen Arbeitern des Internets. Die Programmiersprache läuft hinter Blogs, Onlineshops, Nachrichtenportalen und Verwaltungsseiten. WordPress, Drupal, Joomla und die Wikipedia-Software MediaWiki bauen auf ihr auf. Nach Angaben des Sicherheitsunternehmens Wiz wird PHP auf rund 70 Prozent aller Websites eingesetzt.
Das bedeutet nicht, dass 70 Prozent des Netzes gleichermaßen offenstanden. Betriebssystem, PHP-Version, Serverkonfiguration und bereits installierte Schutzmaßnahmen entscheiden darüber, ob ein Angriff gelingen kann. Doch wenn eine Schwachstelle im Kern einer derart verbreiteten Technik steckt, genügt schon ein kleiner Anteil verwundbarer Systeme, um ein gewaltiges Zielgebiet zu schaffen.
Zwei Speicherfehler mit enormem Schadenspotenzial
Bei PHP2Shell geht es um zwei Speicherfehler mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Beide erhielten einen Schweregrad von 9,2 auf einer Skala mit dem Höchstwert 10. Im schlimmsten Fall kann ein Angreifer aus der Ferne eigenen Code auf einem Server ausführen, ohne sich zuvor anmelden zu müssen. Er könnte Daten lesen, verändern oder den übernommenen Rechner als Ausgangspunkt für weitere Attacken verwenden. Die Schwachstellen liegen nicht in einem schlecht programmierten WordPress-Plugin oder einer einzelnen Website. Sie befinden sich tiefer: in PHP selbst.
Der erste Fehler entsteht, vereinfacht gesagt, wenn PHP während einer Anfrage der Speicher ausgeht. Teile der internen Daten sind dann noch nicht vollständig vorbereitet, werden beim Aufräumen aber möglicherweise behandelt, als wären sie gültig. Beim zweiten Problem bleiben Verweise auf bereits freigegebenen Speicher zurück. Bearbeitet derselbe Prozess später eine weitere Anfrage, kann er auf diesen alten Zustand zugreifen. Für einen Angreifer eröffnet sich damit die Möglichkeit, Daten in einem Bereich abzulegen, den das Programm irrtümlich noch für vertrauenswürdig hält.
Solche Beschreibungen klingen abstrakt. Genau darin lag lange ein Teil des Schutzes. Zwischen der Erkenntnis, dass ein Programm theoretisch falsch mit seinem Speicher umgeht, und einem zuverlässig funktionierenden Angriff liegen oft Wochen oder Monate mühsamer Arbeit. Speicherbelegung muss rekonstruiert, Programmverhalten auf unterschiedlichen Systemen beobachtet und eine Kette vieler kleiner Schritte entwickelt werden. Komplexität bot keinen verlässlichen Schutz, wirkte aber wie dichtes Unterholz.
Warum die bekannte Gefahr liegen blieb
Die ersten Spuren eines der Fehler waren bereits 2024 bei einem externen Sicherheitsaudit aufgetaucht. Damals ließ sich zwar ein möglicher Angriff vermuten, ein konkreter Weg zur vollständigen Übernahme eines Servers wurde jedoch nicht gefunden. Mehrere Reparaturansätze hatten erhebliche Nachteile: Manche hätten die Kompatibilität beeinträchtigt, andere neue Möglichkeiten für Ausfälle geschaffen oder Änderungen an zahlreichen Erweiterungen verlangt.
Hinzu kam ein menschliches Problem. Nur wenige Entwickler kennen den Kern von PHP tief genug, um solche Eingriffe sicher vorzunehmen. Die Arbeit blieb liegen, wurde wieder aufgenommen und stockte erneut. Die PHP Foundation bezeichnete die Verzögerung später ungewöhnlich offen als strukturelles Versagen der Entscheidungsprozesse und der verfügbaren Ressourcen. Recherchequelle: thephp.foundation
DQo8ZGl2IGNsYXNzPSJleHRob3JpYS1hbWF6b24tYWQiIGRhdGEtZXh0aG9yaWEtYWQtc2xvdD0iMDEiIGRhdGEtZXh0aG9yaWEtYWQtcHJvdmlkZXI9ImFtYXpvbiI+PGRpdiBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19tZXRhIj48c3BhbiBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19iYWRnZSI+V2VyYnVuZzwvc3Bhbj48c3BhbiBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19wcm92aWRlciI+QW1hem9uPC9zcGFuPjwvZGl2PjxzdHJvbmcgY2xhc3M9ImV4dGhvcmlhLWFtYXpvbi1hZF9fdGl0bGUiPlBIUC1TaWNoZXJoZWl0OiBQSFAvTXlTUUwtV2ViYW53ZW5kdW5nZW4gc2ljaGVyIHByb2dyYW1taWVyZW48L3N0cm9uZz48YSBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19jdGEiIGhyZWY9Imh0dHBzOi8vbGluay5hbWF6b24vQjBiNmRQZTVwIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJzcG9uc29yZWQgbm9mb2xsb3cgbm9vcGVuZXIgbm9yZWZlcnJlciIgZGF0YS1leHRob3JpYS1saW5rLW1hbmFnZXI9IjEiIGRhdGEtZXh0aG9yaWEtbGluay10eXBlPSJleHRlcm5hbCIgZGF0YS1leHRob3JpYS1hZC1saW5rPSJhbWF6b24iPkJlaSBBbWF6b24gYW5zZWhlbiA8c3Bhbj4oYmV6YWhsdGVyIExpbmspPC9zcGFuPjwvYT48c21hbGwgY2xhc3M9ImV4dGhvcmlhLWFtYXpvbi1hZF9fZGlzY2xvc3VyZSI+w5xiZXIgdW5zZXJlIEFtYXpvbi1QYXJ0bmVybGlua3MgZXJoYWx0ZW4gd2lyIGJlaSBxdWFsaWZpemllcnRlbiBWZXJrw6R1ZmVuIGVpbmUgUHJvdmlzaW9uLjwvc21hbGw+PC9kaXY+DQo=Als KI aus Theorie einen Angriff machte
Dann kamen die KI-Systeme.
Am 30. Juli 2026 begann das Sicherheitsunternehmen Calif im Rahmen von OpenAIs Programm „Patch the Planet“ mit einer Prüfung von PHP. Am 11. August meldete der Forscher Ryan A. einen Angriff, der denselben grundlegenden Speicherfehler ausnutzte, dessen Spuren bereits zwei Jahre zuvor aufgefallen waren. OpenAI meldete unabhängig davon dieselbe Ursache und lieferte später weitere Angriffsmöglichkeiten. Auch Wiz untersuchte PHP mit mehreren KI-Modellen und meldete seine Ergebnisse am 24. August.
Dabei wäre es falsch, die Geschichte als autonomen Triumph einer Maschine zu erzählen. Die Modelle öffneten nicht selbstständig einen Quelltext, fanden eine Lücke und schickten anschließend höflich einen Fehlerbericht. Für die Auswahl der Ziele, die Aufgaben, den Aufbau der Testumgebungen und die Kontrolle der Ergebnisse waren Sicherheitsforscher verantwortlich. Menschen bewerteten die Gefahr, entwickelten Patches und entschieden, welche Änderungen verantwortbar waren.
Trotzdem verschob die KI das Verhältnis von Aufwand und Ergebnis. Wiz setzte nach eigenen Angaben unter anderem Gemini 4 Argon und GPT-5.6 Sol ein. Ein Forscher habe damit in einer Woche Aufgaben bewältigen können, für die früher womöglich ein hoch spezialisiertes Team mehrere Monate benötigt hätte. Funktionierende Angriffe auf Drupal und WordPress entstanden binnen Stunden. Die lange für kaum ausnutzbar gehaltene Schwachstelle war plötzlich praktisch nutzbar. Recherchequelle: wiz.io
Hier liegt die eigentliche Bedeutung von PHP2Shell. KI entdeckt nicht nur unbekannte Fehler. Sie kann bekannte, bislang als zu kompliziert geltende Schwächen neu bewerten. Ein alter Fehler wird gefährlicher, wenn sich der Weg zu seiner Ausnutzung drastisch verkürzt. Was gestern nur theoretisch möglich war, kann heute zum Arbeitsauftrag für ein Modell werden.
Ein Vorsprung von wenigen Wochen
Für die Verteidiger war die Entdeckung zunächst ein Vorsprung. OpenAI spricht von einem Zeitfenster, in dem leistungsfähige Modelle Schwachstellen finden, bevor vergleichbare Fähigkeiten in großem Umfang für Angriffe eingesetzt werden. Zwei Monate lang arbeiteten PHP-Entwickler, Forscher, Hostinganbieter und Sicherheitsunternehmen an Korrekturen, Tests und Schutzregeln. OpenAI koordinierte nach eigener Darstellung Teile dieser Zusammenarbeit und stellte zusätzlich ein Werkzeug bereit, mit dem Betreiber ihre PHP-Version überprüfen können. Recherchequelle: openai.com
Doch ein solcher Vorsprung ist zerbrechlich. Die Veröffentlichung war ursprünglich für den 22. Oktober geplant. Am 20. Oktober tauchten die Kennungen der Schwachstellen vorzeitig in Foren und sozialen Netzwerken auf, zusammen mit falschen Angaben zum Zeitpunkt der Veröffentlichung und zum Schweregrad. Technische Einzelheiten waren nach Darstellung der PHP Foundation zunächst nicht darunter. Dennoch wurde der Zeitplan vorgezogen. Die Patches erschienen am 21. Oktober.
Cloudflare hatte zu diesem Zeitpunkt bereits Schutzregeln für seine Web Application Firewall vorbereitet und aktivierte sie rund neun Stunden vor der öffentlichen Bekanntgabe. Das Unternehmen beobachtete anschließend, wie Angreifer ihre Anfragen veränderten, offenbar um die neuen Filter zu umgehen. Bemerkenswert ist dabei nicht nur die Geschwindigkeit. Schutz und Angriff begannen sich während der Veröffentlichung gegenseitig anzupassen. Recherchequelle: blog.cloudflare.com
An den Zahlen von Imperva lässt sich diese Beschleunigung ablesen. In den ersten 24 Stunden registrierte das Sicherheitsunternehmen 482.342 verdächtige Anfragen in 122.311 Angriffssitzungen. Sie richteten sich gegen 21.998 Websites in 103 Ländern. Fast zwei Drittel der erfassten Ziele lagen in den USA; Deutschland gehörte ebenfalls zu den stärker betroffenen Ländern.
Diese Werte belegen keine 21.998 erfolgreichen Einbrüche. Imperva spricht überwiegend von breit gestreuten, automatisierten Prüfversuchen. Die Angreifer warfen gewissermaßen an Tausenden Türen die Klinke herunter, ohne zu wissen, welche tatsächlich unverschlossen war. Genau darin zeigt sich jedoch die neue Größenordnung: Automatisierung macht es billig, sehr viele Systeme gleichzeitig auszuprobieren. Recherchequelle: imperva.com
Der wahre Engpass ist die Wartung
Für einen Angreifer genügt ein funktionierender Weg. Die Verteidiger müssen dagegen den Fehler verstehen, eine belastbare Lösung entwickeln, ältere Versionen berücksichtigen, Patches an Linux-Distributionen und Hoster verteilen, Schutzregeln anpassen und schließlich jeden einzelnen Betreiber erreichen. Updates müssen getestet werden, weil auch ein gut gemeinter Patch Anwendungen lahmlegen kann. Das Internet ist kein zentral verwalteter Rechner. Es ist ein Flickenteppich aus modernen Cloudsystemen, sorgfältig gepflegten Servern und Maschinen, die seit Jahren niemand mehr genauer angesehen hat.
Gleichzeitig wächst die Zahl der Hinweise. Seit Anfang Juli veröffentlichte das PHP-Team 15 Sicherheitskennungen und untersuchte mehr als 100 weitere Meldungen, die sich als nicht reproduzierbar, doppelt oder falsch erwiesen. KI hilft beim Sortieren und Überprüfen. Über jeden Patch entscheidet dennoch ein Mensch.
PHP2Shell erzählt deshalb weniger von einer Maschine, die das Internet rettet oder bedroht. Die tiefere Geschichte handelt von einem Ungleichgewicht. Die Leistungsfähigkeit von Werkzeugen zum Aufspüren und Ausarbeiten von Angriffen wächst schneller als die der Strukturen zur Pflege alter Software. Quellcode lässt sich vervielfältigen. Erfahrene Entwickler, die seine verborgensten Winkel kennen, nicht.
Der entscheidende Engpass könnte deshalb künftig nicht Rechenleistung sein, sondern Wartung: Zeit, Aufmerksamkeit und Menschen, die entscheiden können, welche Reparatur das Netz aushält. KI macht Probleme in bislang schwer zugänglichen Bereichen des Codes immer schneller sichtbar. Beheben muss sie trotzdem jemand.
Weiterführende Informationen
Quellenhinweis: Einzelne Fakten, Einschätzungen und Prognosen dieses Beitrags stützen sich auf Veröffentlichungen der nachfolgend genannten Unternehmen und Institutionen. Die Links dienen zugleich der weiterführenden Information.
Doğa Network – PHP-Sicherheitslücken CVE-2026-109618 / CVE-2026-109619 (PHP2Shell): Kritische RCE wird aktiv ausgenutzt
Die technische Übersicht erklärt die Speicherfehler, betroffenen PHP-Konfigurationen und die vorläufige Deaktivierung von session.upload_progress.
https://www.doga.network/de/sicherheitshinweise/php-sicherheitsluecke-cve-2026-109618-cve-2026-109619-php2shell
Computer4You – PHP2Shell, Teil 2: Wie Calif, OpenAI und Wiz die gefährlichen PHP-Lücken entdeckten
Der Beitrag zeichnet nach, wie KI-Modelle die Fehlersuche und Entwicklung praktisch nutzbarer Angriffe auf Drupal, WordPress und weitere PHP-Systeme beschleunigten.
https://www.computer4you.de/php2shell-entdeckung-august-2026-calif-wiz-openai/
Threat-Informed – PHP2Shell: Was die kritischen PHP-Lücken für Ihr Unternehmen bedeuten
Das laufend aktualisierte Advisory bündelt Patchstand, WAF-Schutz, Reaktionen der Hoster und Erkenntnisse zur frühen automatisierten Angriffswelle.
https://threat-informed.de/advisories/php2shell-2026
