PHP2Shell: Ist meine WordPress-Website gefährdet und was ist zu tun

Jede WordPress-Website, die auf PHP von php.net älter als 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 läuft, ist für PHP2Shell anfällig (Pakete von Linux-Distributionen haben eigene Versionsnummern, dazu unten mehr). Diese vier PHP-Versionen sind am 21. Oktober 2026 erschienen und schließen zwei kritische Lücken, über die sich ohne Anmeldung Code aus der Ferne ausführen lässt. Die Lücke steckt in PHP, deshalb beseitigt ein Update von WordPress, Theme oder Plugins sie nicht. PHP auf dem Server muss aktualisiert werden, oder Sie stellen sicher, dass Ihr Hoster das erledigt hat.

Die Meldung zu jedem der vier Releases auf php.net enthält denselben Satz:

Es gibt keine vollständigen Gegenmaßnahmen, das Update ist die einzige sichere Wahl.

(eigene Übersetzung, php.net, Release-Meldungen vom 21. Oktober 2026)

#Was ist PHP2Shell

PHP2Shell sind zwei Fehler in der PHP-Engine, die laut der Seite der Forscher von Calif, OpenAI und Wiz entdeckt wurden. Untersuchung und Beschreibung stammen von Ryan Austin von Calif, gefunden wurden die Fehler im Rahmen der Initiative Patch the Planet von OpenAI (Calif). Wiz Research hat eine eigene Analyse veröffentlicht (Wiz). Das PHP-Projekt führt sie als zwei Lücken:

Beide sind Speichersicherheitsfehler vom Typ Use-after-free in der Behandlung fataler Fehler durch PHP, einschließlich Speichermangel-Fehlern, und eine präparierte HTTP-Anfrage kann sie auslösen, bevor irgendein WordPress-Code ausgeführt wird. Die Einträge in der Datenbank GitHub Security Advisories für das Repository php-src wurden am 21. Oktober 2026 um 13:34 UTC veröffentlicht. Als betroffen nennen sie alle Versionen unter 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Laut der von Calif veröffentlichten Chronologie meldeten die Forscher den ersten Fehler am 11. August 2026 an das PHP-Projekt, am 15. August bestätigte PHP, dass ihr Machbarkeitsnachweis für die Codeausführung aus der Ferne funktioniert, und die korrigierten Versionen erschienen am 21. Oktober 2026 (Calif).

Einen Tag zuvor, am 20. Oktober, hatte das PHP-Sicherheitsteam das Release für den 21. Oktober um 14:00 UTC angekündigt und mitgeteilt, dass beide Lücken auf der Skala CVSS v4.0 mit 9.2 bewertet sind (php.net, Ankündigung vom 20. Oktober).

Gegen 16:05 Uhr MESZ (14:05 UTC) zeigte die Website von Wordfence nur eine Meldung: “Die Dienste von Wordfence sind vorübergehend nicht verfügbar, da wir Schutzmaßnahmen gegen die derzeit noch ungepatchte Lücke PHP2Shell umsetzen. Vielen Dank für Ihre Geduld.” (eigene Übersetzung, Website wordfence.com, Stand 21. Oktober 2026 gegen 16:05 Uhr MESZ). Bei unserer erneuten Prüfung um 17:16 Uhr MESZ (15:16 UTC) zeigte die Website weiterhin nur diese Meldung. Selbst ein Anbieter von Sicherheitslösungen für WordPress hat seine eigenen Dienste für diese Zeit abgeschaltet, um Schutzmaßnahmen einzuspielen.

Aus der Veröffentlichung von Wiz Research sind für Websitebetreiber drei Erkenntnisse relevant:

• betroffen sind PHP-Versionen bis zurück zu 5.4,
• in den Tests von Wiz funktionierte die Remote-Code-Ausführung ohne Authentifizierung auf dem Container-Image wordpress:latest sowie auf Drupal und Joomla,
• ein separater Fehler erlaubt es, einen Teil des Speichers des PHP-Prozesses auszulesen, in dem Passwörter, Authentifizierungstoken, API-Schlüssel und Zertifikate liegen können, selbst wenn die Anwendung überhaupt keine Session startet (session_start()).

Wiz weist außerdem darauf hin, dass es neben den vier beschriebenen Fehlern weitere Varianten desselben Problems gibt und die Korrektur des PHP-Projekts alle beseitigt (Wiz).

#Ist meine WordPress-Website anfällig

Ja, wenn sie auf einer PHP-Version läuft, die niedriger ist als das korrigierte Release ihres Zweigs. Laut php.net ist jede PHP-Installation gefährdet, die Webanfragen verarbeitet: PHP-FPM, Apache mit dem Modul mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko ordnet php.net Konfigurationen mit mod_php zu, für die ein vorgeführter Exploit existiert, der über eine nicht angemeldete Anfrage startet, bevor Anwendungscode läuft (php.net).

Die Version von WordPress, Theme und Plugins spielt hier keine Rolle, weil der Fehler im PHP-Interpreter liegt und automatische WordPress-Updates PHP auf dem Server nicht anfassen. Auch sauberer Code der Website schützt nicht: Laut Wiz kann selbst eine einfache Anwendung vom Typ “Hello World” auf einer anfälligen PHP-Version Ziel eines Angriffs sein. Ein Sicherheits-Plugin arbeitet innerhalb von WordPress, die Anfrage kann den Fehler aber auslösen, bevor WordPress geladen ist.

Ein WooCommerce-Shop hat in dieser Lage mehr zu verlieren als eine Firmenwebsite. In Datenbank und Konfiguration liegen Kundendaten, Bestellungen und Schlüssel für Zahlungsanbieter, und die Offenlegung des Prozessspeichers betrifft genau solche Geheimnisse.

Calif hat die Codeausführung aus der Ferne ohne Anmeldung unter WordPress 7.1.2 bestätigt, außerdem unter anderem unter Magento 2.4.9, phpMyAdmin 5.2.3 und WHMCS (Calif). Nach unserer Einschätzung ist ein phpMyAdmin oder ein Kundenpanel, das auf dem PHP desselben Servers läuft, auf dieselbe Weise angreifbar, deshalb braucht der Server das PHP-Update auch dann, wenn WordPress selbst nicht erreichbar ist.

Statische Websites liegen außerhalb der Reichweite dieser Lücke. Wird die Website zu HTML-Dateien generiert und führt der Server bei der Verarbeitung von Anfragen kein PHP aus, betrifft sie die Meldung auf php.net nicht, denn diese beschreibt PHP-Installationen, die Webanfragen verarbeiten.

#Wie Sie die PHP-Version Ihrer WordPress-Website prüfen

Der einfachste Weg führt über das WordPress-Dashboard:

1. Melden Sie sich als Administrator an.
2. Öffnen Sie Werkzeuge, Website-Zustand.
3. Wechseln Sie zum Reiter Bericht und klappen Sie den Abschnitt Server auf.
4. Lesen Sie die Zeile mit der PHP-Version ab.

Vergleichen Sie die Nummer mit der Tabelle:

Die Daten zur Unterstützung stammen aus der Tabelle der unterstützten Versionen auf php.net.

Die PHP-Version im Website-Zustand ist die Version, die die Website ausliefert. Das Hosting-Panel kann für die Kommandozeile oder für eine andere Domain im selben Konto eine andere Version anzeigen, maßgeblich ist daher der Wert aus WordPress.

Eine Ausnahme bilden Pakete aus Linux-Distributionen. Laut php.net haben Distributionen und Anbieter von LTS-Support die Korrekturen früher erhalten und veröffentlichen eigene Pakete (php.net). Eine Distribution portiert die Korrektur in ihre eigene PHP-Version zurück und behält ihre eigene Nummer. Ubuntu 24.04 LTS hat PHP mit dem Paket 8.3.6-0ubuntu0.24.04.13 korrigiert (USN-8948-1), eine gepatchte Website auf so einem Server zeigt im Website-Zustand also weiterhin 8.3.6. Debian 13 (trixie) hat php8.4 in Version 8.4.27-1~deb13u1 erhalten (DSA-6574-1), während der Security Tracker von Debian php8.2 in Debian 12 (bookworm) bei unserer Prüfung am 21. Oktober 2026 um 15:14 UTC noch als anfällig führte (Debian Security Tracker). Auf einem VPS mit PHP aus dem Repository der Distribution sagt die Versionsnummer allein nichts aus. Prüfen Sie in der Sicherheitsmeldung der Distribution oder im Changelog des Pakets, ob das Update die Korrekturen für CVE-2026-109618 und CVE-2026-109619 enthält, und fragen Sie beim Hosting den Hoster.

#Was tun, wenn der Hoster PHP noch nicht aktualisiert hat

Beim Shared Hosting übernimmt der Hoster das PHP-Update. Als Websitebetreiber haben Sie vier Möglichkeiten:

1. Version im Panel umstellen. Viele Hosting-Panels erlauben es, die PHP-Version pro Domain zu wählen. Steht eine Version mit Korrektur bereits in der Liste, stellen Sie die Website darauf um und prüfen Sie das Ergebnis im Website-Zustand.
2. Anfrage an den Hoster. Schreiben Sie dem technischen Support mit den Nummern CVE-2026-109618 und CVE-2026-109619 und fragen Sie, wann der Server PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder ein Paket mit diesen Korrekturen erhält.
3. Backup vor der Umstellung. Der Wechsel auf einen neueren PHP-Zweig kann ein altes Plugin oder Theme lahmlegen. Eine Kopie der Dateien und der Datenbank von vor der Umstellung verkürzt den Weg zurück zu einer funktionierenden Website.
4. Website bis zum Update vom Netz nehmen. Lässt sich PHP nicht schnell aktualisieren, nehmen Sie die Website vom Netz oder zeigen an ihrer Stelle eine statische Wartungsseite, die ohne PHP ausgeliefert wird. Unser Hinweis: Ein Wartungsmodus-Plugin in WordPress reicht nicht, weil die Anfrage trotzdem bei PHP ankommt. John Mueller von Google schrieb am 21. Oktober: “Wenn Sie PHP-Websites vom Netz nehmen, um Zeit für ungeplante Updates zu gewinnen, verwenden Sie HTTP 503, statt Antworten in einen Timeout, 404 oder 500 laufen zu lassen. Das geht außerhalb von PHP, per DNS-Umleitung an einen anderen Ort oder über ein CDN.” (eigene Übersetzung, John Mueller, Bluesky). Die Wartungsseite mit Status 503 kommt dann vom Webserver, vom CDN oder nach einer DNS-Umstellung von einem anderen Server, ohne PHP, denn eine Wartungsseite mit Status 200, Timeouts, 404 oder 500 können der Indexierung schaden. Google Search Central empfiehlt 503, wenn eine Website dringend für 1 bis 2 Tage abgeschaltet werden muss, für eine längere Pause eine indexierbare Startseite mit Status 200, und rät davon ab, für die robots.txt 503 zurückzugeben (Google Search Central).

WordPress.org schrieb am 21. Oktober, dass die Lücken nicht WordPress-spezifisch sind und kein WordPress-Update nötig oder geplant ist (WordPress.org). Derselbe Beitrag rät Betreibern, die ihren Server selbst verwalten und PHP älter als 8.2 nutzen, den Server bis zum vorbereiteten Update vom Netz zu nehmen, und verweist auf das britische NCSC. Das NCSC empfiehlt, ein System vom Netz zu nehmen, bis es vollständig abgesichert ist, wenn sich die vorläufigen Maßnahmen nicht schnell genug umsetzen lassen (NCSC). CERT Polska empfahl schon vor dem Release, aus dem Internet erreichbare PHP-Dienste vorübergehend abzuschalten (CERT Polska, 195/2026), und nennt in der Meldung 196/2026 eigene Werte für php.ini. Patchstack gibt denselben Rat für Websites mit hohem Risiko und warnt vor inoffiziellen “Fix”-Plugins und kopierten Code-Schnipseln, die “nicht geprüft sind und Ihre Website lahmlegen können” (eigene Übersetzung, Patchstack). Ein Plugin läuft innerhalb von PHP und kann eine Lücke in PHP selbst nicht beheben.

php.net beschreibt vorübergehende Servereinstellungen für Administratoren, die PHP nicht sofort aktualisieren können. Dazu gehören unter anderem Größenlimits für Anfragen und das Abschalten der Fortschrittsverfolgung für Datei-Uploads in der Session. Diese Einstellungen wirken nur auf Ebene der Serverkonfiguration: php.net stellt klar, dass für die Session-Einstellung weder ini_set() noch eine Datei .user.ini im Verzeichnis der Website ausreicht. Die Meldung betont außerdem, dass keine dieser Einstellungen eine Installation sicher macht:

Auch wenn nur ein Update eine vollständige Lösung ist, verringern die folgenden Maßnahmen die Angriffsfläche für bestimmte Angriffswege, machen eine Installation aber nicht sicher.

(eigene Übersetzung, php.net, Sicherheitsmeldung vom 21. Oktober 2026)

Als vorübergehende, teilweise Abhilfe nennt Calif für PHP-FPM session.upload_progress.enabled=0 zusammen mit memory_limit=-1 und für mod_php nur memory_limit=-1, und warnt, dass der Wert -1 die Speichergrenze von PHP aufhebt und so das Risiko erhöht, dass der Arbeitsspeicher ausgeht (Calif).

php.net rät außerdem, ungültige oder veraltete PHP-Einstellungen zu entfernen, die pro Anfrage gelten und vor der Initialisierung Meldungen erzeugen, und sie mit error_reporting, display_errors oder @ zu unterdrücken, hilft nicht. Ein Beispiel von uns, nicht von php.net: Seit PHP 8.3 sind alle INI-Einstellungen assert.* veraltet, deshalb prüfen Sie unter PHP 8.3 und neuer .htaccess, FPM-Pools und php.ini auf übrig gebliebene assert.*-Einträge, zum Beispiel php_value assert.active.

Die Details dieser Einstellungen für Serveradministratoren haben wir im Abschnitt zum kritischen PHP-Release in unserem Leitfaden zur Absicherung von WordPress zusammengestellt.

Läuft der Datenverkehr der Website über Cloudflare (orange Wolke am DNS-Eintrag), gibt es eine zusätzliche Schutzschicht. Laut Cloudflare sind Kunden mit kostenloser oder kostenpflichtiger WAF seit dem 21. Oktober 2026, 05:02 Uhr MESZ (03:02 UTC), standardmäßig gegen PHP2Shell geschützt, auch im Free-Tarif, und in den Tarifen Pro, Business und Enterprise sollten Sie prüfen, ob das Managed Ruleset im Blockiermodus läuft (Cloudflare). Patchstack schränkt ein, dass diese Regeln nur helfen, wenn der Server ausschließlich Verkehr von Cloudflare annimmt (Patchstack). Antwortet der Server jedem, umgeht eine Anfrage direkt an seine IP-Adresse die WAF. Cloudflare berichtet außerdem, schon vor dem offiziellen Release, nachdem die Lücke durchgesickert war, Angriffsverkehr gegen eigene Kunden beobachtet zu haben, ebenso Angreifer, die ihre Angriffsdaten abwandelten, um die Regeln zu umgehen. Die Zeitleiste von Patchstack verzeichnet um 07:34 UTC “mehrere Vorfälle aktiver Ausnutzung, die Hosting-Partner an Patchstack gemeldet haben” (eigene Übersetzung, Patchstack), während Huntress schrieb, bis 10 Uhr Ostküstenzeit (14:00 UTC) am 21. Oktober keine Ausnutzung bei seinen Partnern gesehen zu haben (Huntress). Cloudflare selbst sieht die WAF als zusätzliche Verteidigungsebene und rät trotzdem zum PHP-Update, und auch eingeschränkte Uploads und Upload-Größen ersetzen die Korrektur nicht.

#Wie Sie einen Angriffsversuch in den Serverlogs erkennen

Wiz weist darauf hin, dass die Fehler unterhalb der Anwendungsebene wirken, die Logs von WordPress also wenig zeigen können. Bis zum Update lohnt es sich, in den Serverlogs nach drei Signalen zu suchen (Wiz):

• ungewöhnliche Multipart-Anfragen, auf die Fehler wegen überschrittenem Speicherlimit oder wiederholte HTTP-500-Antworten folgen,
• unerwartet große oder fehlerhafte PHPSESSID-Cookies in den Antworten des Servers,
• unerklärliche Neustarts der PHP-Worker-Prozesse.

Diese Signale zeigen, wo die Prüfung beginnen sollte. Fehlen sie, heißt das nicht, dass es keinen Angriff gab, und sind sie vorhanden, ersetzt das nicht das Update.

#Müssen Sie nach dem Update die Passwörter ändern

Die Meldung auf php.net verlangt keinen Passwortwechsel. Es ist unsere Empfehlung, gestützt auf die Erkenntnis von Wiz: Über die Lücke lässt sich der Speicher des PHP-Prozesses auslesen, in dem Passwörter, Token und API-Schlüssel aus anderen Anfragen liegen können (Wiz). Eine Website, die eine Zeit lang auf einer anfälligen Version lief, kann ein solches Geheimnis preisgegeben haben, ohne dass im WordPress-Dashboard eine Spur bleibt.

Geheimnisse werden erst nach dem PHP-Update getauscht, denn ein neues Passwort, das auf einem ungepatchten Server gesetzt wird, kann auf demselben Weg abfließen wie das alte.

Was Sie ändern sollten:

• Schlüssel und Salts in wp-config.php. Einen neuen Satz der acht Konstanten erzeugt der offizielle Generator von WordPress.org. Nach dem Austausch werden alle angemeldeten Benutzer abgemeldet.
• Das Datenbankpasswort. Ändern Sie es im Hosting-Panel und tragen Sie das neue in wp-config.php als DB_PASSWORD ein.
• Die Passwörter der Administratorkonten und anderer Konten mit Bearbeitungsrechten.
• API-Schlüssel: die REST-API-Schlüssel von WooCommerce, Schlüssel der Zahlungsanbieter, SMTP-Zugangsdaten und Token externer Dienste, die in Plugin-Einstellungen gespeichert sind.

#Was ist mit PHP 7.4, 8.0 und 8.1

Das PHP-Projekt veröffentlicht für PHP 8.1 und älter keine Korrekturen mehr. Die Meldung auf php.net nennt zwei Wege: Ein Teil der Distributionen und LTS-Anbieter liefert zurückportierte Korrekturen, alle anderen sollten auf eine unterstützte Version wechseln. Wegen der Schwere der Lücken hat das PHP-Sicherheitsteam minimale Quellcode-Patches für PHP 7.4, 8.0 und 8.1 bereitgestellt, gedacht für alle, die PHP aus dem Quellcode kompilieren oder keinen Zugang zu einem LTS-Anbieter haben (php.net).

Für Websitebetreiber im Shared Hosting ändern Quellcode-Patches nichts, denn auf einem solchen Server kompiliert und installiert der Hoster PHP. Die eigentliche Wahl ist der Wechsel auf PHP 8.3, 8.4 oder 8.5 in der korrigierten Version. PHP 8.2 hat die Korrektur zwar ebenfalls erhalten, seine Sicherheitsunterstützung endet aber am 31. Dezember 2026 (php.net), die Wahl von 8.2 bedeutet also in zwei Monaten den nächsten Wechsel.

Die Kompatibilitätstabelle für WordPress- und PHP-Versionen finden Sie im Artikel Lohnt es sich, WordPress zu aktualisieren. Wenn ein altes Theme oder Plugin den Wechsel auf neueres PHP blockiert, beschreibt der Leitfaden zur Modernisierung alter WordPress-Codebasen den Migrationsplan. Nimmt ein WooCommerce-Shop nach dem PHP-Wechsel keine Bestellungen mehr an oder zeigt kritische Fehler, hilft der WooCommerce-Rettungssprint. Eine Prüfung der Serverkonfiguration, der PHP-Version und der Konten nach einem Vorfall gehört zum Sicherheitsaudit für WordPress.

#Checkliste für Betreiber von WordPress-Websites und WooCommerce-Shops

Stand 21. Oktober 2026, gegen 17:30 UTC, nach der Meldung auf php.net, den Einträgen in GitHub Security Advisories, den Veröffentlichungen von Calif und Wiz Research und den Meldungen von Ubuntu, Debian, WordPress.org, NCSC, CERT Polska, Patchstack und Huntress.