php2shell: Die PHP-Sicherheitslücken, die jede WordPress-Website jetzt schließen muss

Was php2shell ist

CVE-2026-109618 ist ein Fehler darin, wie PHP sich erholt, wenn einer Anfrage der Speicher ausgeht: PHP kann anhalten, während interne Anfragedaten erst teilweise eingerichtet sind, und das anschließende Aufräumen behandelt diese kaputten Daten als gültig. CVE-2026-109619 lässt internen Zustand einer Anfrage länger leben als ihren Speicher, sodass eine spätere Anfrage im selben PHP-Worker ihn nutzen kann. Das PHP-Projekt bewertet beide mit 9,2 auf der CVSS-v4.0-Skala, also kritisch.

Betroffen ist jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das PHP-Projekt das Risiko bei mod_php ein, weil es dort einen funktionierenden Exploit gibt, bei dem eine einzige Anfrage ohne Anmeldung den Angriff auslöst, bevor überhaupt Anwendungscode läuft. Sicherheitsforscher berichten, dass Proof-of-Concept-Code bereits öffentlich ist – rechne mit automatisierten Angriffen auf jede PHP-Website.

Welche PHP-Versionen die Lücken schließen

Für jeden unterstützten PHP-Zweig gibt es eine Version, die beide Lücken schließt (siehe Tabelle). PHP 8.2 erreicht am 31. Dezember 2026 sein Lebensende und bekommt danach keine Sicherheitsupdates mehr. Wenn du ohnehin aktualisierst, ersparst du dir mit 8.3 oder neuer ein zweites Upgrade.

PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Einige Linux-Distributionen und Anbieter mit Langzeit-Support liefern zurückportierte Korrekturen, und das PHP-Sicherheitsteam hat minimale Quellcode-Backports für 7.4, 8.0 und 8.1 für alle veröffentlicht, die PHP selbst kompilieren. Für alle anderen heißt die Antwort: auf eine korrigierte Version aktualisieren.

Warum WordPress-Updates das nicht beheben

WordPress, seine Plugins und Themes sind in PHP geschrieben, aber PHP selbst ist auf dem Server installiert. Automatische Updates, die Aktualisierungen-Seite und Sicherheits-Plugins können es nicht ändern. Bei Managed- oder Shared-Hosting aktualisiert dein Hoster PHP; auf deinem eigenen Server kommt es aus den Paketen deines Betriebssystems oder von dort, wo du PHP installiert hast.

So prüfst du deine Website

Öffne in WordPress Werkzeuge → Website-Zustand → Bericht und klappe Server auf: Dort steht die PHP-Version. Liegt sie unter der korrigierten Version ihres Zweigs, ist die Website angreifbar.

Ein Haken: Wenn dein PHP aus einer Linux-Distribution stammt (Debian, Ubuntu, RHEL, AlmaLinux und andere), wird die Korrektur oft zurückportiert, ohne die Versionsnummer zu ändern. Eine Version wie 8.2.7-1~deb12u1 kann bereits gepatcht sein. Prüfe den Sicherheitshinweis deiner Distribution zu CVE-2026-109618 und CVE-2026-109619 oder frag deinen Hoster, welchen Build du hast.

Verwaltet dein Hoster PHP, sieh auf seiner Statusseite nach oder frag direkt, ob eine der korrigierten Versionen eingespielt ist. Betreibst du den Server selbst, mach ein Backup, installiere dann die aktualisierten Pakete deiner Distribution oder deines Anbieters und starte PHP neu.

Wenn du heute nicht aktualisieren kannst

Das PHP-Projekt stellt klar, dass nur ein Update die Lücken vollständig schließt. Sein Advisory nennt Einstellungen, die bestimmte Angriffswege einengen, bis das Update eingeplant ist. Übernimm sie genau so, wie sie dort stehen, in der php.ini oder der Serverkonfiguration statt per ini_set() oder .user.ini, und starte jeden PHP-Worker neu.

Für CVE-2026-109619 ist die wichtigste Einstellung session.upload_progress.enabled=0. Für CVE-2026-109618 empfiehlt das Advisory memory_limit=-1, so gesetzt, dass Anwendungen es nicht überschreiben können, zusammen mit einem niedrigen post_max_size und einem Container- oder cgroup-Speicherlimit als Sicherheitsnetz. Lies das Advisory, bevor du Speichergrenzen änderst: memory_limit=-1 hebt PHPs eigene Speichergrenze auf, deshalb gehört eine äußere Grenze dazu.

Vorsicht bei schnellen Lösungen aus Foren und sozialen Medien, etwa Edge-Skripten, die versprechen, den Angriff zu blockieren. Bestenfalls verringern sie das Risiko, und Code eines unbekannten Autors, der jeden Upload auf deine Website mitliest, ist selbst ein Risiko. Die Lösung ist, PHP zu aktualisieren.

Wie Relvato es meldet

Relvatos Schwachstellen-Monitor liest über das Relvato-Plugin die PHP-Version, auf der eine WordPress-Website läuft, und meldet php2shell als kritischen Befund mit der Version, auf die du aktualisieren solltest. Auf einer Website ohne Plugin meldet es der Exposure-Scan, wenn der Server eine angreifbare PHP-Version im X-Powered-By-Header verrät – und empfiehlt, diesen Header auszublenden.

Hat dein Hoster einen Distributions-Build gepatcht, ohne die Versionsnummer zu ändern, lass es dir bestätigen und ignoriere den Befund: Er bleibt auch bei späteren Scans ignoriert.