Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßig die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619, die unter dem Namen PHP2Shell bekannt geworden sind. Beide erlauben es einem Angreifer, unter den richtigen Bedingungen ohne Anmeldung Code auf einem Server auszuführen, und sind mit CVSS 9,2 bewertet [1, 2]. Der Name beschreibt das Ergebnis recht genau: im schlimmsten Fall von einer einzigen PHP Anfrage direkt zur Shell auf dem Server.

Was PHP2Shell von typischen Webschwachstellen unterscheidet, ist der Ort des Fehlers. Er steckt nicht in WordPress, einem Plugin oder schlechtem Anwendungscode, sondern in der PHP Laufzeitumgebung direkt. Betroffen ist jede Installation, die Webanfragen verarbeitet, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed, zurück bis zur PHP Version 5.4. Das höchste Risiko trägt der Betrieb mit mod_php [1, 2]. Eine vollständig aktualisierte WordPress-, Drupal- oder Joomla-Instanz ist also trotzdem angreifbar, solange das PHP darunter betroffem ist. Codeausführung wurde gegen aktuelle Container-Images genau dieser Systeme demonstriert [2].

Blick unter die Haube

Technisch stecken hinter den zwei CVEs vier miteinander verwandte Speicherfehler in der Speicherverwaltung und Fehlerbehandlung von PHP [1, 3]. Der Kern ist jeweils der Umgang mit dem memory_limit, allerdings auf zwei unterschiedlichen Wegen:

CVE-2026-109618 (Out-of-Memory-Korruption innerhalb einer Anfrage): Stößt eine Anfrage im exakt falschen Moment an das Speicherlimit, lässt PHP halb initialisierte interne Datenstrukturen zurück und verarbeitet diese noch beim Aufräumen derselben Anfrage als valide. Unter Apache mit mod_php greift dieser Fehler, noch bevor überhaupt eine Zeile Anwendungscode läuft – hier reicht bereits eine einzige präparierte Anfrage für eine direkte Codeausführung [1].

CVE-2026-109619 (Cross-Request Use-After-Free): Hier provoziert der Angreifer beispielsweise über einen präparierten Datei-Upload als multipart/form-data, dessen Daten für die Upload-Fortschrittsanzeige der Session genau bemessen sind, noch während des Parsens einen Speicherüberlauf. PHP bricht die Anfrage mit einem fatalen Fehler ab und gibt den Speicher frei. Das Zurücksetzen interner globaler Zeiger findet dabei aber nicht statt. Der Worker-Prozess lebt weiter, nimmt die nächste Anfrage an und arbeitet mit Zeigern auf bereits freigegebenen Speicher. Hat der Angreifer diesen Speicher inzwischen mit eigenen Daten belegt, behandelt PHP diese Bytes als vertrauenswürdige interne Struktur – ein klassischer Use-after-free [2].

Aus diesem verwaisten Zustand entstehen mehrere Angriffsprimitive. Bleibt der Zeiger auf die Session-ID stehen, schreibt PHP den Inhalt des wiederbelegten Speichers URL-kodiert in das PHPSESSID-Cookie der Antwort. Der Angreifer liest so den Arbeitsspeicher des Workers aus – ähnlich wie einst bei Heartbleed –, inklusive Passwörtern, Tokens und API-Schlüsseln [2, 3]. Das Leck verrät außerdem Speicheradressen. Kombiniert mit einem weiteren Use-after-free im Unserializer, der Speicher gezielt korrumpiert, reicht das für eine Codeausführung ohne Authentifizierung [2]. Auf PHP-FPM wurde die Ausnutzung über entsprechende Codepfade in der Anwendung ebenfalls bestätigt [1].

Seit 2024 bekannt: Warum der Fix im Konsens steckenblieb

Bemerkenswert ist, dass der Kern des Problems seit 2024 bekannt war. Damals gab es das erste externe Sicherheitsaudit von PHP seit Jahren, finanziert von der Sovereign Tech Agency, organisiert über OSTIF und durchgeführt von Quarkslab. Beim Beheben eines der Befunde stieß ein Core-Entwickler auf erste Anzeichen des Out-of-Memory-Problems. Ein Exploit galt als theoretisch denkbar, ein konkreter Angriffsweg wurde aber nicht gefunden, und andere Befunde mit klarer Auswirkung hatten Vorrang [1]. Warum es trotzdem keinen Fix gab, beschreibt die PHP Foundation ungewöhnlich offen. Das Sicherheitsteam entwickelte mehrere konkurrierende Lösungen, die jeweils einen Preis hatten: Brüche der Abwärtskompatibilität, neue Angriffsfläche für Denial of Service oder Änderungen an vielen Erweiterungen von Drittanbietern, die sich kaum koordinieren ließen. Das Team entscheidet im Konsens, konnte sich nicht festlegen und fürchtete die Folgen einer falschen Wahl. Dazu kamen der fehlende Nachweis eines Wegs zur Codeausführung. Die Arbeit am Fix lief deshalb über Monate immer wieder an und blieb wieder liegen. Die Foundation nennt das selbst ein strukturelles Versagen, verursacht durch den Entscheidungsprozess und fehlende Ressourcen [1]. Es ging also nicht um eine verschwiegene Lücke. Der Fehler war bekannt, seine Tragweite wurde unterschätzt, und einem Projekt, auf dem ein großer Teil des Webs läuft, fehlten die Leute für eine schwierige Architekturentscheidung.

KI als Brandbeschleuniger

Geändert hat das die KI-gestützte Sicherheitsforschung. Die PHP Foundation brachte PHP in OpenAIs Programm Patch the Planet. Darüber begann die Sicherheitsfirma Calif am 30. Juli 2026 ein Audit und meldete am 11. August eine Remote Code Execution mit derselben Ursache wie das Problem von 2024 – noch am selben Tag reichte auch OpenAI unabhängig davon einen Bericht zum selben Grundproblem ein. Weitere Angriffswege folgten kurz darauf von Wiz (24. August) und erneut von OpenAI (18. September) [1]. Calif und OpenAI arbeiteten mit dem Modell GPT-5.6 Sol. Wiz stieß unabhängig auf dieselbe Fehlerfamilie und nutzte neben GPT-5.6 Sol und der eigenen Plattform Wiz Atlas eine Vorabversion von Googles Gemini 4 Argon [3]. Die Leistung der Modelle lag weniger darin, einen völlig unbekannten Bug zu finden. Sie haben einen bekannten, als kaum ausnutzbar eingestuften Fehler in eine reproduzierbare Angriffskette übersetzt. Mehrere Speicherfehler so zu verketten, dass am Ende stabile Codeausführung steht, war bisher monatelange Handarbeit. Genau diese Komplexität hat das Web über ein Jahrzehnt faktisch geschützt [3]. Laut den Forschern haben KI-Modelle diesen Aufwand auf Tage verkürzt [2]. Die Kehrseite spürt auch die Foundation: Seit dem 1. Juli hat das Team 15 CVEs veröffentlicht und über 100 Meldungen bearbeitet, die sich als ungültig, doppelt oder nicht reproduzierbar erwiesen [1].

Chronologie eines gescheiterten Embargos

Geplant war die koordinierte Veröffentlichung für den 22. Oktober um 14:00 UTC. Am 20. Oktober gegen 15:00 UTC tauchten die beiden CVE-Nummern jedoch vorab in Foren und sozialen Medien auf, mit falschem Termin und einem falschen CVSS-Wert von 10,0, aber noch ohne technische Details. PHP zog daraufhin die Vorankündigung vor und verlegte das Release auf den 21. Oktober, 14:00 UTC. Sofort zu veröffentlichen war keine Option, weil die Distributionen ihre Pakete noch bauten und viele Nutzer sonst keinen einfachen Updateweg gehabt hätten [1]. Danach verschärfte sich die Lage. Calif veröffentlichte versehentlich ein Video, das den Proof of Concept gegen mehrere Ziele zeigte. Kopien verbreiteten sich und beschleunigten die Entwicklung eigener Exploits. Am Morgen des 21. Oktober brach Chainguard das Embargo und veröffentlichte fertige Images mit dem Fix, mehr als sechs Stunden vor dem Release. Ab diesem Moment konnte jeder den Patch im Binärformat analysieren [1]. Noch brisanter: Wie eine nachträgliche Auswertung von Amazon zeigt, liefen die ersten Angriffe sogar schon vor diesen Leaks. Im Honeypot-Netz MadPot wurde bereits am 17. Oktober ein Ausnutzungsversuch registriert – vier Tage vor der Veröffentlichung, ausgehend von der IP-Adresse eines kommerziellen Anonymisierungsdienstes. Wie der Angreifer an die Informationen kam, ist unklar [4].

Für viele Betreiber war Abschalten in dieser Lage die vernünftigste Option. Das BSI gab eine Cybersicherheitswarnung der zweithöchsten Stufe heraus und empfahl, betroffene Webserver im Zweifel vorübergehend vom Netz zu trennen. Regierungsstellen in Finnland und den Niederlanden, Teile der BBC, zahlreiche deutsche Kommunen, Krankenhäuser und Hochschulen schalteten ihre Seiten und Services zeitweise ab [3]. Der Grund waren fehlende Alternativen. Eine Web Application Firewall bietet keinen vollständigen Schutz, und Konfigurationsänderungen wie session.upload_progress.enabled=0 oder memory_limit=-1 sind nur eine Übergangslösung mit Nebenwirkungen: Wer das Speicherlimit in PHP deaktiviert, ohne die Prozesse auf Betriebssystemebene sauber über Linux cgroup v2 (memory.max) zu begrenzen, öffnet die Tür für einfache Denial-of-Service-Angriffe [1, 3]. Laut Amazon gibt es keine reine Konfigurationsmaßnahme, die beide Schwachstellen vollständig behebt [4]. Wer nicht sofort patchen konnte, weil das Paket der Distribution fehlte oder Container erst neu gebaut werden mussten, stand vor der Wahl zwischen offenem Risiko und Offline-Zeit.

Unmittelbar zum Zeitpunkt der Veröffentlichung am 21. Oktober meldeten CISA, Huntress, die PHP Foundation und watchTowr zwar noch keine bestätigten erfolgreichen Einbrüche in Produktivsysteme, da viele frühe Proof-of-Concepts unzuverlässig waren [6]. Der Angriffsdruck war dennoch sofort enorm: Cloudflare zählte in den 45 Minuten nach der Bekanntgabe Zehntausende Ausnutzungsversuche, nach zwei Stunden Hunderttausende und später Millionen [5]. Inzwischen ist auch die aktive Ausnutzung in freier Wildbahn offiziell bestätigt: Am 26. Oktober hat die US-Behörde CISA beide Schwachstellen in ihren Katalog aktiv ausgenutzter Sicherheitslücken (KEV) aufgenommen [7].

Was das für Patchmanagement und Betrieb bedeutet

Die wichtigste Lehre betrifft das Patchmanagement. Amazon beschreibt, dass die Zeit vom Patch zum funktionierenden Exploit aus strukturellen Gründen schrumpft. Früher bauten wenige fähige Akteure Exploits, alle anderen warteten auf einen öffentlichen Proof of Concept. KI-gestützte Analyse macht es billiger, aus einem Patch-Diff oder Advisory einen funktionierenden Exploit abzuleiten. Dadurch können deutlich mehr Akteure innerhalb von Stunden oder Minuten handeln [4]. Amazon empfiehlt deshalb, Patch- und Mitigationszeiten für kritische Lücken an internetexponierten Systemen in Stunden zu messen. Ein SLA von 7 oder 30 Tagen setzt einen Zeitpuffer voraus, den es nicht mehr gibt [4].

Für Unternehmen heißt das konkret:

• Vollständige Inventarisierung: Man muss wissen, wo überall PHP läuft. Das betrifft nicht nur die eigene Website, sondern auch Appliances, Container-Images, eingebettete Weboberflächen und vergessene interne Tools. Das niederländische NCSC führt eine laufend ergänzte Liste betroffener Drittprodukte, darunter Firewalls wie pfSense und OPNsense [3].
• Am selben Tag patchen – und Prozesse neu starten: Patchprozesse für exponierte Systeme müssen ein kritisches Update innerhalb von Stunden ausrollen können, inklusive Neubau von Containern. Wichtig dabei: Ein reines Paket-Update auf der Festplatte reicht nicht. Erst nach einem Neustart von Apache, PHP-FPM und sämtlichen langlaufenden Worker-Prozessen ist der verwundbare Code auch aus dem Arbeitsspeicher verschwunden [2].
• Altlasten ablösen: Für PHP 8.1 und älter gibt es keine offiziellen Releases mehr [2], lediglich Rückportierungen für einzelne ausgelaufene Zweige durch Linux-Distributionen [3].Notfall-Abschaltungen vorab regeln: Die Entscheidung, ein System im Notfall vom Netz zu nehmen, sollte vorher mit den Fachbereichen abgestimmt sein und nicht erst unter Zeitdruck entstehen.
• Secrets rotieren und Forensik starten: Ein Patch schließt nur die Lücke. Zugangsdaten, Tokens und API-Schlüssel, die vorher aus dem Speicher gelesen wurden, bleiben kompromittiert und sollten auf exponierten Servern rotiert werden [2]. Untersuchungen sollten laut Amazon mindestens ab dem 17. Oktober ansetzen – wobei unauffällige Anwendungs-Logs keine Entwarnung sind, da der Absturz oft greift, bevor die Anwendung den Request protokolliert [2, 4].

PHP2Shell zeigt beide Seiten derselben Entwicklung. KI hat einen über zehn Jahre alten Fehler ausnutzbar gemacht und damit auch endlich behoben. Dieselben Werkzeuge stehen Angreifern zur Verfügung und verkürzen die Zeit zwischen Veröffentlichung und Angriff von Tagen auf Stunden. Mit einem Puffer von mehreren Tagen zwischen Advisory und Ausnutzung sollte niemand mehr planen.

Quellen

[1] 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/ [2] Varonis Threat Labs: PHP2Shell: One Upload, Full Server, 22.10.2026 (aktualisiert am 23.10.2026). https://www.varonis.com/blog/php2shell [3] t3n: PHP2Shell: Wie KI-Modelle einen zehn Jahre alten Fehler im Fundament des Webs fanden, 21.10.2026. https://t3n.de/news/php2shell-sicherheitsluecke-php-bsi-warnung-1769356/ [4] AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, 21.10.2026. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ [5] SiliconANGLE: PHP2Shell attacks began four days before patches, Amazon says, as attempts hit millions, 22.10.2026. https://siliconangle.com/2026/10/22/php2shell-attacks-began-four-days-before-patches-amazon-says-as-attempts-hit-millions/ [6] implicator.ai: Amazon logged a PHP2Shell exploit attempt four days before disclosure, 22.10.2026. https://www.implicator.ai/amazon-logged-a-php2shell-exploit-attempt-four-days-before-disclosure/ [7] CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog (CVE-2026-109618, CVE-2026-109619), 26.10.2026. https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog