Die Forscher, die die PHP2Shell-Bugs gefunden haben, waren erstaunlich deutlich darin, was die KI in ihrer Toolchain konnte und was nicht. „Kein Modell ist in der Lage, mit simplen Prompts einfach ‚alle Bugs' aufzuspüren. Zumindest vorerst nicht", schrieb die Sicherheitsfirma Calif in ihrem Write-up, zitiert von TechCrunch. Behalten Sie diesen Satz im Kopf, wenn Sie Schlagzeilen lesen, nach denen Maschinen Lücken schneller finden, als Menschen sie schließen können. Die Schlagzeilen stimmen größtenteils, aber die Details sind seltsamer.
Mehrere voneinander unabhängige Geschichten laufen auf denselben Punkt hinaus. Google hat ein Modell vorgestellt, das gezielt Schwachstellen jagt. Anthropic hat Exploit-Ketten eines Modells veröffentlicht, das es nicht freigegeben hat. OpenAI sagt, die eigenen Agenten hätten eine Lücke in einer weit verbreiteten Kompressionsbibliothek gefunden. Und die meistgenutzte Websprache der Welt brauchte Notfall-Patches. Hier sehen Sie, wie das zusammenhängt, wer profitiert und was ein kleiner Website-Betreiber noch vor dem Mittagessen tun kann.
Die PHP-Bugs waren alt. Neu ist, wer sie ausnutzen kann
Die beiden Lücken heißen PHP2Shell und werden als CVE-2026-109618 und CVE-2026-109619 geführt. Damit kann jemand ohne Passwort über das Internet Code auf einem Server ausführen. Sie stecken in jeder PHP-Version seit PHP 5, das 2004 erschien (TechCrunch). PHP steckt hinter rund 70 % aller Websites, darunter WordPress, Drupal, Joomla und MediaWiki.
Niemand hatte sie geknackt. Die PHP Foundation kannte die Bugs seit 2024 und ließ sie ungepatcht, weil es keinen praktikablen Weg gab, sie auszunutzen (TechCrunch). Dieses Jahr fanden Forscher von Calif heraus, wie sich die Lücken ausnutzen lassen, mit Unterstützung eines KI-Modells, im Rahmen des Open-Source-Sicherheitsprogramms von OpenAI und Wiz. Einer der TechCrunch-Podcast-Hosts sagte zunächst, KI-Modelle hätten die Lücken gefunden, und korrigierte das später im Write-up: Menschliche Forscher fanden sie und setzten KI ein, um den Bug auszunutzen (TechCrunch).
Wir halten diese Korrektur für die nützlichste Erkenntnis der ganzen Geschichte. Dass Modelle Bugs entdecken, ist die kleinere Verschiebung. Die größere: Bugs, die unter „theoretisch" abgelegt waren, werden real, sobald ein Modell einen Exploit an unterschiedliche Setups anpassen kann. Wiz formulierte es in einem eigenen Beitrag so, zitiert von TechCrunch: „Mit KI ist das keine Hürde mehr. LLMs können helfen, einen Exploit an verschiedene PHP-Versionen, Konfigurationen und Speicherlayouts anzupassen."
Die Patches erschienen in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, nachdem große Hoster und Cloud-Unternehmen unter Embargo einen frühen Einblick bekommen hatten. Die NSA riet Website-Betreibern anschließend, alles, was sich nicht sofort patchen lässt, vom Netz zu nehmen, und Banken, Händler, Krankenhäuser und einige Behörden taten genau das (TechCrunch).
Die Angriffe begannen vor dem Patch
Amazon sagt, seine Honeypots hätten vier Tage vor der Veröffentlichung einen Angriffsversuch auf beide Lücken protokolliert. Cloudflare meldete, die Versuche seien innerhalb von 45 Minuten nach der Ankündigung auf Zehntausende und bis zum nächsten Morgen auf Millionen gestiegen (The Hacker News). Die PHP Foundation machte ein Unternehmen verantwortlich, das Patches Stunden vor Ende des Embargos live geschaltet hatte. Aktivität Tage zuvor erklärt das nicht, und nach der von uns gesichteten Berichterstattung hat bisher niemand gesagt, woher der frühe Angreifer Bescheid wusste.
Dann wurden die Angriffe gezielter. Die Sicherheitsfirma Dream verfolgte einen mutmaßlich China-nahen Akteur, der PHP2Shell mit einer Linux-Kernel-Lücke verkettete und 25 Server übernahm, drei davon in einem Netzwerk mit Verbindung zur US-Regierung. Die Ziele waren Firewall-Appliances mit PHP 8.0.30. „Die von uns gesicherte Implementierung ist ein individueller, nicht öffentlicher Build und keine Kopie eines bekannten öffentlichen Exploits für PHP2Shell", so die Forscher von Dream (The Hacker News). Sie fanden außerdem Claude Code in der Infrastruktur des Angreifers, dazu ein Offensive-Security-Tool, das an DeepSeek- und Kimi-Modelle angebunden war. Das deutet auf KI-Hilfe beim Bau der Tools hin. Die Zuordnung ist hier Dreams Einschätzung, kein gesichertes Ergebnis.
Die CISA bestätigte fünf Tage nach den Patches aktive Ausnutzung und nahm beide Lücken in ihren Known Exploited Vulnerabilities Catalog auf. Zivile Bundesbehörden haben drei Tage, ihre Systeme zu beheben (TechCrunch). Noch ein ehrlicher Hinweis: Manche Forscher sagen, ein zuverlässiger Exploit sei schwerer zu bauen als befürchtet, und erste Versuche, eine Mirai-Botnet-Variante einzuschleusen, sind bisher gescheitert (The Hacker News).
Google hat den Scanner gebaut, den alle wollen – und die meisten von uns können ihn nicht nutzen
Google kündigte Gemini 4 Carbon an, während die PHP-Aufräumarbeiten noch liefen, und nannte es sein stärkstes Modell mit „State-of-the-Art-Fähigkeiten in Cybersicherheit und bei langen Zeithorizonten" (Google). Laut Google erreicht Carbon 88,2 % auf SEC-bench Pro beim Finden echter Schwachstellen, 54,8 % auf ExploitGym beim Ausnutzen und 71,0 % auf CWE-bench beim Schreiben des Fixes. Außerdem sagt Google, das Chrome-Team habe Carbon bei hochwertigen Patches mehr als zehnmal besser gefunden als das Frontier-Modell eines anderen Labors. Wiz, das zu Google gehört, meldet, Carbon führe seine Benchmarks für Web-Penetrationstests an.
Das sind Googles Zahlen, ohne Guardrails gemessen, und die drei Benchmarks messen Verschiedenes, rechnen Sie sie also nicht gegeneinander auf. Auffällig ist, dass das Patchen überhaupt auf der Anzeigetafel steht. The Verge berichtet, Carbon schlage GPT-6 Astra auf SEC-bench Pro und führe einen unabhängigen Intelligence-Index an, dahinter Claude Opus 5.5 (The Verge).
Jetzt der Haken. Carbon steht nur einem Teil der Cyber-Verteidiger offen, erweitert über Googles Fairwind Program, während Google Feedback zu Guardrails sammelt und den freiwilligen Pre-Release-Test der US-Regierung durchläuft. Entwicklern und Unternehmen verspricht Google Zugang „so bald wie möglich", ohne Datum. Der Einführungspreis liegt bei 2 $ pro Million Input-Tokens und 10 $ pro Million Output-Tokens. Laut Googles Fußnote steigt er nach der Einführungsphase auf 4 $ und 20 $.
Anthropic und OpenAI argumentieren genauso
Anthropics Frontier Red Team hat fünf Exploit-Ketten eines unveröffentlichten, internen Forschungsmodells publiziert, für Chrome, Safari, Android, Windows und Linux. Die Chrome-Kette verband vier Lücken und endete mit Code, der außerhalb der Browser-Sandbox läuft. Die Linux-Kette lieferte eine Root-Shell über das Netzwerk, ganz ohne Login. Anthropic sagt, es habe jede Lücke zuerst dem Hersteller gemeldet. Allein für Chrome seien 62 CVEs vergeben und gepatcht worden, alle als kritisch oder hoch eingestuft, 13 davon Sandbox-Escapes (Anthropic). Als Grund für die Veröffentlichung nennt Anthropic: „Heute können Modelle das mit wenig menschlichem Zutun und beweisen es dann mit einem funktionierenden Exploit, den jeder ausführen und überprüfen kann."
Betrachten Sie das als Behauptung, so wie The Hacker News es auch getan hat. Apple und Google nennen Anthropic-Forscher, die mit Claude arbeiteten, bei bestimmten Fixes als Urheber, und das lässt sich prüfen. Wie viel von jeder Kette das Modell allein gebaut hat, nicht, denn Anthropic schlüsselt nicht auf, was ein Mensch in jedem Schritt getan hat. The Hacker News stellte außerdem fest, dass zwei der öffentlichen CVE-Einträge die Lücken nicht ganz so beschreiben wie Anthropics Beitrag. Zugang für geprüfte Sicherheitsfachleute läuft über das Cyber Verification Program, das neben anderen Modellen auch Claude Opus abdeckt.
OpenAIs Version kam laut Reuters mit einem Geständnis. Nachdem ein Forschungsmodell Anfang des Jahres über einen Konfigurationsfehler ins Internet gelangt war, setzte das Unternehmen sein fortgeschrittenstes Training aus, verschärfte die Sicherheit und startete es neu, sobald die neuen Kontrollen standen. Um die neuen Schutzmaßnahmen zu testen, ließ es Teams aus KI-Agenten auf den Ausbruch los. Sie fanden eine Lücke in Brotli, einer Kompressionsbibliothek, die Node.js, Bun und Envoy nutzen. Das Detail, auf das wir immer wieder zurückkommen: OpenAI sagt, die Ursache sei im Quellcode von Brotli schon Monate zuvor behoben worden, bevor jemand wusste, dass es eine Schwachstelle war, und es sei keine neue Version erschienen. Monatelang gab es einen Fix. Keine Release enthielt ihn, bis OpenAI die Lücke offenlegte.
OpenAIs Launch-Beitrag zum Programm Patch the Planet mit Trail of Bits erklärt, warum der Mensch im Prozess bleibt. Frontier-Modelle, heißt es dort, „erzeugen viele False Positives, die zum ohnehin überwältigenden Rückstau der Maintainer beitragen können", deshalb prüfte Trail of Bits jeden Fund, bevor ein Maintainer ihn sah (OpenAI). Das Programm nutzt Codex Security und hat bisher Hunderte Probleme in 19 Projekten aufgedeckt.
Finden wurde billig. Beheben nicht
Das Missverhältnis passt in ein Bild. Alles in der oberen Reihe läuft inzwischen mit Maschinengeschwindigkeit. Alles in der unteren Reihe braucht weiterhin einen Menschen mit Terminkalender.
Fangen wir bei den Menschen unten an. TechCrunch weist darauf hin, dass Open-Source-Maintainer oft unbezahlt arbeiten und sich keine externen Sicherheitsreviews leisten können, während Unternehmen, die von ihrer Arbeit abhängen, oft nichts beitragen (TechCrunch). Auch die Regeln zur Offenlegung stammen aus langsameren Zeiten. Anthropics Richtlinie gibt Entwicklern 90 Tage zum Patchen und weitere 45, bevor Details über ein Advisory hinaus besprochen werden. Bei PHP2Shell gab es Versuche vier Tage vor der Veröffentlichung und bestätigte Angriffe fünf Tage nach dem Fix.
Sean O'Kane sagte im Equity-Podcast von TechCrunch, auf der „Knochenebene des Internets" werde alles „von Klebstoff und Träumen zusammengehalten" (TechCrunch). Wiz' CTO für Exposure Management und Application Security, Tomer Schwartz, argumentierte in derselben Sendung, dass manuelles Patchen nicht skaliert (TechCrunch). Dem zweiten Punkt stimmen wir mehr zu als dem ersten.
Wer profitiert, wer ist exponiert
| Gruppe | Warum |
|---|---|
| Große Hoster und Cloud-Plattformen | Bekommen Patches unter Embargo. Wiz dankte Automattic, Akamai, AWS, Cloudflare, Fastly, Imperva, Microsoft und Vercel für die Hilfe bei PHP, so TechCrunch. |
| Teams mit Scanner-Zugang | Früher Zugang zu Modellen wie Carbon und zum Anthropic-Programm macht aus einem Rückstau eine priorisierte Liste. |
| Einzelentwickler und kleine IT-Teams | TechCrunch erwartet, dass sie langsamer updaten, und sie haben den geringsten Spielraum. |
| Appliances und alte Stacks | Firewalls, Router und Storage-Boxen enthalten PHP. Die Opfer von Dream liefen auf PHP 8.0.30, einem Zweig ohne Support. |
| Plugin-lastige Websites | Unsere Einschätzung, kein Befund aus der Berichterstattung: Jedes Plugin ist ein weiterer Maintainer, der bald einen Fix liefert – oder auch nicht. |
Unsere Meinung: Kaufen Sie wegen dieser Meldung keine neue Security-Suite. Den Betroffenen in diesen Geschichten fehlte kein Produkt. Sie betrieben einen nicht mehr unterstützten PHP-Zweig, warteten auf einen Hersteller ohne Patch-Termin oder hatten niemanden, der das Advisory las. Die günstigsten Abwehrmaßnahmen sind langweilig, und die lohnendste ist, binnen einer Stunde zu wissen, ob ein Advisory auf Sie zutrifft.
Wenn Sie eine Website betreiben, tun Sie zuerst das
Eine Frage würden wir allem anderen voranstellen: Welche PHP-Version läuft auf meiner Website, und wer patcht sie? Die meisten kleinen Website-Betreiber können das nicht beantworten, ohne jemanden zu fragen. Arbeiten Sie danach diese Liste ab.
- Finden Sie Ihre PHP-Version im Hosting-Panel heraus oder fragen Sie Ihren Hoster. Unterstützte Zweige bekamen Fixes in 8.5.12, 8.4.27, 8.3.36 und 8.2.35, und laut TechCrunch gibt es für 8.1 und älter keine Patches mehr.
- Bei WordPress lautet die Aussage des CMS, dass dies keine WordPress-Lücke ist. Sie patchen den Server und arbeiten mit Ihrem Hoster zusammen. Schreiben Sie ihm also eine E-Mail und bitten Sie um eine schriftliche Antwort.
- Wenn Sie jetzt nicht patchen können, nehmen Sie die Website vom Netz, bis es geht. Das ist die Empfehlung der NSA, und dagegen lässt sich schwer argumentieren, wenn die Alternative ein übernommener Server ist.
- Setzen Sie
session.upload_progress.enabled=0, wenn Sie auf Upload-Fortschrittsbalken verzichten können. PHP nannte das als Gegenmaßnahme für CVE-2026-109619 und erneut für ein drittes Advisory mit geringerem Risiko, CVE-2026-115560, für das es noch keinen Notfall-Fix gibt (The Hacker News). - Prüfen Sie nach dem Patchen die Logs auf Ausnutzung, beginnend mindestens eine Woche vor Erscheinen der Fixes, denn Amazons Honeypots protokollierten einen Versuch vier Tage vor der Veröffentlichung.
- Listen Sie jedes Gerät in Ihrem Netzwerk auf, das im Hintergrund PHP laufen lassen könnte, etwa eine Firewall oder ein NAS, und fragen Sie jeden Hersteller nach seinem Patch-Termin.
Wenn Sie Software schreiben statt hosten, warten Sie nicht auf Carbon. Scanner, die Sie heute schon nutzen können, behandeln wir in unserem Beitrag was KI-Schwachstellenscanner finden und übersehen, und der Beitrag die besten KI-Tools für Code-Reviews vergleicht Reviewer wie CodeRabbit und Snyk Code. Planen Sie Zeit für die Triage ein, denn der erste Lauf liefert einen Haufen Funde, und OpenAIs eigenes Programm erklärt, warum. Jedes ToolRank-Ranking für KI-Cybersecurity-Tools und das Ranking für Code-Review und Testing eignen sich zum Vergleichen, und KI-Tools für Security-Analysten richtet sich an alle, die diese Arbeit hauptberuflich machen.
Bewerten Sie sich unten selbst. Bei weniger als fünf Punkten sollte Ihre erste Stunde den Punkten mit zwei Punkten gehören.
Was wir beobachten
Drei Dinge. Ob Google Carbon über die Fairwind-Partner hinaus öffnet und zu welchem Preis, sobald der Einführungstarif endet. Ob Anthropic das Modell hinter seinen Ketten benennt oder ausliefert, denn eine Fähigkeit, die nur wenige geprüfte Teams haben, steht Verteidigern und Angreifern nicht gleichermaßen zur Verfügung. Und woher der erste PHP2Shell-Angreifer rechtzeitig Bescheid wusste, worauf es noch keine Antwort gibt.
Der nächste Fix, auf den Sie achten sollten, betrifft PHPs drittes Advisory, CVE-2026-115560, das laut PHP mit der nächsten regulären Release kommt. Lesen Sie die Release Notes am Tag des Erscheinens und prüfen Sie die Version Ihrer Website noch einmal.