Wenn es die Programmiersprache in die Tagesschau schafft: Anatomie des PHP2Shell-Bebens
Die Nachricht erreichte mich im Halbschlaf auf dem Sofa. Eine PHP-Sicherheitslücke hatte es bis in die Tagesschau geschafft – und irgendwo im Netz lief noch eine WordPress-Installation unter meiner Obhut. Wenn ein Programmierfehler zwischen Weltpolitik und Wetterbericht auftaucht, ist die Schonfrist vorbei. Also runter vom Sofa und ab vor den Rechner.
In der Szene hatte das Biest längst einen griffigen Spitznamen: PHP2Shell. Dahinter verbargen sich gleich zwei hochgradig gefährliche Lücken (CVE-2026-109618 und CVE-2026-109619), die Angreifern das erlauben, wovor jeder Systemadministrator nachts schweißgebadet aufwacht: Remote Code Execution – das Ausführen fremder Befehle aus der Ferne, ohne Passwort, ohne Vorwarnung. [1]
Die IT-Welt misst solche Einschläge mit dem Industriestandard CVSS (aktuell in der Version 4.0). [2] Man kann sich das vorstellen wie die Richterskala bei Erdbeben, nur dass bei 10,0 Schluss ist. Während Werte zwischen 0,1 und 3,9 ein leichtes Grummeln beschreiben, das kaum Schaden anrichtet, schlug das Seismometer bei PHP2Shell mit 9,2 aus. [1] Im Klartext: kritisch. Sofortiger Handlungsbedarf.
Das Tückische an PHP2Shell ist, dass der Fehler nicht in irgendeiner schlampig programmierten Erweiterung steckt, sondern tief im Maschinenraum der Programmiersprache selbst lebt. Wer dachte, er könne das Problem im Halbschlaf mit einem bequemen Klick auf den „WordPress aktualisieren“-Button erledigen, sah sich getäuscht. Hier musste ans Fundament herangegangen werden. Rund um den Planeten saßen in dieser Nacht müde Admins vor ihren Bildschirmen. Glücklich war, wer den Ernstfall schon einmal geprobt hatte und wusste, welche Handgriffe sitzen müssen. Allen anderen fiel die fehlende Worst-Case-Planung jetzt ungebremst auf die Füße.
Meine WordPress-Installation lag bei AWS Lightsail. Damals musste es schnell und einfach gehen, also hatte ich ein vorkonfiguriertes Bitnami-Paket gewählt: WordPress samt Datenbank, fertig installiert, ein Klick, läuft. Ich war begeistert von der Geschwindigkeit meines spontanen Deployments. In dieser Nacht verflog die Begeisterung. Bitnami-Server sind Wegwerfware, ein PHP-Update im laufenden Betrieb ist nicht vorgesehen. Die Idee ist, einen neuen Server aufzusetzen und dann das Backup einzuspielen, das man hoffentlich gut gepflegt und geprobt griffbereit hat. Ein Schicksal, das ich vermutlich mit vielen teile, die sich für ein paar Dollar im Monat einen Server gönnen. Schnell aufgesetzt heißt eben nicht schnell geflickt.
Das vergessene Fundament des Internets
Um die Dimension von PHP2Shell zu begreifen, muss man sich von einem verbreiteten Irrtum der Tech-Branche verabschieden. Auf Konferenzen reden zwar alle nur noch über KI, moderne Cloud-Architekturen und hippe Sprachen wie Rust oder Python (Letztere übrigens vier Jahre älter als PHP) – doch das reale Internet wird im Maschinenraum immer noch von einem unscheinbaren Arbeitstier am Laufen gehalten: PHP.
Rund 70 Prozent aller Websites weltweit basieren auf dieser Sprache. [3] PHP werkelt in großen wie in kleinen Projekten: Content-Management-Systeme wie TYPO3, Joomla und WordPress laufen ebenso darauf wie Online-Shops à la Shopware, Lernplattformen wie Moodle oder private Cloud-Speicher wie Nextcloud. Und weil der Fehler bis zu PHP 5.4 aus dem Jahr 2012 zurückreicht, ist praktisch der gesamte Bestand verwundbar. [1]
Besonders bitter wird es, wenn man sich den Zustand dieser Serverlandschaft ansieht. Von den öffentlich sichtbaren PHP-Servern liefen laut der Sicherheitsfirma Flare 73 Prozent auf Versionszweigen, für die es offiziell längst keine Sicherheitsupdates mehr gibt. Und 24 Stunden nach dem Patch-Release meldeten über 99 Prozent noch immer eine ungepatchte Version. [4] Das sind Millionen digitaler Untoter: Websites, die vor Jahren einmal eingerichtet wurden, brav vor sich hin schnurren und um die sich niemand mehr kümmert. Für diese Systeme gibt es keinen schnellen Rettungsanker.
Dazu kommt eine unsichtbare Flanke, an die im ersten Moment kaum jemand denkt: PHP steckt nicht nur hinter klassischen Webseiten. Es werkelt auch versteckt in den Administrationsoberflächen von Netzwerkspeichern (NAS) und professionellen Firewalls. Synology und QNAP haben betroffene Produkte bestätigt, bei Palo Alto Networks steckt die Lücke in der Verwaltungsoberfläche sämtlicher PAN-OS-Versionen. [5] Wer glaubt, er habe gar keinen Webserver im Betrieb, hat die verwundbare Sprache oft längst als blinden Passagier im eigenen Serverschrank stehen.
Ein menschliches Versagen – aufgedeckt von Maschinen
Wer hat diese Zeitbombe überhaupt gefunden? Die ehrliche Antwort ist schmerzhaft: Menschen haben sie gesehen. Mehrfach. Schon im Juli 2004 warnte der deutsche Sicherheitsforscher Stefan Esser, damals selbst PHP-Kernentwickler, dass Angreifer das Speicherlimit von PHP an Stellen auslösen können, an denen ein Abbruch gefährlich ist. [6] 2006 verließ er frustriert das PHP-Sicherheitsteam. 2020 folgte ein Bug-Report, der versandete. 2024 ein Audit, das die Ausnutzbarkeit nicht beweisen konnte. Die PHP Foundation spricht heute ungewöhnlich offen von einem „strukturellen Versagen“. [7] Man könnte auch sagen, die künstliche Intelligenz ist über die analoge Blödheit gestolpert.
Dass der Fehler im Sommer 2026 schließlich doch geknackt wurde, war kein Triumph menschlicher Geduld, sondern das Ergebnis einer KI-Materialschlacht. Gleich drei Teams meldeten die Lücken unabhängig voneinander an PHP: [6]
Zuerst war Calif da, eine Sicherheitsfirma, die im Rahmen von OpenAIs Initiative Patch the Planet gezielt PHP unter die Lupe nahm. Ihr Forscher Ryan Austin spürte die Lücke mithilfe von OpenAIs Spezialmodell GPT-5.6 Sol auf und meldete sie am 11. August. [8] Ironischerweise war bei Calif auch Stefan Esser beteiligt, ausgerechnet der Mann, der 22 Jahre zuvor gewarnt hatte.
Dreizehn Tage später folgte Wiz Research, die Forschungsabteilung des Sicherheits-Startups Wiz, das im März 2026 für die Rekordsumme von 32 Milliarden Dollar von Google geschluckt worden war. [9] Wiz arbeitete mit dem hauseigenen KI-Werkzeug Wiz Atlas, mit GPT-5.6 Sol und mit einer noch unveröffentlichten Vorabversion von Googles Gemini 4. [10] Nach eigener Aussage schaffte ein einzelner Forscher so in einer Woche, wofür früher ein Weltklasse-Team Monate gebraucht hätte.
Als Dritter meldete sich am 18. September OpenAI selbst. Das hauseigene Codex-Security-Team fand weitere Angriffswege, und Amy Burnett aus diesem Team wird heute auf beiden CVE-Einträgen als Mitentdeckung genannt. [6] Der Hersteller, der Calif das Werkzeug geliefert hatte, grub also gleich selbst mit. Wer die Schaufeln verteilt, steht eben auch mit im Loch.
Chronologie eines Kontrollverlusts
Eigentlich sollte die Welt erst am 22. Oktober geordnet von dem Problem erfahren, zeitgleich mit den rettenden Patches. Doch der Zeitplan kollabierte im Stundentakt. Zuerst brach ein inzwischen gelöschter Beitrag auf der Plattform Hacker News das Stillschweigen, kurz darauf stellte Calif versehentlich ein Beweisvideo des Angriffs ins Netz. [11] Man fasst es nicht: Ausgerechnet die absolute Sicherheits-Elite stolpert über den eigenen Veröffentlichen-Button. Den Entwicklern blieb nichts anderes übrig, als die Notbremse zu ziehen und die Reparatur-Updates einen Tag früher als geplant auf den Markt zu werfen.
Doch das wirklich Beunruhigende kam erst danach ans Licht. Amazon wertete die Protokolle seiner Honeypots aus – absichtlich verwundbarer Köder-Server – und fand den ersten Angriffsversuch bereits am 17. Oktober. [12] Vier Tage vor dem Patch, drei Tage vor den ersten Leaks. Irgendjemand da draußen wusste schon Bescheid – über ein Leck im Embargo (der vereinbarten Schweigefrist bis zur Veröffentlichung) oder eigene Forschung, vielleicht mit denselben KI-Methoden wie die Verteidiger. Man riecht förmlich den frischen Humus für die nächsten Verschwörungstheorien.
Nach der Veröffentlichung brach schließlich der Damm. Um 13:34 Uhr UTC landeten die Fixes auf GitHub, um 14:38 Uhr registrierten die Sensoren der Firma ELLIO den ersten Ladeversuch für ein Mirai-Botnetz. 64 Minuten. [13] Cloudflare-Chef Matthew Prince konnte in Echtzeit zusehen, wie die Angriffswelle von Tausenden über Hunderttausende bis in die Millionen schwoll. [14] Ein Beweis für KI-gestütztes Reverse Engineering sind die 64 Minuten allerdings nicht: Die Angreifer hatten CVE-Nummern, Beweisvideo und Vorwissen schon vor dem Patch in der Hand.
Die Anatomie der Angreifer
Hinter diesem Dauerfeuer stehen längst keine einsamen Kapuzenpulli-Träger mehr, sondern Maschinen und eine arbeitsteilige Untergrund-Ökonomie:
Die lauten Plünderer: Botnetz-Betreiber versuchten, ungeschützte Server in Potassium einzubinden, eine Mirai-Variante für Überlastungsangriffe (DDoS). Bislang erfolglos: Laut Sophos haben die Angreifer Mühe, zuverlässige Exploits zu bauen. [15]
Die lautlosen Türöffner: Gefährlicher wäre, was man nicht sieht. Wiz hat gezeigt, dass die Lücke Passwörter, Tokens und API-Schlüssel direkt aus dem Arbeitsspeicher des Servers lesen kann. [10] Genau solche Zugänge sind die Ware der sogenannten Initial Access Broker, die gekaperte Server-Zugänge typischerweise an Erpresser-Gruppen weiterverkaufen. Ob sie bei PHP2Shell schon zugegriffen haben, weiß derzeit niemand.
Das digitale Fußvolk: Seit erste Proof-of-Concept-Skripte im Netz kursieren, probieren Trittbrettfahrer ihr Glück und verändern ihre Anfragen laufend, um die Firewalls von Cloudflare & Co. auszutricksen. [16]
Zur Entwarnung gibt es trotzdem keinen Anlass. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat die Lage mit Warnstufe 3 („Orange“) eingestuft und Betreibern geraten, ungepatchte Server im Zweifel vom Netz zu nehmen. [17] Erfolgreiche Einbrüche hat bislang aber weder das BSI noch die japanische Regierung bestätigt. [7]
Das Geschäftsmodell der Angst
Ich habe den Server noch in der Nacht heruntergefahren und ihn am nächsten Tag, nach Rücksprache mit den Kollegen, endgültig ins Nirvana verabschiedet. Gebraucht wurde er ohnehin nicht mehr. Einen der digitalen Untoten habe ich in dieser Nacht also selbst beerdigt. Vielleicht ist das der beste Seiteneffekt von PHP2Shell: Alte Server fliegen endlich auf den digitalen Schrottplatz. Wie ein kleiner Waldbrand, der das Gestrüpp ausräumt und Licht für Neues schafft. Der Spuk dieser Nacht ist vorbei. Was bleibt, ist ein mulmiges Gefühl – und eine merkwürdige Bilanz: Millionen Angriffsversuche, null bestätigte Einbrüche. Die Panik-Kurve war echt, die Katastrophe ist bisher ausgeblieben.
Ein Blick auf die Akteure lohnt sich. Wiz gehört zu Google und verkauft Cloud-Sicherheit. Cloudflare schützte seine Kunden schon Stunden vor der Veröffentlichung mit neuen Firewall-Regeln – ein Produkt, das das Unternehmen verkauft, und das nur den Datenverkehr schützt, der hindurchläuft. OpenAI stellt für eine Milliarde Dollar subventionierten Zugang zu den eigenen Modellen bereit, damit Betreiber kritischer Dienste ihre Lücken finden. [18] Die Firmen, die die Bomben finden, verkaufen auch die Schutzwesten.
Das folgt dem uralten Gesetz der Kryptografie: Kaum entwirft der eine einen neuen Verschlüsselungsalgorithmus, arbeitet der andere schon daran, ihn zu knacken. Neu ist nur, dass jetzt auf beiden Seiten Maschinen sitzen. Wir richten hochgezüchtete KI-Modelle aufeinander und rechtfertigen mit genau dieser Bedrohung den Bau immer neuer, milliardenschwerer Rechenzentren. Jedes Zeitalter hat nun mal sein eigenes Geschäftsmodell. Vielleicht überleben wir ja auch dieses.
Was tun? PHP auf eine der gepatchten Versionen aktualisieren: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 – und PHP danach neu starten. WordPress-, Plugin- oder Theme-Updates helfen nicht. Wer Shared Hosting nutzt, fragt beim Provider nach. NAS und Firewalls nicht vergessen. [1]
Quellen und Verweise
[1] BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws sowie die Releasenotes auf php.net
[3] W3Techs: Usage statistics of PHP for websites
[4] Dark Reading: Exposed to PHP2Shell? Cyber Experts Weigh in With Advice (Daten von Ox Security und Flare)
[5] TechRadar: PHP security issues could also threaten your NAS device; Help Net Security: What PHP2Shell means for Fortinet, Cisco and Palo Alto customers
[6] Capital & Compute: Who Found PHP2Shell? Calif, Wiz and OpenAI Timeline; zur Vorgeschichte: The 22-Year Road To PHP2Shell
[7] Decrypt: Internet safe again after PHP nightmare?
[9] Techzine: Google closes $32B Wiz deal
[10] Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities; zur Gemini-Vorabversion: t3n
[11] Il Sole 24 Ore: PHP2Shell: when a software vulnerability becomes a global emergency
[12] BleepingComputer: Amazon says PHP2Shell exploitation began 4 days before patches
[13] Trellix Research: PHP2Shell: Key info on CVE-2026-109618 and CVE-2026-109619 (ELLIO-Daten); Zeitpunkt der Fixes: HackerNoon
[14] The Next Web: Cloudflare sees millions of attempts to exploit critical PHP flaws
[15] The Hacker News: PHP2Shell Exploit Attempts Hit Millions; Cybersecurity Dive: PHP exploitation slower than expected
[16] BankInfoSecurity: Millions of Exploit Attempts Logged Against PHP Servers; iThome: Cloudflare zu WAF-Umgehungsversuchen
[17] ZDFheute: Gravierende Sicherheitslücke: Millionen Webseiten bedroht (BSI-Warnung BITS-H Nr. 2026-297981-1032)
[18] TechJack Solutions: AI Models Found Critical PHP Flaws Before Hackers Did; zur Cloudflare-WAF-Einordnung: HackerNoon