Vierzehn Jahre im Fundament: Was hinter PHP2Shell steckt

 

Warum eine Sicherheitslücke so alt sein kann wie das Smartphone-Zeitalter und trotzdem erst jetzt gefährlich wird

Seit gestern ist das Wort überall: PHP2Shell. Das BSI hat die Warnstufe 3 ausgerufen, Orange, also außerordentlich hohes Risiko. Das Klinikum Braunschweig hat seine Webseite vorsorglich vom Netz genommen, und in fast jedem Bericht taucht eine Zahl auf, die zum Nachdenken einlädt: Die Lücke soll 14 Jahre alt sein.

Mein erster Gedanke war, dass solche Zahlen gern etwas großzügig gerundet werden. Also habe ich nachgerechnet. Ergebnis vorweg: Die 14 Jahre stimmen. Aber sie bedeuten etwas anderes, als die Schlagzeile nahelegt.

Was eigentlich passiert ist

Hinter PHP2Shell stecken zwei Schwachstellen im Kern von PHP, geführt als CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9,2 von 10 Punkten bewertet. Ein Angreifer braucht weder ein Passwort noch die Mithilfe eines Nutzers. Ein paar präparierte Anfragen an den Webserver genügen, um dort eigenen Code auszuführen. Der Name ist bewusst an Log4Shell angelehnt, jene Java-Lücke, die Ende 2021 die halbe IT-Welt um ihre Weihnachtsruhe gebracht hat.

PHP ist dabei kein Nischenprodukt. Die Sprache steckt unter WordPress, Joomla, Drupal, Typo3, Moodle, Nextcloud und unzähligen Onlineshops. Wiz Research spricht von rund 70 Prozent aller Webseiten weltweit.

Eigentlich sollten die Updates am 22. Oktober kommen. Am 20. Oktober sickerten jedoch Details durch, die Veröffentlichung wurde auf den 21. Oktober um 16 Uhr deutscher Zeit vorgezogen. Cloudflare beobachtete die ersten Angriffe bereits am Vormittag, also Stunden bevor es überhaupt einen Patch gab. Die bereinigten Versionen heißen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Stimmen die 14 Jahre?

Ja. Der betroffene Code reicht laut den Sicherheitsforschern bis PHP 5.4 zurück. Diese Version erschien im März 2012. 2026 minus 2012 ergibt 14. Das passt auch technisch, denn ein Teil der Angriffskette läuft über eine Funktion namens Session Upload Progress, mit der ein Server den Fortschritt eines Datei-Uploads anzeigen kann. Genau diese Funktion kam mit PHP 5.4 neu hinzu.

Etwas unscharf ist die häufige Formulierung, betroffen seien alle Versionen seit PHP 5. Das BSI schreibt vorsichtig von „mindestens zurückgehend bis PHP 5“. PHP 5.0 stammt aber von 2004, dann wären wir bei 22 Jahren. Gemeint ist PHP 5.4.

Zur Einordnung: Als dieser Code geschrieben wurde, war ich noch nicht einmal in der Glasfaserbranche. Seitdem lag er unbemerkt auf Millionen Servern, wurde mit jeder neuen PHP-Version weitergereicht und hat alle Updates, Audits und Umzüge in die Cloud überstanden.

Vorhanden heißt nicht ausgenutzt

Hier liegt der entscheidende Unterschied. Dass ein Fehler 14 Jahre im Code steckt, heißt nicht, dass Angreifer ihn 14 Jahre lang benutzt haben. Dafür gibt es bislang keinen einzigen Beleg.

Die dokumentierte Geschichte beginnt im Sommer 2026. Am 1. August fand die Sicherheitsfirma Calif mehrere Wege zur Codeausführung, am 11. August meldete sie den ersten Fehler an das PHP-Team. Am 24. August folgte unabhängig davon Wiz Research. Danach lief, wie in solchen Fällen üblich, eine vertrauliche Abstimmung: Fehler bestätigen, Patches bauen, Distributionen und Hoster vorwarnen, gemeinsam veröffentlichen. Dass der Zeitplan am Ende durch ein Leck durcheinandergeriet, ändert nichts daran, dass das Verfahren im Grunde funktioniert hat.

Warum hat es so lange niemand gefunden? Weil die Fehler dort sitzen, wo kaum jemand hinschaut: in der Fehlerbehandlung. Wenn ein PHP-Prozess sein Speicherlimit überschreitet, bricht er die Anfrage hart ab. Dabei bleiben Daten halb angelegt zurück, und die Aufräumroutine stolpert anschließend über diesen Zustand. Im zweiten Fall hält PHP noch Verweise auf Speicher fest, der längst wieder freigegeben ist. Solche Pfade werden im Alltag fast nie durchlaufen und entsprechend selten getestet. Code, der nur im Ausnahmefall läuft, ist der Keller eines Hauses: Man weiß, dass er da ist, aber man geht nur hinunter, wenn es tropft.

Die Rolle der KI

Wiz schreibt offen, dass KI bei der Entdeckung geholfen hat, und auch OpenAI war an der koordinierten Veröffentlichung beteiligt. Manche Berichte machen daraus eine Gruselgeschichte nach dem Muster „Maschine findet Lücke“. Ich sehe das anders. Genau diese Werkzeuge haben einen Fehler aufgespürt, den 14 Jahre lang kein Mensch gefunden hat, und zwar zuerst auf der richtigen Seite. Dass dieselben Werkzeuge auch Angreifern zur Verfügung stehen, ist richtig. Gerade deshalb ist es gut, dass die Verteidiger sie konsequent einsetzen. Die Alternative wäre nicht, dass der Fehler verborgen bleibt, sondern dass ihn irgendwann jemand findet, der es niemandem erzählt.

Keine Ausnahme, sondern die Regel

Wer die Geschichte der großen Sicherheitslücken kennt, den überraschen die 14 Jahre wenig. Heartbleed, der Fehler in OpenSSL von 2014, lag gut zwei Jahre im Code, bevor ihn jemand bemerkte. Log4Shell steckte seit 2013 in der Java-Bibliothek Log4j und wurde Ende 2021 entdeckt, nach rund acht Jahren. Shellshock, die Lücke in der Linux-Shell Bash, wurde 2014 gefunden und war seit 1989 vorhanden, also rund 25 Jahre.

Das Muster ist immer dasselbe. Software, auf der alles aufbaut, gilt als erprobt, weil sie seit Jahren läuft. Dass sie seit Jahren läuft, heißt aber nur, dass sie im Normalbetrieb funktioniert. Über die Ausnahmefälle sagt das nichts.

Aus dem Tiefbau kenne ich das zur Genüge. Man öffnet eine Straße und findet ein Kabel, das in keinem Bestandsplan auftaucht, oder eine Leitung, die laut Unterlagen seit Jahrzehnten stillgelegt ist und trotzdem Spannung führt. Niemand hat es versteckt. Es hat nur nie jemand nachgeschaut, weil es keinen Anlass gab. PHP2Shell ist genau so ein Fund, nur eben im Fundament des Internets.

Was das für Seitenbetreiber heißt

Die unangenehmste Erkenntnis: Beide Angriffswege greifen, bevor überhaupt Anwendungscode läuft. Ein vorbildlich aktuelles WordPress mit allen Plugin-Updates schützt also nicht, wenn darunter ein ungepatchtes PHP läuft. Wer einen eigenen Server betreibt, muss PHP selbst aktualisieren. Wer bei einem Hoster ist, sollte nachfragen, ob das schon geschehen ist. Viele Hoster haben vorab die Upload-Fortschrittsfunktion abgeschaltet, das ist eine sinnvolle Notbremse, aber nach Aussage des PHP-Teams kein Ersatz für das Update.

Heikel wird es bei alten Versionen. PHP 7.4, 8.0 und 8.1 werden offiziell nicht mehr gepflegt. Einige Anbieter haben für ihre Kunden trotzdem korrigierte Pakete gebaut, verlassen sollte man sich darauf aber nicht. Wer noch auf einer solchen Version sitzt, hat jetzt den deutlichsten Anlass seit Jahren, das zu ändern.

Mein eigener Blog läuft übrigens auf Blogger, also auf Googles Plattform. Da gibt es für mich keinen PHP-Server zu patchen. Das ist ausnahmsweise mal ein Vorteil davon, dass man nicht alles selbst in der Hand hat.

Fazit

Die Schlagzeile „14 Jahre alte Lücke“ ist korrekt, aber sie erzählt nur die halbe Geschichte. 14 Jahre lang lag der Fehler unbemerkt im Fundament. Gefährlich ist er erst seit dieser Woche, weil seit dieser Woche alle Bescheid wissen, die Verteidiger ebenso wie die Angreifer. Bei solchen Lücken gewinnt nicht, wer sie zuerst kennt, sondern wer zuerst handelt. Und dieses Rennen hat am Mittwochmorgen begonnen, Stunden bevor es überhaupt einen Patch gab.

Quellen

BSI: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit, Version 1.1 vom 21.10.2026

CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP

Sansec: PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)

Wiz Research: PHP2Shell – AI uncovers critical RCE vulnerabilities

Cyber Kendra: PHP2Shell: Critical PHP Flaws Allow Remote Code Execution

ZDFheute: Gravierende Sicherheitslücke: Millionen Webseiten bedroht, 21.10.2026