php2shell: was am 21. Oktober 2026 passiert ist
Mittwoch, 15:30 Uhr. Das PHP-Projekt veröffentlicht vier neue Versionen und schließt damit zwei Lücken, die unter dem Namen php2shell bekannt gemacht wurden. Beide mit einem CVSS Score von 9.2 von 10 Punkten bewertet, beide ohne Zugangsdaten ausnutzbar, und betroffen ist nach Angaben des PHP-Teams jede Version seit PHP 5.
Für WordPress-Betreiber ist dieser Fall besonders unangenehm, weil die übliche Reaktion nichts ausrichtet. Diese PHP-Sicherheitslücke steckt nicht in WordPress, nicht in einem Plugin und nicht im Theme, sondern in der Sprache, auf der das alles läuft.
WordPress war das Vorzeige-Ziel der Forscher
Das ist bei php2shell kein theoretisches Risiko. Die Entdecker haben die Codeausführung ohne Anmeldung ausgerechnet an WordPress demonstriert – dazu an Drupal und Joomla, jeweils mit den damals aktuellen offiziellen Container-Abbildern. Die Demonstrationsvideos liegen öffentlich auf der Projektseite.
Wichtig dabei: Angreifbar war nicht eine Lücke in WordPress. WordPress diente nur als typische Anwendung, um zu zeigen, dass eine ganz normale Installation reicht. Rund 70 % aller Websites laufen auf PHP – WordPress ist davon der größte Einzelposten.
Zwei Lücken, beide mit einem CVSS Score von 9.2 von 10
Nicht nur Codeausführung – auch Passwörter und Tokens
Der zweite, leisere Teil von php2shell: Über dieselben Lücken lässt sich der Arbeitsspeicher des PHP-Prozesses auslesen. Darin liegen Passwörter, Sitzungs-Tokens, API-Schlüssel und Zertifikate – auch aus den Anfragen anderer Besucher. Das funktioniert, ohne dass überhaupt Code eingeschleust wird.
Praktische Folge für die Aufarbeitung: Ein Malware-Scan findet davon nichts, weil nichts eingeschleust wurde. Wer eine betroffene Installation länger ungepatcht am Netz hatte, sollte deshalb nicht nur nach Schadcode suchen, sondern auch Zugangsdaten und Schlüssel wechseln.
Warum ein WordPress-Update hier nichts ausrichtet
WordPress-Sicherheit wird meistens auf drei Dinge reduziert: Core aktuell, Plugins aktuell, Theme aktuell. Das ist richtig und deckt den Großteil der Vorfälle ab, die wir in der Praxis sehen. Hier nicht.
Die Lücke sitzt unter WordPress. Der PHP-Interpreter verarbeitet die Anfrage, bevor die erste Zeile WordPress-Code läuft. Ein Plugin-Update ändert daran nichts, und ein Security-Plugin kann es auch nicht abfangen – selbst eine sorgfältige Plugin-Prüfung hilft an dieser Stelle nicht.
21 Minuten – unsere Zeitleiste
Die Vorwarnung des PHP-Security-Teams kam einige Tage vorher. Diese Vorwarnungen lesen wir, und wir planen danach – auch wenn der Fix dann eine halbe Stunde früher kam als angekündigt.
| Zeit | Was passiert ist |
|---|---|
| 15:30 | Der Fix wird auf php.net bekannt gegeben (für 16:00 Uhr angekündigt) |
| 15:37 | Ondřej Surý hat die ersten Pakete gebaut |
| 15:51 | Die offiziellen Patches sind bei uns durchgelaufen (8.2 bis 8.5) |
| danach | Die zurückportierten Pakete für die alten Zweige bis PHP 5.6 |
Zum Merken:
Die 21 Minuten gelten für die offiziell unterstützten Zweige. Dass es so schnell ging, ist kein Glück: Bei uns muss niemand suchen, welche Website auf welcher PHP-Version steht. Die Arbeit dafür passiert in den Monaten davor, nicht am Tag der Lücke.
Wen wir patchen können – und wen nicht
Diese Unterscheidung spielt im Alltag selten eine Rolle. An einem Tag wie diesem entscheidet sie alles. Die PHP-Version gehört zum Server, nicht zur Website – wir können sie nur dort aktualisieren, wo wir auch den Server betreiben.
Wir haben die von uns betreuten Websites nach der Patch-Runde durchgemessen. Das Ergebnis war eindeutig getrennt: Alles in unserem Hosting lief auf der neuen Version, die Instanzen auf fremden Servern häufig noch auf den veralteten Versionen von vorher.
Auch PHP 5.6 ist bei uns gepatcht
Beim PHP-Projekt endet die Pflege bei 8.2. Für 7.4, 8.0 und 8.1 gab es wegen der Schwere zusätzlich Quellcode-Backports, gedacht für Betreiber, die selbst kompilieren. Alles unterhalb von 7.4 geht dort leer aus – betroffen sind die Versionen trotzdem, bis zurück zu PHP 5.
Auf unseren Servern laufen die PHP-Pakete von Ondřej Surý, dem Debian-Maintainer für PHP. Er pflegt weit mehr Zweige als das Projekt selbst und hat die Fixes bis hinunter zu PHP 5.6 zurückportiert. Wir haben in seinem Repository nachgesehen, bevor wir das hier schreiben:
| PHP-Zweig | Paketversion mit dem Fix | Vom PHP-Projekt gepflegt |
|---|---|---|
| 8.5 | 8.5.12 | ja |
| 8.4 | 8.4.27 | ja |
| 8.3 | 8.3.36 | ja, bis Ende 2027 |
| 8.2 | 8.2.35 | ja, bis 31.12.2026 |
| 8.1 | 8.1.34-9 | nein |
| 8.0 | 8.0.30-25 | nein |
| 7.4 | 7.4.33-31 | nein |
| 7.0 bis 7.3 | 7.0.33-92 bis 7.3.33-35 | nein |
| 5.6 | 5.6.40-104 | nein |
Alle elf Zweige tragen das Build-Datum vom 21. Oktober 2026.
Was Sie jetzt prüfen sollten
Läuft die Seite über Cloudflare, gibt es dort seit dem Bekanntwerden Firewall-Regeln gegen die bekannten Angriffswege – auch im kostenlosen Tarif. Das überbrückt Stunden, bis der Hoster patcht, und ersetzt das Update nicht. Eine ausführliche Einordnung steht bei heise security, die Advisories im Archiv des PHP-Projekts. Was in unserer Wartung enthalten ist, steht auf der Seite Leistungen.
Fazit:
php2shell lässt sich nicht im WordPress-Backend lösen – und WordPress war das Ziel, an dem die Forscher es vorgeführt haben. Die Lücke zeigt, warum Wartung und Hosting zusammengehören: Jemand muss die Vorwarnung lesen, binnen Minuten reagieren und wissen, auf welcher PHP-Version jede einzelne Website steht. Wo beides bei uns liegt, war das am selben Nachmittag erledigt. Wo das Hosting woanders liegt, können wir nur sagen, was zu tun ist.
