Am 21. Oktober 2026 hat das PHP-Projekt zwei Speicherfehler im Kern der Sprache geschlossen. Beide sind mit CVSS 9,2 bewertet, beide erlauben Code-Ausführung ohne Anmeldung, und beide stecken nicht in WordPress, Drupal oder einem Plugin, sondern in der Laufzeit darunter. Bereinigt sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Gefunden wurden die Fehler mit KI-Unterstützung – und dieser Teil der Geschichte sagt mehr über die nächsten Jahre der Fehlersuche als über die letzten Jahre von PHP.

Wir arbeiten seit Jahren an der Frage, wo KI im Betrieb läuft und wer die Sicherheit dafür verantwortet. Dieser Fall liefert beides in einem Vorgang: eine Lücke, die über ein Jahrzehnt im Code lag und jetzt innerhalb von Tagen ausgenutzt wurde, und ein Fund, an dem Menschen und Modelle arbeitsteilig beteiligt waren. Was davon belegt ist, was nicht, und was Betreiber jetzt tun sollten, steht in diesem Text. Alle Adressen in den Quellen wurden am 22.10.2026 abgerufen.

Zwei Speicherfehler, ein Auslöser

PHP räumt normalerweise auf, wenn eine Anfrage erledigt ist. Geht mitten in der Arbeit der Speicher aus oder bricht ein fataler Fehler dazwischen, bleibt ein halbfertiger Zustand zurück. Genau dort setzen beide Lücken an.

Die erste, CVE-2026-109618, entsteht, wenn die Behandlung von Out-of-Memory PHP unterbricht, während die internen Anfragedaten erst teilweise eingerichtet sind. Die zweite, CVE-2026-109619, führt über veralteten globalen Zustand auf Speicher, der bereits freigegeben wurde.[2][9] Beide zusammen erlauben einem Angreifer ohne jede Anmeldung, Code auf dem Webserver auszuführen oder fremden Speicher mitzulesen – laut Wiz und Zscaler Daten, „die Passwörter, Authentifizierungstoken, API-Schlüssel und Zertifikate anderer Anfragen oder des Servers selbst enthalten können“.[2][4][8]

Das PHP-Team bewertet beide mit 9,2 von 10 nach CVSS v4.0.[2][3] Eine Präzisierung, die in vielen Meldungen fehlt: Die am 20. Oktober kursierenden CVE-IDs trugen einen Wert von 10,0, der falsch war – die PHP Foundation nennt die 9,2 ausdrücklich als den tatsächlichen Wert.[3] Solche Details entscheiden, wie hektisch ein Betrieb reagiert.

Am gefährlichsten sind Installationen mit Apache und mod_php. Im Original: „We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.“[2] Der Angriff braucht also nicht einmal eine verwundbare Anwendung – er kommt vorher.

Wer betroffen ist – und wo die Grenze verläuft

Betroffen ist jede PHP-Installation, die Web-Anfragen bedient. Wiz formuliert es so: „Even a simple ‚Hello World‘ application running on an affected PHP version can be vulnerable.“[4] Die Reichweite reicht nach Angaben von Wiz bis PHP 5.4 zurück.[4] CERT-EU beschreibt die betroffenen Fassungen der Zweige 8.2 bis 8.5 sowie die abgekündigten Zweige bis einschließlich 8.1.[4][14] Die verbreitetsten Betriebsarten – PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed – sind alle im Spiel.[2][7]

Bei den Versionen wird es für viele Betriebe unangenehm. Für alles unter 7.4 gibt es keinen Fix. Für die abgekündigten Zweige 7.4, 8.0 und 8.1 hat das PHP-Team wegen der Schwere Source-Backports veröffentlicht, und 8.2 läuft am 31.12.2026 aus.[2][15] Wer sein Hosting vor Jahren eingerichtet und seither nicht angefasst hat, sitzt mit hoher Wahrscheinlichkeit auf einem dieser Zweige.

Das PHP-Team lässt an der eigenen Einschätzung keinen Zweifel: „There are no complete mitigations, updating is the only safe choice.“[2] Dem ist wenig hinzuzufügen – außer der praktischen Konsequenz, dass eine Firewall vor dem Server die Lücke nicht schließt, sondern nur den Weg dorthin erschwert.

Was die KI dabei getan hat – und was nicht

Die erste Lücke fand das Sicherheitsunternehmen Calif im Rahmen eines Audits der PHP-Quelltexte, das OpenAI über sein Programm „Patch the Planet“ finanzierte. Als Werkzeug nennt OpenAI ausdrücklich GPT-5.6 Sol.[5][15] Wiz fand beide Fehler unabhängig und Wochen später, mit der eigenen Plattform Atlas sowie Gemini 4 Argon und GPT-5.6 Sol.[4][5] Das PHP-Projekt nennt in seinem Advisory Calif, Wiz und OpenAI gemeinsam; Cloudflare nennt Quarkslab als vierten Namen.[2][6][14]

Interessanter als die Werkzeugliste ist, was Calif selbst dazu sagt. Das Unternehmen betont, es habe ausschließlich allgemein verfügbare Modelle ohne Spezialwerkzeug eingesetzt, und die Kenntnis der PHP-Geschichte sei wichtiger gewesen als die Wahl des Modells. Im Original: „No model is simply capable of unearthing ‚all bugs‘ with simple prompts. At least not for now.“[15]

Und Wiz beschreibt, was sich tatsächlich verändert hat: Der Exploit galt jahrelang als theoretisch möglich, aber praktisch außerhalb der Reichweite – „at the edge of what human researchers could practically achieve“.[4] Die Lücke selbst ist alt; neu ist, dass sie sich mit vertretbarem Aufwand nutzen lässt. Der Unterschied zwischen „jemand könnte das irgendwann bauen“ und „das läuft heute“ ist die eigentliche Verschiebung, und sie ist eine Rechenfrage: Frontier-Modelle senken die Kosten, einen bekannten Fehler bis zum funktionierenden Exploit zu Ende zu denken.

OpenAI rahmt den Fund als „Defender’s Window“ – die Zeit, in der Verteidiger von einem Fund profitieren, bevor Angreifer ihn nutzen: „To our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender’s Window for maintainers and security providers.“[5] Zwei Anmerkungen dazu. Erstens ist der Begriff Marketing-Vokabular von OpenAI und älter als dieser Fall – er taucht bereits in einem Beitrag vom 03.09.2026 auf.[12] Zweitens ist die Aussage eine Selbstauskunft mit dem Zusatz „to our knowledge“. Dazu unten mehr, im Abschnitt über das, was nicht belegt ist.

Auch die Zahl, die in vielen Meldungen als Neuigkeit auftaucht, gehört nicht zu diesem Vorgang: OpenAIs Zusage von einer Milliarde Dollar vergünstigtem Zugang zum Programm Daybreak stammt vom 03.09.2026 und richtet sich an Organisationen mit knappen Sicherheitsressourcen. Sie ist eine Reaktion auf die allgemeine Lage, nicht auf PHP2Shell.[12]

Was am Netzrand passiert ist

Cloudflare hat seine Schutzregeln am 21.10.2026 um 03:02 UTC für alle Pläne aktiviert, auch für kostenlose Konten. Das Unternehmen schreibt, das sei „about 9 hours ahead of public disclosure“ gewesen.[6] Nachgerechnet wird es interessanter: CERT-EU datiert die Veröffentlichung der Fixes auf 13:30 UTC, das sind zehn Stunden und 28 Minuten nach 03:02. Cloudflare nennt den Bezugspunkt für seine neun Stunden nicht – vermutlich eine Forscherveröffentlichung, nicht der PHP-Release.[14] Wer die Zahl übernimmt, sollte sie als Cloudflare-Angabe kennzeichnen.

Der Zeitplan geriet ohnehin durcheinander. Am 20.10. kursierten die CVE-IDs mit falscher Release-Zeit und falschem Score, ohne technische Details. PHP zog daraufhin die Vorankündigung vor und legte den Release vom 22. auf den 21.10.[3] Am 21.10. um 07:41 UTC brach Chainguard die Embargo-Vereinbarung und veröffentlichte fertige Images mit dem Fix.[3] CERT-EU und das britische NCSC rieten Organisationen, Systeme offline zu nehmen, wo ein sofortiges Update nicht möglich war; die NSA veröffentlichte eine eigene Warnung. Der Bookmarking-Dienst Pinboard, das GrapheneOS-Forum und das Streaming-Werkzeug OBS nahmen Teile ihrer Seiten vom Netz, Laravel stoppte Cloud-Deployments, bis gepatchte Images bereitstanden.[15]

Cloudflare berichtet außerdem, man habe Angriffsverkehr auf Kunden gesehen und mitbekommen, wie Angreifer ihre Nutzlast an die neuen Regeln anpassten.[6] Wer sich allein auf die Firewall verlässt, verteidigt damit gegen einen Gegner, der genau diese Firewall gerade austestet. Cloudflare sagt das selbst – nicht der Schutz sei der Fix, sondern die Laufzeit: „These flaws are in the PHP runtime, so updating website code or a plugin(s) alone does not fix these vulnerabilities. Administrators need to update the PHP software running their applications.“[6]

Der eigentliche Befund: zehn Wochen Koordination

Am 11.08.2026 meldete Calif die Lücke an das PHP-Team, OpenAI meldete unabhängig am selben Tag dieselbe Grundursache. Von da an hatte der Fix oberste Priorität.[3] Am 24.08. folgte die Meldung von Wiz, am 21.09. bestätigte PHP die Reports und begann den koordinierten Fix.[4] Am 21.10. standen die bereinigten Fassungen in vier Zweigen gleichzeitig bereit, dazu Vorab-Patches an Distributoren und LTS-Anbieter.[2][3][6]

Zehn Wochen für einen Fix im Kern einer Sprache, die den Großteil des Webs trägt, über vier parallele Versionszweige, mit Anbietern, WAF-Betreibern und Behörden – das ist der Teil dieses Vorgangs, der gut gelaufen ist. Die PHP Foundation schreibt aber auch den anderen Teil auf, und dieser Satz gehört in eine ehrliche Einordnung: „We won’t pretend otherwise: the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.“[3] Ein Projekt, das eine solche Lücke mit einem kleinen Security-Team verwaltet, ist keine Ausnahme, sondern der Normalfall in der Open-Source-Infrastruktur.

Volker Dusch von der PHP Foundation sagte dem Wall Street Journal, es sei das schwerste Problem gewesen, mit dem PHP in mehr als einem Jahrzehnt umgehen musste, und verglich es mit Heartbleed.[15] Wiz zieht die Linie auch zu Log4Shell.[15] Beide Vergleiche taugen als Maßstab für den Aufwand – nicht als Prognose für den eigenen Betrieb.

Was Sie jetzt tun sollten

Die Reihenfolge ist unspektakulär, und genau so sollte sie ablaufen.

Zuerst die Version. Ziel sind 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 – je nach Zweig – oder höher.[2] Betreiben Sie selbst, finden Sie den Stand in der phpinfo()-Ausgabe, über php -v auf der Kommandozeile oder im Hoster-Panel. Bei einem Managed-Paket hilft nur die Nachfrage beim Anbieter, und die sollte schriftlich kommen.

Danach der Neustart. Nach dem Update müssen die PHP-Prozesse und der Opcache neu anlaufen. Sonst bedient ein laufender Worker weiter mit dem alten Stand – die Dateien auf der Platte sind dann bereits sauber, während im Speicher noch die alte Laufzeit arbeitet. Das ist der Schritt, der in Betriebsabläufen am häufigsten untergeht.

Die Firewall bleibt wichtig, aber als zweite Lage. Cloudflare-Regeln und WAF-Sperren fangen einen Teil des Verkehrs ab, sie ersetzen das Update nicht und schützen nicht gegen Angriffe aus dem eigenen Netz.[6] Wer die Regel-Lage als erledigt verbucht, hat den Teil bearbeitet, der sich ohne Wartungsfenster erledigen ließ.

An CMS und Plugins ändert sich nichts. WordPress, Drupal und Joomla können nichts dafür und nichts dagegen; ein Plugin-Update behebt hier nichts, es verschiebt nur das Gefühl, etwas getan zu haben.[6] Dasselbe gilt für Theme-Basteleien und für den Hinweis, die Seite sei „nur eine Broschüre“.

Bleibt der Blick auf alte Zweige. Wer noch 7.4, 8.0 oder 8.1 fährt, sollte den Backport einspielen und parallel einen Wechsel planen. 8.2 läuft am 31.12.2026 aus, danach endet die Versorgung – und mit ihr die Annahme, dass es für den nächsten Fund dieser Art noch einen Patch geben wird.[2][15]

Was das für Handwerk und Mittelstand heißt

Für die Betriebe, mit denen wir arbeiten, ist dieser Fall vor allem eine Frage an den Hoster. Die Website läuft selten auf eigener Hardware, und die PHP-Version ist selten Teil des Gesprächs. Drei Fragen genügen für den Anfang. Welche PHP-Version läuft auf unserem Paket? Ist sie auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder höher? Und wurden die Worker nach dem Update neu gestartet? Fragen Sie das schriftlich an, am besten mit Verweis auf CVE-2026-109618 und CVE-2026-109619 – dann landet die Anfrage beim richtigen Ansprechpartner statt im allgemeinen Support-Postfach.

Wer die Antworten schriftlich bekommt, hat mehr gewonnen als mit jeder Sicherheitsfolie. Bleiben sie aus, ist das ein Befund für sich – gerade bei günstigen Paketen, die gern auf abgekündigten Zweigen laufen.

Der zweite Punkt betrifft Ihre Rolle im Betrieb, nicht die des Hosters. Dieselbe Fähigkeit, die den Fehler gefunden hat, verkürzt auch die Zeit zwischen Bekanntwerden und funktionierendem Angriff. Wer KI-Verfahren einsetzt – für Angebote, Kalkulation, Schriftverkehr –, muss die Sicherheitsseite mitplanen, und zwar als Betriebsfrage, nicht als Anhang zur Technik. Für Betriebe, die unter NIS-2 fallen, ist das ohnehin Pflicht: Schwachstellenmanagement ist dort eine Aufgabe mit Dokumentationspflicht. PHP2Shell ist ein Praxistest dafür, wie schnell Sie von „wir haben davon gelesen“ zu „wir haben es geprüft“ kommen.

Zum Schluss

Wenn Sie aus diesem Text eine Sache mitnehmen, dann diese: Die Frage nach der PHP-Version ist in fünf Minuten geklärt und ersetzt jede Diskussion über Sicherheitsgefühl. Wer KI im Betrieb betreibt, sollte die Antwort auf „wer aktualisiert das eigentlich“ außerdem in dasselbe Dokument schreiben wie die KI-Roadmap – dort wird sie auch gelesen, wenn die Roadmap das nächste Mal auf dem Tisch liegt.

Und wie ist es bei Ihnen? Wissen Sie, welche PHP-Version Ihre Website fährt? Schreiben Sie uns die Version – wir sagen Ihnen gern, ob der Stand für dieses Jahr noch reicht.

Was nicht belegt ist

Wir schreiben lieber auf, was wir nicht belegen können, als es glatt zu formulieren.

• „Die KI war vor den Angreifern“ ist nicht belegt. Amazon Threat Intelligence hat am 17.10.2026, vier Tage vor der Bekanntgabe, einen Ausnutzungsversuch gegen sein Honeypot-Netz beobachtet; ob er erfolgreich war, ist laut Amazon offen.[11] Horizon3 formuliert die Trennlinie sauber: „The advisories document demonstrated exploitation. Those demonstrations do not, by themselves, establish exploitation in the wild.“[10] OpenAIs „to our knowledge“ ist eine Selbstauskunft, kein Beweis.
• Die Angaben zur Verbreitung widersprechen sich deutlich. Es kursieren Größenordnungen von rund 1,3 Millionen Hosts über 1,9 Millionen bis zu 22,6 Millionen Exposed Instances, dazu die Schätzung von Wiz, PHP laufe auf etwa 70 Prozent aller Websites.[9][11][15] Die Zahlen beruhen auf unterschiedlicher Methodik und unterschiedlicher Grundgesamtheit. Wir nennen hier nur die Wiz-Schätzung und kennzeichnen sie als solche.
• Die „neun Stunden“ sind eine Herstellerangabe ohne genannten Bezugspunkt; bis zum Release um 13:30 UTC sind es rund zehneinhalb.[6][14]
• Der Name PHP2Shell ist kein Name des PHP-Projekts. Er stammt von Wiz, wo die beiden Lücken zu einem Exploit-Skript zusammengeführt und so benannt wurden.[4]
• Eine Angabe zum Umfang des Patches und eine neue INI-Einstellung memory_hard_limit_percent stammen aus einer Sekundärquelle, deren Commit-Bezug wir nicht geprüft haben. Wir führen beides deshalb nicht als Fakt.
• Die Zahl der Meldenden ist nicht abschließend geklärt. Cloudflare nennt Calif, Wiz, OpenAI und Quarkslab, OpenAIs Beitrag Quarkslab nicht.[6][14]

Quellen

Alle Adressen wurden am 22.10.2026 abgerufen. Zwei Einträge sind nur zur Nachvollziehbarkeit aufgeführt und tragen keine Aussage im Text: [1] ist die Ausgangsmeldung, die den Anlass gab, [13] eine Sekundärquelle, deren Commit-Bezug wir nicht geprüft haben.

1. all-ai.de, „GPT entdeckt kritische PHP-Lücke: Angriffe laufen bereits“, Andreas Becker, 21.10.2026 – https://www.all-ai.de/news/news26/gpt-php-angriffe (Ausgangsmeldung; diente als Anlass, nicht als Belegquelle)
2. The PHP Group, PHP-Archiv 2026, Sicherheitsrelease 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 – https://www.php.net/archive/2026.php (CVE-2026-109618 und CVE-2026-109619, CVSS 9,2, betroffene SAPIs, „updating is the only safe choice“, mod_php-Warnung)
3. The PHP Foundation, „Today’s PHP security release and how we’re strengthening PHP security“, 21.10.2026 – https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security (Meldedatum 11.08., falscher CVSS-Wert 10,0 in den geleakten IDs, Chainguard-Bruch des Embargos um 07:41 UTC, Selbstkritik an der Verzögerung)
4. Wiz Research, „PHP2Shell – PHP RCE“, 2026 – https://www.wiz.io/blog/php2shell-php-rce (unabhängiger Fund, Atlas / Gemini 4 Argon / GPT-5.6 Sol, „Hello World“-Zitat, Speicherinhalte, Exploit-Skript php2shell, „at the edge of what human researchers could practically achieve“)
5. OpenAI, „Coordinated disclosure of critical vulnerabilities“, 21.10.2026 – https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities (GPT-5.6 Sol, Patch the Planet, Defender’s Window, Koordination)
6. Cloudflare, „PHP vulnerabilities: WAF protection“, 21.10.2026 – https://blog.cloudflare.com/php-vulnerabilities-waf-protection (Regeln live 03:02 UTC für alle Pläne, Angriffsverkehr, Payload-Mutation, „updating website code or a plugin(s) alone does not fix these vulnerabilities“, Quarkslab)
7. Rapid7, „CVE-2026-109618 and CVE-2026-109619: Critical unauthenticated remote code execution in PHP“ – https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php (betroffene Betriebsarten, Handlungsempfehlungen)
8. Zscaler ThreatLabz, „CVE-2026-109618 and CVE-2026-109619: PHP vulnerable to unauthenticated RCE“ – https://www.zscaler.com/blogs/security-research/cve-2026-109618-and-cve-2026-109619-php-vulnerable-unauthenticated-rce (Speicherinhalte: Passwörter, Token, Schlüssel, Zertifikate)
9. Unit 42 (Palo Alto Networks), CVE-2026-109618 / CVE-2026-109619 – https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619 (technische Einordnung)
10. Horizon3.ai, „CVE-2026-109618 / CVE-2026-109619“ – https://horizon3.ai/attack-research/vulnerabilities/cve-2026-109618-cve-2026-109619 (Abgrenzung „demonstrated exploitation“ von „in-the-wild“)
11. Tenable, „PHP2Shell – Frequently asked questions“, 2026 – https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote (Ausnutzungsversuch am 17.10. gegen Honeypots, Backports für 7.4 / 8.0 / 8.1, divergierende Expositionszahlen)
12. OpenAI, „Daybreak for frontline defenders“, 03.09.2026 – https://openai.com/index/daybreak-for-frontline-defenders (eine Milliarde Dollar vergünstigter Zugang, Begriff Defender’s Window)
13. melihucar.com, „PHP2Shell“ – https://melihucar.com/articles/php2shell (Sekundärquelle zu Ablauf und Patch-Umfang; nicht als Beleg verwendet)
14. PPC Land, „Cloudflare blocks php2shell exploits 9 hours before PHP flaws went public“, 21.10.2026 – https://ppc.land/cloudflare-blocks-php2shell-exploits-9-hours-before-php-flaws-went-public (Vergleich Cloudflare-Angaben mit CERT-EU: 13:30 UTC, 10 h 28 min; Quarkslab; abweichende Versionsangaben)
15. The Next Web, „PHP rushes out emergency patches for two critical bugs AI found first“, 21.10.2026 – https://thenextweb.com/news/php2shell-php-rce-ai-openai-wiz (Patch the Planet, Calif-Aussagen und Zitat, Wiz-Vergleich mit Heartbleed und Log4Shell, 70-Prozent-Schätzung, CERT-EU-/NCSC-Hinweise, Offline-Nahmen einzelner Dienste, Dusch im Wall Street Journal, Backports)

Autor: Team REN-AI-SSANCE – mit KI-Unterstützung erstellt, von Menschen geprüft und freigegeben.