php2shell: kritische PHP-Sicherheitslücke in allen Versionen seit PHP 5

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Lücken geschlossen, die unter dem Namen php2shell veröffentlicht wurden. Diese PHP-Sicherheitslücke sitzt im Kern der Sprache, nicht in einer Anwendung – betroffen sind nach Angaben des PHP-Teams alle Versionen seit PHP 5. Beide Schwachstellen sind mit CVSS 9.2 bewertet und ohne Anmeldung ausnutzbar.

Die Veröffentlichung war laut heise ursprünglich für den 22. Oktober geplant und wurde wegen eines Leaks um einen Tag vorgezogen. Die Vorwarnung nannte dann 16 Uhr unserer Zeit, draußen war der Fix um 15:30 Uhr. Wer sich auf den angekündigten Termin verlassen hat, war also schon hinterher, als es losging.

Es sind zwei getrennte Schwachstellen mit unterschiedlichem Mechanismus:

• CVE-2026-109618, Speicherüberlauf beim Aufräumen – schlägt das konfigurierte Speicherlimit an, bricht PHP das Skript ab und soll die Reste wegräumen. Mit einem passend gebauten Upload oder geschickt verschachtelten Arrays kommt es dabei aus dem Tritt.
• CVE-2026-109619, zurückgebliebener Zustand in der Fehlerbehandlung – braucht mindestens zwei Anfragen. Die erste hinterlässt einen instabilen Zustand, die zweite nutzt ihn aus, bevor die normale Initialisierung ihn zurücksetzt.

Behoben sind beide in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Über php2shell lässt sich fremder Code im Benutzerkontext des Webservers ausführen – das ist der Teil, der die Schlagzeilen macht. Der zweite Teil ist leiser und in der Praxis oft unangenehmer: Dieselben Lücken erlauben es, den Arbeitsspeicher des PHP-Prozesses auszulesen. Darin liegen Passwörter, Sitzungs-Tokens, API-Schlüssel und Zertifikate – auch aus den Anfragen anderer Besucher.

Das ist aus zwei Gründen wichtig. Erstens reicht dieser Weg ohne jede Codeausführung, um an Zugangsdaten zu kommen. Zweitens hinterlässt er kaum Spuren: Werkzeuge, die nach eingeschleusten Dateien und ausgeführten Befehlen suchen, finden hier nichts. Wer eine betroffene Installation länger offen hatte, sollte deshalb nicht nur nach Schadcode suchen, sondern auch die hinterlegten Zugangsdaten und Schlüssel wechseln.

Drei Dinge kommen zusammen. Ein Angriff braucht keine Zugangsdaten. Er trifft nicht eine einzelne Anwendung, sondern die Ebene darunter – laut PHP-Projekt alle Installationen, die Webanfragen ausliefern, von PHP-FPM über Apache mit mod_php bis zu php-cgi und LiteSpeed. Und er greift, bevor überhaupt Anwendungscode läuft; selbst eine sauber programmierte Seite kann hier nichts dagegen tun.

Eine Einordnung gehört dazu: Ein einzelner Aufruf genügt nicht. Nach den Angaben der Entdecker braucht ein Angriff mehrere Tausend bis Zehntausend Anfragen, bis er trifft – zuverlässig genug für automatisierte Massenangriffe, aber nichts, was beim ersten Seitenaufruf passiert. Dass die Lücke aktiv ausgenutzt wird, ist bislang nicht bekannt. Bei einer Schwachstelle dieser Größenordnung ist das eine Momentaufnahme, keine Entwarnung.

Wer gar nicht sofort patchen kann, hat eine brauchbare Zwischenlösung, falls die Seite über Cloudflare läuft: Dort gibt es seit dem Bekanntwerden Firewall-Regeln gegen die bekannten Angriffswege, auch im kostenlosen Tarif. Das überbrückt allerdings auch eher Stunden als Wochen.

Unsere Zeitleiste von diesem Mittwoch:

Die 21 Minuten gelten für die offiziell unterstützten Zweige. Die alten Versionen haben etwas länger gebraucht, weil ihre Pakete erst gebaut werden mussten – entscheidend ist, dass sie überhaupt kommen. Jede Website in unserem Hosting läuft seit diesem Nachmittag auf gepatchtem PHP.

Hier ist eine Unterscheidung wichtig, die im Alltag selten eine Rolle spielt und an einem Tag wie diesem plötzlich alles entscheidet. Die PHP-Version gehört zum Server, nicht zur Website. Wir können sie nur dort aktualisieren, wo wir auch den Server betreiben.

• Website liegt in unserem Hosting – erledigt, ohne Ihr Zutun. Das gilt unabhängig davon, ob zusätzlich ein Wartungsvertrag besteht.
• Website liegt bei einem fremden Hoster, Wartung läuft über uns – wir halten WordPress, Plugins und Themes aktuell, aber an die PHP-Version kommen wir nicht heran. Die kann ausschließlich der Hoster aktualisieren.

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 noch auf dem Stand von vorher. Die betroffenen Kunden sprechen wir direkt an.

Das PHP-Projekt pflegt nur noch 8.2 und neuer. Für 7.4, 8.0 und 8.1 hat das Security-Team wegen der Schwere zusätzlich Quellcode-Backports bereitgestellt, gedacht für Betreiber, die selbst kompilieren. Alles unterhalb von 7.4 geht dort leer aus – und betroffen ist es trotzdem, bis zurück zu PHP 5.

Wir setzen auf unseren Servern die PHP-Pakete von Ondřej Surý ein, 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. Nachgesehen in seinem Paket-Repository:

Alle elf Zweige tragen das Build-Datum vom 21. Oktober 2026. Damit sind bei uns sämtliche PHP-Instanzen versorgt, auch die, auf denen aus guten Gründen noch eine ältere Anwendung läuft.

PHP steckt in mehr Geräten, als man beim Stichwort Website vermutet. Viele Netzwerkgeräte nutzen es für ihre Weboberfläche und sind damit genauso betroffen – nach der heise-Aufstellung unter anderem NAS-Systeme von Synology und QNAP, Firewalls wie pfSense und OPNsense, Router von DrayTek, ZyXEL, D-Link, TP-Link und Netgear sowie Security-Appliances von Citrix, Palo Alto und Ivanti.

Praktisch heißt das: Ein Gerät, dessen Verwaltungsoberfläche aus dem Internet erreichbar ist, gehört bei dieser Lücke auf die Liste der Angriffsfläche – nicht auf die der Schutzmaßnahmen. Und auch rein intern erreichbare Geräte sind nicht egal: Sie sind genau das, was jemand sucht, der sich im Netzwerk dauerhaft einnisten will.

Liegt Ihre Website in unserem Hosting, ist der Fall erledigt – Sie müssen nichts tun. Bei allen anderen Websites würden wir zwei Fragen an den Hoster stellen:

• Welche PHP-Version läuft, und ist sie aktualisiert? Gefragt sind 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 – oder bei einem älteren Zweig eine Paketversion vom 21. Oktober 2026 oder später.
• Wurden die Dienste danach neu gestartet? Das neue Paket wirkt erst, wenn Apache beziehungsweise PHP-FPM und alle lang laufenden PHP-Prozesse durchgestartet sind. Vorher bedient weiter der alte Interpreter.

Dazu die eigene Hardware: NAS, Firewall und Router auf Updates prüfen. Kommt auf die erste Frage keine klare Antwort oder dauert sie lange, ist das selbst schon eine Information. Die vollständigen Advisories stehen im News-Archiv des PHP-Projekts, eine ausführliche Einordnung bei heise security. Wenn Sie Hosting und WordPress-Wartung lieber aus einer Hand hätten, sprechen Sie uns gerne an.