php2shell: Warum die PHP-Version wichtiger war als das CMS

Die Woche, in der PHP seinen eigenen Motor flicken musste

Am 21. Oktober 2026 hat das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Diese schließen zwei kritische Sicherheitslücken, die mittlerweile unter dem Namen php2shell bekannt sind. Über diese Lücken kann ein Angreifer ohne Anmeldung schadhaften Code auf einem Server ausführen. Wer eine Craft-Site betreibt und PHP noch nicht aktualisiert hat, sollte dies vor dem Weiterlesen unbedingt erledigen.

Sicherheitsupdates in der Craft-Welt betreffen meist ein Plugin oder ein neues Craft-Release. Bei php2shell ist das anders, denn der Fehler liegt in PHP selbst. Daher waren Craft-Sites genauso betroffen wie WordPress- oder Laravel-Sites auf demselben Server. In einem Craft-Projekt hätte man das Problem nicht verhindern können, entscheidend war die auf dem Server eingesetzte PHP-Version.

Im Folgenden wird erläutert, worum es bei den beiden Lücken genau geht, wie sie entdeckt wurden, warum die Veröffentlichung im Chaos endete und welche besonderen Auswirkungen das alles für Craft-Sites hat.

Zwei Fehler im Code, den jede Anfrage durchläuft

Beide Sicherheitslücken wurden nach CVSS 4.0 mit 9,2 von 10 bewertet. Ein Angreifer muss sich dazu nicht anmelden, um sie auszunutzen. Sie liegen in der Speicherverwaltung und Fehlerbehandlung von PHP, also in Code, den nahezu jede Anfrage durchläuft.

CVE-2026-109618: Speicherfehler am Memory Limit. Jede PHP-Anfrage läuft mit einem memory_limit. Überschreitet eine Anfrage diese Grenze genau im ungünstigen Moment, kann PHP halb aufgebaute interne Daten zurücklassen und sie später als gültig behandeln. Unter Apache mit mod_php ließ sich dies auslösen, noch bevor Anwendungscode ausgeführt wurde. Mit den Standardeinstellungen wurde eine vollständige Remote-Code-Ausführung nachgewiesen. Unter PHP-FPM ließ sich Codeausführung ebenfalls bestätigen, dort allerdings über Code-Pfade in Anwendungen.

CVE-2026-109619: Reste der vorherigen Anfrage. Ein fataler Fehler an einer falschen Stelle konnte dazu führen, dass PHP weiterhin auf Speicher zeigte, der zu einer früheren Anfrage gehörte. Die nächste Anfrage auf demselben Worker konnte diesen bereits freigegebenen Speicher verwenden – ein klassischer Use-after-free. Der Entdecker zeigte die Codeausführung in einer echten Anwendung unter Apache mit mod_php.

Da dieser Code zentral in PHP verankert ist, gestaltete sich die Behebung schwierig. Sie durfte weder die Kompatibilität brechen noch PHP verlangsamen oder ein großes Ökosystem an Drittanbieter-Erweiterungen zu Änderungen zwingen. Eine vollständige Abhilfe über die Konfiguration gibt es ebenfalls nicht. Laut dem PHP-Team ist ein Update die einzige sichere Lösung.

Warum die Fehlerbehebung zwei Jahre dauerte

Der Fehler im Memory Limit war nicht neu. Im Jahr 2024 durchlief PHP sein erstes externes Sicherheitsaudit seit mehreren Jahren. Finanziert wurde es von der deutschen Sovereign Tech Agency, organisiert von OSTIF und durchgeführt von Quarkslab. Beim Beheben eines von Quarkslab festgestellten Befunds entdeckte ein von der PHP Foundation beauftragter Core-Entwickler die ersten Anzeichen des Problems. Ein möglicher Exploit galt damals als denkbar, einen konkreten Angriffsweg fand jedoch niemand.

Das Sicherheitsteam entwickelte daraufhin mehrere konkurrierende Lösungen. Jede brachte ihre eigenen Nachteile mit sich: Brüche der Abwärtskompatibilität, neue Risiken für Denial-of-Service-Angriffe oder weitreichende Änderungen an zahlreichen Drittanbieter-Erweiterungen, deren Koordination sich in der Praxis kaum umsetzen ließ. Entscheidungen erforderten die Zustimmung aller Teammitglieder, die jedoch nicht erreicht wurde. Monatelang stockte die Arbeit und begann immer wieder von vorn. In ihrem eigenen Beitrag bezeichnet die PHP Foundation dies als strukturelles Versagen, verursacht durch den Entscheidungsprozess und durch fehlende Ressourcen.

In diesem Sommer nahm der Druck wieder zu. Am 30. Juli 2026 begann die Sicherheitsfirma Calif im Rahmen des Programms "Patch the Planet" von OpenAI mit einem Audit von PHP. Am 11. August entdeckte der Calif-Forscher Ryan Austin eine bedingungslose Remote-Code-Ausführung mit derselben Ursache. OpenAI stellte denselben Fehler unabhängig fest, während das Cloud-Sicherheitsunternehmen Wiz am 24. August weitere Angriffswege aufzeigte, gefolgt von zusätzlichen Erkenntnissen seitens OpenAI am 18. September. Ab dem 11. August hatte die Behebung dieses Problems für alle sicherheitsrelevanten Teams in der Foundation oberste Priorität, später arbeiteten sie rund um die Uhr daran.

KI-Tools spielten auf beiden Seiten eine Rolle. Das PHP-Projekt ließ seinen Code von Alpha-Omega mithilfe von Claude Mythos von Anthropic scannen und nutzt Tools von OpenAI, um Meldungen zu prüfen. Seit dem 1. Juli hat das Sicherheitsteam 15 CVEs veröffentlicht und mehr als 100 Meldungen bearbeitet, die sich als ungültig, doppelt oder nicht reproduzierbar herausstellten. Craft erlebt dieselbe Entwicklung. In einem Beitrag im Craft-Blog vom 17. Oktober erklärt Brad, dass die Zunahme an Craft-Sicherheitshinweisen auf KI-gestützte Sicherheitsforschung zurückzuführen sei und nicht darauf, dass Craft schlechter geworden sei.

In vielen Berichten dieser Woche wurde die Geschichte vereinfacht dargestellt. Die Associated Press veröffentlichte ihren Artikel unter der Überschrift, php2shell sei ein „AI-detected security bug“, obwohl im Artikel selbst steht, dass Menschen die Sicherheitslücken zuerst entdeckt haben. Die BBC begann ihren Erklärtext mit der Aussage, KI habe die Fehler ans Licht gebracht. In Deutschland legte ein vielfach übernommener dpa-Bericht nahe, die Schwachstellen seien wahrscheinlich durch intensiven KI-Einsatz entdeckt worden, da sie jahrzehntelang übersehen worden seien. Derselbe Text zitiert einen Bundestagsabgeordneten, der sagt, KI verwandle Schwachstellen, die zuvor als kaum ausnutzbar galten, in echte Einfallstore.

Die offizielle Chronologie verläuft weniger dramatisch. Im Jahr 2024 entdeckte ein Mensch bei einem klassischen Audit die Ursache. Die KI-gestützte Forschung zeigte 2026, wie ernst das Problem tatsächlich war, und erzwang die Behebung. Ein Forscher, den die BBC weiter unten im Artikel zitiert, bringt die Sache präziser auf den Punkt als der Einstieg: 

Was die Exploits danach beschleunigte, waren ein Leak und ein gelöschtes Video, nicht ein Modell.

Ein Leak, ein gelöschtes Video und ein gebrochenes Embargo

Die koordinierte Veröffentlichung hielt bis zwei Tage vor dem geplanten Release am 22. Oktober. Dann geriet sie außer Kontrolle. Alle Zeiten sind in UTC angegeben.

Warum nicht sofort veröffentlichen? Die Linux-Distributionen arbeiteten noch daran, den Fix in ihre Pakete zu integrieren. Ein sofortiges Release hätte viele Nutzer ohne einfache Update-Möglichkeit zurückgelassen. Das Veröffentlichungsdatum um einen Tag vorzuziehen, war daher ein Kompromiss.

Die frühen Images waren heikel, weil sich ein Patch rückwärts nachvollziehen ließ. Sobald die Binärdateien von Chainguard öffentlich wurden, konnte jeder untersuchen, was geändert worden war, während andere noch warteten. Das PHP-Team gibt an, zum Zeitpunkt des Releases keine funktionierenden Exploits gesehen zu haben. Der Beitrag von Craft ergänzt, dass es Hinweise auf Ausnutzung gab, bevor die Updates veröffentlicht wurden.

Laut BBC verzeichnete Cloudflare in den zehn Stunden vor der Ankündigung Tausende Angriffsversuche in seinem Netzwerk und danach Millionen; einen erfolgreichen Angriff hatte jedoch bis Freitagmorgen niemand gemeldet. Mehrere Websites gingen in der Zwischenzeit vollständig offline, und Wired veröffentlichte die Geschichte unter der Überschrift "This is not a drill".

Wer noch betroffen ist

Den offiziellen Fix gibt es nur für PHP 8.2 und neuere Versionen. PHP 8.1 und alle älteren Versionen haben das Ende ihres Lebenszyklus erreicht und erhalten keine regulären Updates mehr. Das Sicherheitsteam hat zwar minimale Backports für 7.4, 8.0 und 8.1 im Quellcode veröffentlicht, und einige Distributionen sowie Anbieter von Langzeit-Support stellen eigene Updates bereit. AWS weist jedoch darauf hin, dass es für CVE-2026-109618 keine Fixes für Versionen ohne Support gibt. Die US-Behörde CISA empfiehlt, Systeme, die nicht aktualisiert werden können oder auf Version 8.1 oder älter laufen, bis zur Installation eines Patches vom Netz zu nehmen.

Das ist eine große Gruppe. Qualys zählt rund 110 Millionen PHP-Installationen in den Versionen 5.4 bis 8.1, das entspricht 71 Prozent aller erfassten. Insgesamt wurden in den ersten zwölf Stunden nur etwa 199.000 Installationen gepatcht.

Bei Craft-Sites verrät die Hauptversion schon viel:

Ein Datum sollte man sich außerdem merken: PHP 8.2 erreicht am 31. Dezember 2026 sein Lebensende. Eine Craft-5-Website mit PHP 8.2 ist heute in Ordnung, doch das nächste PHP-Sicherheitsupdate könnte 8.2 bereits nicht mehr unterstützen.

Wie Craft Cloud damit umging und was das für eigenes Hosting heißt

Sites auf Craft Cloud waren bereits geschützt, bevor der Patch veröffentlicht wurde. OpenAI koordinierte sich vor der Veröffentlichung mit Cloudflare, das daraufhin Notfall-Firewallregeln im gesamten Netzwerk ausspielte. Laut Pixel & Tonic haben diese Regeln die Sites auf Craft Cloud wirksam geschützt; es sind keine erfolgreichen Angriffe bekannt. Sobald die gepatchten PHP-Versionen erschienen waren, baute Matthieu Napoli in gut einer Stunde neue Images für Bref, die PHP-Laufzeitumgebung hinter Craft Cloud. Das Cloud-Team setzte diese für alle Projekte ein. Bis auf eine kleine Anzahl von Sites mit bereits bestehenden Build-Problemen laufen inzwischen alle Cloud-Umgebungen mit den gepatchten Images.

Waren die Websites woanders gehostet, war der Tag härter. Zwischen Leak und Release gab es nichts zu installieren, sodass die eigentliche Frage darin bestand, wie viel Risiko man für ein paar Stunden in Kauf nehmen wollte. Was sinnvoll war, hing davon ab, wo eine Site betrieben wird:

• Managed Craft Hosting: herausfinden, welche Maßnahmen der Hoster ergriffen hat, und diese Informationen an die Kunden weitergeben. Der Großteil der Arbeit liegt beim Hoster.  
• Plattformen mit Wartungsmodus: Der Wartungsmodus hält alle Anfragen vollständig von PHP fern und reduziert so die Angriffsfläche, bis der Patch verfügbar ist.  
• Eigener Server oder VPS: Die Site per Firewall oder Webserver so absichern, dass nur man selbst darauf zugreifen kann, anschließend patchen und danach wieder freigeben.

Eine Kunden-Site vom Netz zu nehmen, ist nie eine beliebte Entscheidung. Bei einer Sicherheitslücke ohne Login-Hürde und bereits veröffentlichten CVE-Nummern sind jedoch einige Stunden Ausfall immer noch die günstigere Alternative, als einen kompromittierten Server zu bereinigen. Dies entspricht außerdem der Empfehlung der CISA für Systeme, die noch nicht gepatcht werden können.

Die Lehre für alle, die Craft-Sites betreuen, betrifft weniger Craft selbst als den Überblick: Für jeden Kunden muss klar sein, wo die Site läuft und wer für die Aktualisierung von PHP verantwortlich ist. Auf einer Managed-Plattform übernimmt der Hoster dies, auf einem VPS ist man selbst zuständig.

Wo Craft hilft und wo nicht

Kein CMS schützt vor einem Fehler in der PHP-Engine. Ist der Interpreter fehlerhaft, hat der Code darüber keinerlei Einfluss. Was Craft gut macht, ist, dafür zu sorgen, dass eine Site bevorzugt mit einer PHP-Version betrieben wird, für die eine Fehlerbehebung verfügbar ist, und dass man frühzeitig von Problemen erfährt.

Es lässt Sites nicht auf altem PHP hängen. Craft 5 setzt PHP 8.2 voraus. Als Craft 5 im Jahr 2024 erschien, wirkte das wie eine routinemäßige Anhebung der Systemanforderungen. In dieser Woche bedeutete es jedoch, dass keine Craft-5-Website auf einem PHP-Zweig ohne aktuelle Sicherheitsupdates betrieben werden konnte. Zum Vergleich: WordPress 7.0, erschienen im Mai 2026, läuft weiterhin offiziell mit PHP 7.4. Laut Qualys liefen 71 Prozent der PHP-Installationen auf nicht unterstützten Versionen.

Die Supportzeiträume stehen fest. Pixel & Tonic veröffentlicht für jede Hauptversion genaue Daten zum aktiven Support und zu den Sicherheitsupdates. Craft 5 erhält Sicherheitsupdates bis Ende 2031. Wenn ein Kunde fragt, wie lange seine Website sicher ist, kann auf eine entsprechende Seite verwiesen werden, statt eine Vermutung anzustellen.

Es informiert früh über Probleme. Craft betreibt ein Programm zur Meldung von Schwachstellen, veröffentlicht Sicherheitshinweise auf GitHub und bietet einen Feed für kritische Updates an. Zunächst erscheint das gepatchte Release, während die vollständigen Details 30 Tage später folgen, damit Betreiber die Möglichkeit haben, ihre Systeme zu aktualisieren, bevor die Hinweise öffentlich zugänglich werden. Auch das Control Panel zeigt entsprechende Update-Hinweise an.

Mehr Schlösser an der Haustür. Craft 5 bietet von Haus aus Zwei-Faktor-Authentifizierung und Passkeys. Gegen php2shell hilft das jedoch nicht, da hierfür kein Login erforderlich ist. Den häufigsten Weg in ein CMS, den Login, sichert es aber deutlich besser ab.

Das hauseigene Hosting reagierte innerhalb weniger Stunden. Craft Cloud kombinierte das vorgeschaltete Netzwerk von Cloudflare mit einer Laufzeitumgebung, die noch am selben Nachmittag neu erstellt und bereitgestellt wurde. Für ein kleines Team ohne Rufbereitschaft ist das ein starkes Argument.

Ein großer Teil der Sicherheit eines Craft-Projekts hängt davon ab, wie gut es gepflegt wird. Die Empfehlungen von Pixel & Tonic in den Beiträgen dieser Woche lassen sich auf zwei Punkte zusammenfassen: auf einer unterstützten Version zu bleiben und Updates zur Routine statt zur Ausnahme zu machen. Eine aktuelle Site verträgt einen Notfall-Patch an einem Nachmittag. Eine Site, die zwölf Monate hinterherhinkt, benötigt hingegen möglicherweise zunächst Arbeit an Abhängigkeiten und Plugins.

Der Teil, den kein Patch löst

Der wichtigste Absatz im Beitrag der PHP Foundation ist nicht technischer Natur. PHP wird für Behördendienste, Onlineshops, Banken und einen großen Teil des Internets genutzt, doch die Sicherheitsarbeit liegt weiterhin in den Händen einer kleinen Gruppe von Entwicklern, die von der Foundation bezahlt werden, sowie einiger Freiwilliger. Automatisierte Tools entdecken Fehler heute schneller denn je. Wie man eine tief in der Engine verankerte Designentscheidung korrigiert, können jedoch nur erfahrene Fachleute beurteilen, die die gesamte Codebasis kennen. Davon gibt es zu wenige.

Die Foundation bittet Unternehmen, die auf PHP setzen, Hoster und öffentliche Einrichtungen, diese Arbeit zu finanzieren. Viele von uns verdienen ihr Geld mit Craft-Websites. Ein Teil davon könnte durchaus an die zugrunde liegende Sprache zurückfließen. Agenturen und Unternehmen, die es sich leisten können, finden die Möglichkeiten auf der Sponsoring-Seite der PHP Foundation.

Quellen

• Today's PHP security release, and how we're strengthening PHP security, The PHP Foundation
• Craft Cloud and php2shell, Craft CMS blog
• Why Craft is publishing more security advisories, Craft CMS blog
• Supported versions, Craft CMS knowledge base
• PHP 8.2.35 release notes, php-src on GitHub
• Security advisory 2026-018, CERT-EU
• PHP security bulletin, AWS
• PHP2Shell: find, mitigate, and patch now, Qualys
• PHP2Shell remediation guide, SecurityScorecard
• Was Sie zur PHP-Sicherheitslücke wissen müssen, dpa via Tagesspiegel
• What to know about the AI-detected security bug impacting wide swaths of the internet, Associated Press
• What is PHP and why did it spark a global cyber-security scramble?, BBC News