PHP2Shell: Was WordPress-Betreiber jetzt tun müssen

PHP2Shell bezeichnet zwei kritische Sicherheitslücken in PHP selbst, veröffentlicht am 21. Oktober 2026 und mit CVSS 9.2 bewertet. Auf einer ungepatchten PHP-Laufzeitumgebung kann ein Angreifer ohne Benutzerkonto Code auf dem Server ausführen oder Arbeitsspeicher auslesen, in dem Passwörter, Session-Tokens und API-Schlüssel liegen. Die Forscher haben den Angriff an aktuellen WordPress-Installationen vorgeführt. Updates für WordPress, Ihr Theme oder Ihre Plugins beheben das Problem nicht: Aktualisiert werden muss die PHP-Version, auf der Ihre Website läuft.

Dieser Leitfaden erklärt, was PHP2Shell ist, wie Sie prüfen, ob Ihre Website betroffen ist, was Sie Ihren Hoster fragen sollten und was Sie tun können, wenn das Update nicht mehr heute möglich ist.

Was PHP2Shell ist

Wiz Research, OpenAI Codex Security und Calif haben in der PHP-Engine zwei verwandte Klassen von Speichersicherheitsfehlern gefunden:

• CVE-2026-109618, Speicherbeschädigung bei Speichermangel. Die Art, wie PHP mit erschöpftem Arbeitsspeicher umgeht, kann seinen internen Zustand beschädigen. Ein Angreifer kann das nutzen, um ohne Anmeldung Code als PHP-Webworker auszuführen.
• CVE-2026-109619, veralteter globaler Zustand über Anfragen hinweg. Daten aus einer Anfrage können bis in die nächste erhalten bleiben. Das führt zu einem Use-after-free, über den Speicher des Workers abfließen oder Code ausgeführt werden kann.

Weil der Fehler in PHP steckt, muss Ihr eigener Code keinen Fehler enthalten. Laut den Forschern kann schon eine „Hello World“-Seite auf einer betroffenen PHP-Version angreifbar sein. WordPress, Drupal und Joomla waren lediglich die Anwendungen, an denen sie eine Remote-Code-Ausführung ohne Anmeldung demonstriert haben. Das PHP-Team hat noch am selben Tag korrigierte Versionen veröffentlicht.

Für eine WordPress-Website zählen vor allem zwei Folgen:

1. Übernahme des Servers. Codeausführung als PHP-Worker bedeutet in der Regel, dass der Angreifer Dateien ändern, einen Administrator anlegen, eine Hintertür platzieren oder auf die Datenbank zugreifen kann.
2. Unbemerkter Datendiebstahl. Das Auslesen des Speichers funktioniert, ohne dass Schadcode ausgeführt wird, und hinterlässt daher womöglich kaum Spuren. Der Speicher eines stark ausgelasteten PHP-Workers kann Passwörter und Cookies anderer Besucher, Ihr Datenbankpasswort und API-Schlüssel enthalten.

Ist meine Website betroffen?

Fast sicher, es sei denn, Ihr PHP wurde am oder nach dem 21. Oktober 2026 aktualisiert. Die Forscher fanden betroffene Versionen bis zurück zu PHP 5.4. Dies sind die ersten korrigierten Versionen je unterstütztem Zweig:

PHP 8.1, 8.0 und alle 7.x-Versionen werden vom PHP-Projekt nicht mehr unterstützt und stehen nicht in dieser Tabelle. Läuft Ihre Website auf einer davon, gibt es keine korrigierte Version, die Sie installieren könnten: Sie müssen auf einen unterstützten Zweig wechseln.

Ihre genaue Version sehen Sie in WordPress unter Werkzeuge → Website-Zustand → Bericht, wenn Sie den Abschnitt Server aufklappen. Die Zeile „PHP-Version“ zeigt die vollständige Nummer, zum Beispiel 8.3.36. Die ersten beiden Teile (8.3) reichen nicht aus: Entscheidend ist die letzte Zahl.

So schließen Sie die Lücke

Die einzige vollständige Lösung ist eine gepatchte PHP-Laufzeitumgebung, gefolgt von einem Neustart.

1. Aktualisieren Sie PHP in jeder Laufzeitumgebung. Auf Ihrem eigenen Server installieren Sie die aktualisierten Pakete Ihrer Distribution, sobald sie erscheinen, oder das offizielle Release von php.net. Bei Managed- oder Shared-Hosting aktualisiert der Hoster PHP. Fragen Sie ihn direkt, ob Ihr Tarif bereits die korrigierte Version nutzt.
2. Starten Sie PHP neu. Ein neues PHP-Paket bewirkt nichts, solange die laufenden Prozesse nicht ersetzt sind. Starten Sie PHP-FPM, Apache mit mod_php und alle dauerhaft laufenden PHP-Worker neu.
3. Prüfen Sie das Ergebnis. Sehen Sie erneut in den Website-Zustand. Die PHP-Version muss jetzt mindestens der korrigierten Version Ihres Zweigs entsprechen.
4. Vergessen Sie die übrigen Laufzeitumgebungen nicht. Staging-Websites, eine zweite PHP-Version, die in Ihrem Hosting-Panel ausgewählt ist, das PHP für Cronjobs und WP-CLI sowie Container-Images zählen alle mit.

Wenn Sie ein Hosting-Panel mit PHP-Versionsauswahl nutzen, ist die Auswahl „8.3“ oder „8.4“ nur dann sicher, wenn der Hoster hinter dieser Bezeichnung bereits den gepatchten Build installiert hat. Der Website-Zustand zeigt Ihnen, was wirklich läuft.

Wenn Sie heute nicht updaten können

Die Forscher nennen vorübergehende Maßnahmen. Jede blockiert einige Angriffswege, keine blockiert alle, und manche können Ihre Website beeinträchtigen. Testen Sie deshalb zuerst:

• fatal_error_backtraces = 0, sofern Ihre PHP-Version das unterstützt.
• Senken Sie post_max_size und max_input_nesting_level so weit, wie Ihre Formulare und Uploads es zulassen, und setzen Sie session.upload_progress.enabled = 0, wenn nichts den Upload-Fortschritt nutzt.
• Lassen Sie PHP-FPM-Worker mit einem niedrigeren pm.max_requests häufiger erneuern (das kostet Leistung).
• memory_limit = -1 beseitigt den Weg über das Speicherlimit, auf den einige Angriffe angewiesen sind, überlässt die Speichererschöpfung aber dem Betriebssystem. Nutzen Sie es nur zusammen mit einem Limit auf Betriebssystemebene wie cgroup v2 memory.max, und ersetzen Sie es nie durch RLIMIT_AS oder RLIMIT_DATA, die laut dem PHP-Advisory denselben Fehler auslösen können.

Das Ausblenden von PHP-Fehlern (display_errors, error_reporting oder @) gehört nicht zu diesen Maßnahmen: Laut PHP-Projekt hilft es nicht.

Anbieter von Firewalls und CDNs haben Regeln für PHP2Shell veröffentlicht. Sie können das Risiko senken, doch die Forscher stellen klar, dass eine Schutzregel kein Ersatz für ein PHP-Update ist.

Anzeichen, auf die Sie achten sollten

Keine einzelne Logzeile beweist einen Angriff. Die Forscher nennen Signale, denen Sie nachgehen sollten: ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies in Antworten, seltsame Multipart-Anfragen, auf die Fehler wegen des Speicherlimits oder gehäufte HTTP-500-Antworten folgen, und PHP-Worker, die ohne erkennbaren Grund abstürzen oder neu starten. Fehlen diese Signale, beweist das nicht, dass Ihre Website sauber ist, denn das Auslesen des Speichers hinterlässt in den WordPress-Logs womöglich keine Spuren.

Sehen Sie diese Anzeichen, behandeln Sie die Lage als möglichen Sicherheitsvorfall. Unser Leitfaden zu einer gehackten WordPress-Website hilft bei den ersten Prüfungen. Weil ausgelesener Speicher Geheimnisse enthalten kann, ändern Sie nach dem Patchen das Datenbankpasswort, die Keys und Salts in wp-config.php und alle API-Schlüssel. Könnten personenbezogene Daten betroffen sein, beginnt die DSGVO-Frist zu laufen: Lesen Sie unseren Leitfaden zur Meldung einer Datenpanne in 72 Stunden.

Wo Sie anfangen

1. Öffnen Sie Werkzeuge → Website-Zustand → Bericht → Server und notieren Sie die genaue PHP-Version jeder Website, die Sie betreiben.
2. Vergleichen Sie sie mit der Tabelle oben. Alles unter der korrigierten Version oder auf PHP 8.1 und älter verlangt noch heute Handeln.
3. Aktualisieren Sie PHP oder fragen Sie Ihren Hoster nach der gepatchten Version, und stellen Sie dann sicher, dass PHP-FPM oder Apache neu gestartet wird.
4. Prüfen Sie den Website-Zustand erneut und bewahren Sie den Screenshot als Nachweis der Behebung auf.
5. Durchsuchen Sie Ihre Logs nach den oben genannten Anzeichen und tauschen Sie Geheimnisse aus, wenn Ihnen etwas verdächtig vorkommt.

Quellen: php2shell.com, Ankündigung der PHP Foundation, Wiz Research.