PHP2Shell ist nicht das Problem, sondern eingefrorener Code
Zwei kritische PHP-Lücken, mit KI gefunden, wurden im Oktober geschlossen. Was ein gutes Setup ausmacht und wie Agenten eine Codebasis dorthin bringen.
Max SvistunovCTPO, Kadmo
Auf dieser Seite 5 Abschnitte
Am 21. Oktober hat PHP zwei kritische Lücken geschlossen, über die ein Angreifer mit einer einzigen Anfrage ohne Anmeldung Code auf einem Webserver ausführt. Der Code reicht laut Wiz zurück bis PHP 5.4 von 2012, und Forschende haben funktionierende Exploits gegen WordPress, Drupal, Magento, Laravel und Symfony gezeigt. Das Besondere an PHP2Shell ist, wie die Lücken gefunden wurden: KI-Modelle haben einen großen Teil der Suche übernommen. Es geht weniger um PHP als um Geschwindigkeit.
Ich habe über zehn Jahre PHP geschrieben, ein CRM, ein ERP, viel dazwischen, also habe ich an dem Tag alles gelesen, was erschienen ist. Das steht drin.
Was passiert ist
Beide Lücken, CVE-2026-109618 und CVE-2026-109619, stecken in der PHP-Engine und sind mit 9,2 nach CVSS v4 bewertet. PHP beantwortet jede Anfrage in einem Worker mit Speicherlimit. Eine Lücke beschädigt Speicher, wenn eine Anfrage dieses Limit erreicht, bevor die App startet. Die andere lässt nach einem fatalen Fehler Zustand zurück, der auf Speicher einer früheren Anfrage zeigt und den die nächste Anfrage auf diesem Worker dann nutzt.
Ein Update von WordPress, Drupal oder Laravel ändert nichts; nur ein PHP-Update behebt es. Behobene Releases: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4, 8.0 und 8.1 gibt es nur Backports im Quellcode; ältere Zweige bekommen nichts. Betroffen ist jedes Web-Setup, von PHP-FPM bis FrankenPHP; Rapid7 sieht mod_php als am stärksten gefährdet, weil der Angriff dort laufen kann, bevor Anwendungscode ausgeführt wird.
Wie KI die Lücken gefunden hat
Die Darstellung der PHP Foundation ist ungewöhnlich offen. Ein erstes Anzeichen des Speicherproblems tauchte 2024 bei einem Audit auf, doch der Fix blieb monatelang an konkurrierenden Ansätzen hängen. Die Foundation nennt das ein strukturelles Versagen ihres eigenen Ablaufs.
In diesem Jahr ging die Suche schneller. Calif meldete am 11. August aus einem Audit im Programm Patch the Planet von OpenAI eine Remote Code Execution, und OpenAI fand am selben Tag dieselbe Ursache. Wiz ergänzte am 24. August weitere Angriffswege, mit Gemini 4 Argon und GPT-5.6 Sol.
Ebenso aufschlussreich ist, was die Modelle nicht getan haben. KI hilft der Foundation beim Validieren von Meldungen und beim Sortieren von Duplikaten, aber jede Entscheidung trifft ein Mensch, und jeden Patch bearbeitet ein Mensch. Wiz beschreibt wiederholtes Testen und Debuggen durch die eigenen Forschenden, bis aus den Fehlern funktionierende Angriffe wurden.
Worauf man nüchtern schauen sollte
Die „70 Prozent des Internets“ aus den Schlagzeilen sind der Anteil von PHP an Websites, keine Zahl verwundbarer Server. Palo Alto Networks kommt auf 22,6 Millionen exponierte Instanzen, die verwundbar sein könnten. Nach den Zahlen von W3Techs läuft rund die Hälfte der PHP-Seiten auf einem Zweig, den PHP nicht mehr patcht.
Die Offenlegung lief nicht nach Plan. Am 20. Oktober sickerten die CVE-Nummern mit einer falschen Bewertung von 10,0 durch, Calif veröffentlichte versehentlich sein Proof-of-Concept-Video, und die Foundation zog das Release um einen Tag vor. Chainguard lieferte am nächsten Morgen gepatchte Images sechs Stunden zu früh aus.
Die Honeypots von Amazon hatten schon am 17. Oktober einen Angriffsversuch registriert, vier Tage vor der Offenlegung, und am Tag des Release sah Cloudflare Angreifer, die ihre Payloads änderten, um die Schutzregeln zu umgehen. Zum Release kannte die Foundation keinen funktionierenden Exploit; Rapid7 rechnet damit, dass sich das ändert.
Für die Maintainer ist KI auch kein Geschenk. Seit Juli hat das Sicherheitsteam von PHP 15 CVEs veröffentlicht und mehr als 100 ungültige, doppelte oder nicht reproduzierbare Meldungen bearbeitet, jede mit Zeit, die das Projekt kaum hat. Die Foundation hat das Release genutzt, um Unternehmen um Förderung zu bitten.
Was das für Teams heißt
Die Modelle, die die Lücken gefunden haben, stehen auch Angreifern zur Verfügung. Wiz schreibt, sie hätten die Hürde gesenkt, aus jahrzehntealten Fehlern funktionierende Exploits zu bauen. Das verändert die Uhr: Bei PHP2Shell kamen die Versuche vor dem Fix.
Der Engpass ist nicht, vom Patch zu erfahren. Er ist, ihn überall einzuspielen: jeder Server, jedes Container-Image, jede Serverless-Funktion, jedes vergessene Admin-Werkzeug. Googles Bericht zeigt die Trennung: App Engine Standard hat sich selbst aktualisiert, Cloud Run dort, wo automatische Base-Image-Updates an waren, und App Engine Flexible sowie selbst gebaute Images mussten von Hand neu gebaut werden. Derselbe Bug, derselbe Tag; der Unterschied war das Setup.
Vier Dinge machen dieses Setup aus. Richten Sie sie vor dem nächsten PHP2Shell ein, nicht mittendrin.
Im Support-Fenster bleiben. Jeder PHP-Zweig bekommt zwei Jahre Fixes und zwei weitere Jahre Sicherheitsfixes. 8.1 und älter liegen außerhalb; 8.2 fällt am 31. Dezember heraus. Betreiben Sie eine aktuelle Laufzeit mit einem gepflegten Framework; die Sprache ist nicht der Punkt.
Wissen, was man betreibt. Die erste Anweisung der CISA war, jedes System mit PHP zu inventarisieren. Eine aktuelle Liste der Dienste mit Laufzeit und Version macht aus „Sind wir betroffen?“ eine Abfrage.
Patchen als Routine statt als Ereignis. Basis-Image anheben, neu bauen, testen, ausrollen: jedes Mal dieselbe Aufgabe. Ein Team, das sie wöchentlich für kleine Updates erledigt, kann sie bei einem kritischen Update in Stunden schaffen. Verfolgen Sie die Zeit von einem verfügbaren Fix bis zu dem Moment, in dem er überall läuft.
Nach Risiko entscheiden, wer was prüft. Ein Versionssprung bei einem internen Werkzeug mit guten Tests geht bei grünen Checks durch. Eine Änderung am Checkout eines Shops bekommt einen Menschen, bevor sie live geht.
Wer nicht sofort patchen kann, findet bei Rapid7 Notlösungen: Session Upload Progress abschalten, unter 8.5 die Backtraces bei fatalen Fehlern abschalten, das Speicherlimit aufheben. Sansec warnt, dass Letzteres einer einzelnen Anfrage den gesamten Speicher eines Servers überlässt; alle drei sind eine Brücke bis zum Update. Systeme, die sich gar nicht aktualisieren lassen, gehen laut CISA vom Netz, bis es geht.
Bei Kadmo behandeln wir das als Transformation, nicht als Patch. Spezialisierte Agenten arbeiten nach Playbooks auf Ihrer eigenen Infrastruktur, mit jedem LLM.
- Wissen zuerst. Die Agenten lesen die Codebasis und das laufende Produkt und schreiben das Knowledge Pack: Modulkarte, Geschäftsregeln, Datenmodell, Integrationen, Weg zum Deploy. Ihre Arbeitsanweisung und Ihre Dokumentation in einem.
- Ein aktueller Stack oder eine andere Sprache. Ein aktuelles PHP, TypeScript, Java, Go oder .NET. Was immer Ihr Team einstellen kann.
- Die Cloud. Container-Images und verwaltete Laufzeiten, die den nächsten Patch von allein nehmen.
- Agentische Entwicklung. Upgrades, Tests und Releases laufen über Playbooks. Ein Gate entscheidet nach Risiko, ob ein Mensch draufschaut, bevor es live geht.
- Ihr Review, Ihre Tools, Ihre Cloud. Modul für Modul, jede Änderung ein Pull Request, den Ihr Team reviewt.
Wenn Sie sehen wollen, wie das bei Ihnen aussehen kann, zeigen wir es Ihnen gern.
Wann hat Ihr Team zuletzt den ältesten Dienst ausgerollt, den Sie betreiben?
Quellen
- https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
- https://www.wiz.io/blog/php2shell-php-rce
- https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
- https://sansec.io/research/php2shell
- https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
- https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619
- https://www.php.net/supported-versions.php
- https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
- https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
- https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
- https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released
- https://w3techs.com/technologies/details/pl-php
