Am Mittwoch verschwanden in Deutschland reihenweise Behördenseiten aus dem Netz. Mainz schaltete sein Stadtportal ab, die Charité ihre Website, die Ruhr-Universität Bochum ließ ihre Seiten nur noch per VPN erreichen. Der Grund: zwei Lücken in PHP, die seit über einem Jahrzehnt im Code schlummerten und die niemand gefunden hatte – bis ein Forscherteam KI-Modelle darauf ansetzte. Und während die Admins patchten, meldete sich Google mit einem Hinweis, der banal klingt und es nicht ist.
Angefangen hat es am 19. August, und zwar unspektakulär. Vier Forscher von Wiz – Sagi Tzadik, Shir Tamari, Nir Ohfeld und Tomer Schwartz – stießen auf eine Unsauberkeit darin, wie PHP mit fatalen Fehlern umgeht, insbesondere mit Speichermangel. Läuft einem Worker mitten im Request der Speicher aus, bleibt interner Zustand in einem halbgaren Zwischenstadium zurück. Die Aufräumroutine behandelt diesen beschädigten Zustand anschließend, als wäre er gültig. Und der nächste Request, der auf demselben Worker landet, erbt das Chaos.
Einen Tag später hatten sie auf einer Drupal-Installation Code ausgeführt. Ohne Anmeldung. Wieder einen Tag später dasselbe auf WordPress. Am 24. August ging die Meldung an das PHP-Security-Team.
Vier Bugs, zwei CVEs, CVSS 9.2
Was daraus wurde, läuft seit Dienstag unter dem Namen PHP2Shell und verteilt sich auf zwei Einträge. CVE-2026-109618 steckt im Unserializer des Upload-Progress-Mechanismus, ein Use-after-free, über den sich Prozessspeicher auslesen und Code ausführen lässt – alles vor jeder Authentifizierung. CVE-2026-109619 kombiniert einen zweiten Use-after-free im Backtrace fataler Fehler mit einer Typverwechslung im OPcache. Beide bewertet mit CVSS 9.2.
Betroffen ist praktisch jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed. Am übelsten trifft es mod_php-Setups, wo ein einziger unauthentifizierter Request genügt – bevor auch nur eine Zeile Anwendungscode läuft. Die Fehler reichen zurück bis PHP 5.4. Jede Version des vergangenen Jahrzehnts trägt mindestens einen davon.
Die Zahl, die seitdem durch alle Meldungen geistert, lautet 70 Prozent. Sie stammt aus der Statistik, nach der PHP bei rund 69 Prozent aller Websites mit bekannter serverseitiger Sprache im Einsatz ist. Konkreter sind die Messungen: Der Sicherheitsforscher Silas Cutler schätzt über 1,3 Millionen aus dem Internet erreichbare Hosts als potenziell verwundbar ein, eine Shodan-Auswertung kommt auf über 1,9 Millionen exponierte PHP-Server.
Der Teil, der die Branche eigentlich beschäftigt
Interessanter als die Lücke selbst ist, wie sie gefunden wurde. Das Team setzte neben der hauseigenen Plattform zwei Frontier-Modelle ein, Gemini 4 Argon und GPT-5.6 Sol, und zwar nicht nur zum Aufspüren, sondern über die gesamte Kette: Exploit-Entwicklung, Anpassung an unterschiedliche Speicherlayouts, Fehleranalyse, am Ende sogar die Prüfung der Patches.
Genau das ist der Punkt. Die Forscher schreiben in ihrer Veröffentlichung, die Bugs seien seit über zehn Jahren da gewesen, aber ihre Ausnutzung habe eine derart komplexe Kette vorausgesetzt, dass sie praktisch unerreichbar blieb. Die Modelle hätten diese Hürde massiv gesenkt. Ein einzelner Forscher habe in einer Woche geschafft, wofür ein Weltklasse-Team Monate gebraucht hätte.
Man kann das als Erfolgsgeschichte der defensiven Sicherheitsforschung lesen. Man kann es auch anders lesen: Wenn die Hürde für diese Art von Angriff gefallen ist, ist sie für alle gefallen.
Jemand war vier Tage vor der Veröffentlichung da
Und offenbar war tatsächlich jemand schneller. Die Honeypots von Amazon registrierten bereits am 17. Oktober einen Ausnutzungsversuch – vier Tage vor der öffentlichen Bekanntgabe, mitten in der Sperrfrist, über eine IP eines kommerziellen Anonymisierungsdienstes. Wie der Angreifer an die Details kam, ist unklar. Amazons Empfehlung an alle, die jetzt ihre Logs durchsehen, lautet entsprechend: nicht ab dem Veröffentlichungsdatum suchen, sondern mindestens ab dem 17. Oktober.
Auch der Zeitplan der Veröffentlichung geriet unter Druck. Die CVE-Nummern sickerten vorab durch, woraufhin das PHP-Team seine Releases um einen Tag vorzog und am 21. Oktober um 14 Uhr UTC veröffentlichte. Gepatcht sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4 bis 8.1 existieren nur minimale Backports für Leute, die selbst kompilieren. Für alles ab PHP 7.3 abwärts gibt es nichts mehr.
In Deutschland reagierten die ersten Einrichtungen, bevor die Updates überall ankamen. Die Landeshauptstadt Mainz nahm nach einer Bundeswarnung mehrere Online-Dienste und das Portal mainz.de vom Netz, erreichbar blieben die Ämter per Telefon und E-Mail. Die Berliner Charité schaltete ihre Website ab, die Ruhr-Universität Bochum machte ihre Seiten bis zum Folgetag nur noch aus dem Uni-Netz oder per VPN zugänglich. Das CERT des Bundes stufte die Lage als akuten Notfall ein. CERT-EU riet in seinem Advisory dazu, aus dem Internet erreichbare Anwendungen zu isolieren, bis der Patch eingespielt und überprüft ist.
Wer nicht sofort patchen kann, hat nur Notbehelfe: memory_limit auf -1 und nicht überschreibbar, session.upload_progress.enabled auf 0, unter PHP 8.5 zusätzlich fatal_error_backtraces auf 0 – danach sämtliche Worker neu starten. Cloudflare hat WAF-Regeln für bekannte Angriffswege ausgerollt, auch für Gratis-Accounts, bezeichnet sie aber selbst als Überbrückung. Ein vollständiger Schutz ist keine dieser Maßnahmen.
Und dann meldete sich Google
Mitten in diese Lage hinein, am Dienstagvormittag, setzte John Mueller von Google einen kurzen Beitrag auf Bluesky ab. Sein Hinweis klang nach Nebensache und war es nicht: Wer seine PHP-Seiten abschaltet, um Zeit für ungeplante Updates zu gewinnen, soll bitte einen HTTP-Status 503 ausliefern – statt Anfragen ins Timeout laufen zu lassen oder mit 404 oder 500 zu antworten.
Der Grund dahinter ist simpel. Ein 503 sagt dem Crawler: vorübergehend nicht verfügbar, komm später wieder. Ein 404 sagt: diese Seite gibt es nicht. Ein 500 sagt: hier ist etwas kaputt. Und ein Timeout sagt gar nichts, was in der Praxis am schlechtesten ist. Wer ein paar Tage mit 404 antwortet, riskiert, dass Seiten aus dem Index fallen – und das Zurückholen dauert deutlich länger als die Abschaltung selbst. Google hat dazu seit Jahren eine Anleitung für geplante Ausfallzeiten veröffentlicht; neu ist nur der Anlass.
Praktisch wichtig ist Muellers Zusatz: Der 503 muss nicht aus PHP kommen. Das ist bei dieser Lücke keine Spitzfindigkeit, sondern der Kern der Sache. Wenn PHP das Problem ist, kann PHP nicht die Lösung ausliefern. Der Statuscode lässt sich über den Webserver, über einen vorgelagerten CDN oder notfalls über eine umgebogene DNS-Auflösung setzen – ohne dass der verwundbare Interpreter dafür überhaupt anspringen muss.
Wer sich an 2021 erinnert fühlt, liegt richtig. Dieselbe Empfehlung gab Google damals während Log4Shell. Es scheint zum Muster zu gehören: Erst kommt die Lücke, dann die Abschaltungen, und dann die Erinnerung daran, dass auch eine Notabschaltung noch halbwegs sauber kommuniziert werden will.
Was bleibt
Zwei Dinge gehen in dieser Woche leicht unter.
Das eine ist die Frage, wer am 17. Oktober geklopft hat, und woher derjenige wusste, wo er klopfen muss. Die PHP Foundation erklärte zum Release, man habe keine funktionsfähigen Exploits identifiziert. Vier Tage vorher hatte sie offenbar jemand.
Das andere ist eine stille Verschiebung. Wenn ein Fehler zwölf Jahre ungefährlich war, weil ihn auszunutzen zu kompliziert erschien, und diese Komplexität plötzlich keine Hürde mehr darstellt, dann ändert sich nicht ein einzelner Patch-Zyklus, sondern die Rechnung dahinter. Ein großer Teil der installierten Software da draußen ist nicht sicher, weil sie geprüft wurde. Sie ist sicher, weil sich bisher niemand die Mühe gemacht hat.
Bis dahin: patchen, Logs ab dem 17. Oktober durchsehen – und falls doch abgeschaltet werden muss, bitte mit 503.
