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 meiner 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.

Das finnische staatliche IT-Zentrum Valtori begann am 21. Oktober kurz nach 13:00 Uhr finnischer Zeit, öffentliche Webdienste der Zentralregierung vorsorglich vom Netz zu nehmen, und die Website des finnischen Landvermessungsamts Maanmittauslaitos war um 15:11 Uhr bereits nicht mehr erreichbar (Yle News). Die Universität Freiburg kündigte um 10:39 Uhr Ortszeit an, dass ihre Websites und zentralen Dienste vom Netz gehen (Rechenzentrum der Universität Freiburg).

In den Niederlanden meldete NOS um 11:10 Uhr MESZ, dass die Tweede Kamer, das NCSC, die Autoriteit Persoonsgegevens und Tweakers ihre Websites abgeschaltet hatten und dass NotuBiz, das System für Ratssitzungen von rund hundert Gemeinden, schon am Morgen vom Netz gegangen war (NOS). Auch die Website der Universität Wien und das Wiki explain xkcd waren zeitweise nicht erreichbar (ORF, explain xkcd). W3Techs zählt PHP auf 69,3 % der Websites, deren serverseitige Sprache es kennt (Stand 23. Oktober 2026). Deshalb hat ein einziger Fehler im Interpreter so viele Betreiber gleichzeitig dazu gebracht, ihre Websites abzuschalten (W3Techs).

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). Automattic schrieb am 21. Oktober 2026, dass Websites auf WordPress.com, WordPress VIP, WP Cloud, Pressable und Tumblr bereits geschützt sind und ihre Betreiber nichts tun müssen (Automattic). Das Update betrifft also Websites, deren PHP der Betreiber selbst oder ein anderer Hoster verwaltet.

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 meiner 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). Wenn Sie das von Freiwilligen betreute Repository rpms.remirepo.net nutzen, fordert php.net Sie auf, auf Pakete der Distribution umzusteigen oder aus dem Quellcode zu kompilieren, damit Sie Updates sofort einspielen können, und warnte, dass das Repository am Tag des Releases keine Updates haben würde (php.net, 21. Oktober 2026). 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 meiner 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. Mein 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).

Die Advisories des PHP-Projekts ordnen jede Übergangsmaßnahme einer bestimmten Lücke zu. Für CVE-2026-109618 gilt memory_limit=-1, gesetzt und erzwungen, als wichtigste Maßnahme in der Konfiguration. Laut Advisory ist sie unvollständig, weil eine fehlgeschlagene Speicheranforderung PHP weiterhin auf den verwundbaren Pfad führen kann, und es rät von RLIMIT_AS und RLIMIT_DATA ab, die genau diesen Pfad auslösen. Außerdem empfiehlt es ein knappes post_max_size, das zusätzlich auf dem vorgeschalteten Server durchgesetzt wird, Grenzen für Multipart-Teile, Header und Uploads sowie das Blockieren von Multipart-Anfragen an dieser Stelle, wenn die Anwendung sie nicht braucht. Mit dem Patch meldet PHP einen weichen Speicherfehler an einem sicheren Punkt und beendet den Prozess erst, wenn der Verbrauch eine zweite, höhere Schwelle erreicht (GHSA-w8hw-w9fx-j79w). Die Einstellung session.upload_progress.enabled=0 stammt aus dem Advisory zu CVE-2026-109619 und deckt laut diesem nur den dort gezeigten Pfad im Lebenszyklus der Sitzung ab, die übrigen Pfade nicht (GHSA-6wmf-4rv5-p3rp). Unser Hinweis: WordPress lädt Dateien in die Mediathek und Daten vieler Formulare per Multipart hoch, eine komplette Sperre legt also Backend und Formulare lahm. Diese Option passt nur zu Websites ohne Datei-Uploads.

Für CVE-2026-109619 unter PHP 8.5 nennt php.net außerdem fatal_error_backtraces=0 mit einem Neustart aller Worker und schreibt, dass dies nur den bestätigten Pfad über den Backtrace bei fatalen Fehlern sperrt (php.net, 21. Oktober 2026). Dieselbe Meldung rät, 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 mir, 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.

Aktualisierung vom 24. Oktober 2026. Die Releases vom 21. Oktober schließen nicht jeden Angriffsweg. Am 23. Oktober veröffentlichte php.net einen informativen Hinweis zu einem weiteren Weg zur Remote-Codeausführung, CVE-2026-115560. Das PHP-Projekt hält ihn in der Praxis für unwahrscheinlich, behebt ihn im nächsten regulären Bugfix-Release und veröffentlicht erst dann einen vollständigen Hinweis. Er betrifft also auch bereits aktualisierte Server, setzt aber drei Bedingungen zugleich voraus: Die Konfiguration setzt session.serialize_handler auf php_binary oder php_serialize, die Anwendung stellt ihn zur Laufzeit per ini_set() vor dem Aufruf von session_start() auf php um, und der Upload-Fortschritt für Sessions ist weiterhin aktiv. Anwendungen, die den Serialisierer zur Laufzeit nie ändern, können die Funktion eingeschaltet lassen. Bis zu diesem Release schlägt php.net session.upload_progress.enabled=0 vor. Wenn Sie diese Einstellung bereits am 21. Oktober als Maßnahme gegen CVE-2026-109619 gesetzt haben, lassen Sie sie bestehen, mehr ist nicht nötig (php.net, 23. Oktober 2026). Wie sie gesetzt wird, steht in der Meldung vom 21. Oktober: in php.ini, einem FPM-Pool oder der Serverkonfiguration, nicht über ini_set() oder .user.ini, danach ein Neustart aller Worker. Beim Shared Hosting ist das also eine Anfrage an den Hoster. Unser Hinweis: Ob Code auf Ihrem Server den Serialisierer umstellt, finden Sie heraus, indem Sie Plugins, Themes und eigenen Code nach session.serialize_handler durchsuchen, etwa mit grep -rn "session.serialize_handler" wp-content/.

Die Details dieser Einstellungen für Serveradministratoren habe ich im Abschnitt zum kritischen PHP-Release in meinem 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.

Aktualisierung vom 23. Oktober 2026. Einen Tag nach den Korrekturen meldete Wordfence, dass es auf den mehr als fünf Millionen WordPress-Websites, die es schützt, keine bestätigte Kompromittierung durch die beiden Lücken beobachtet hat. Die eigene Firewall hat in dieser Zeit mehr als 74.000 Angriffs- und Sondierungsversuche abgefangen. In einer Stichprobe von Anfragen vom 20. bis 22. Oktober, die laut Wordfence nicht repräsentativ für den gesamten Datenverkehr ist, versuchen die Anfragen, .env und wp-config.php auszulesen, Befehle wie id und uname -a auszuführen und eine PHP-Shell namens wp2s.php in beschreibbare Ordner für hochgeladene Dateien, Plugins oder Themes zu schreiben. Sie zeigen eine Absicht, keinen gelungenen Angriff. Wordfence ergänzt, dass das Fehlen einer bestätigten Kompromittierung in seinen Daten einen nicht aktualisierten Server nicht sicher macht, weil manche Fehler außerhalb von WordPress und seinen Protokollen auftreten (Wordfence, 22. Oktober 2026). Auf Debian- und Ubuntu-Servern, die PHP aus dem Repository deb.sury.org beziehen, stammen die Pakete von Ondřej Surý. Er ist Debian-Entwickler, auf seiner Arbeit beruhen die offiziellen PHP-Pakete in Debian und Ubuntu, und er schreibt, dass er die Paketierung überwiegend in seiner Freizeit erledigt (deb.sury.org). Bei meiner Prüfung am 23. Oktober führte sein Repository für Debian 12 die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12, erstellt am 21. Oktober (packages.sury.org). Das gilt für jede PHP-Anwendung, ob Onlineshop, CRM oder ein anderes CMS: Prüfen Sie, wer die PHP-Pakete auf Ihrem Server baut und ob Ihr Versionszweig noch Korrekturen erhält, vergleichen Sie die installierte Version mit der korrigierten und starten Sie nach der Aktualisierung alle PHP-Prozesse neu. Diese Kontrolle auf Kundenservern gehört zu meiner Wartung von WordPress-Websites.

#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.

Aktualisierung vom 28. Oktober 2026. Eine Woche nach den Korrekturen kennt Wordfence weiterhin keine WordPress-Website, die über PHP2Shell kompromittiert wurde, und sein Team für die Bereinigung von Websites hatte keinen solchen Fall. Die Versuche gehen weiter: Eine eigene Überwachungsregel zählte vom 23. bis 27. Oktober rund 77.600 zugehörige Anfragen von mehr als 2.000 IP-Adressen, keine davon sah nach normalem Besucherverkehr aus. Werkzeuge, die gezielt für diese Lücken gebaut wurden, tauchten in den Daten von Wordfence am 21. Oktober auf, etwa vier Stunden vor der öffentlichen Bekanntgabe. Im Labor von Wordfence führte ein Test-Exploit auf einem speziell konfigurierten PHP-Build Code aus, auf einem normalen, optimierten Build derselben Version brachte er PHP nur zum Absturz. Ein Exploit muss also an den jeweiligen Server angepasst werden. Das bremst Massenangriffe, behebt aber nichts (Wordfence, 28. Oktober 2026). Auf einem eigenen Server prüfen Sie zwei Dinge. find wp-content -name "*.php" -newermt 2026-10-17 listet PHP-Dateien, die seit dem 17. Oktober angelegt oder geändert wurden, in wp-content/uploads sollte keine liegen. cat /proc/sys/kernel/randomize_va_space sollte 2 liefern, also volle Zufallsverteilung des Adressraums (ASLR). Bewahren Sie Logs von Webserver, PHP und Firewall vom 17. Oktober bis zum Neustart von PHP nach dem Update auf. Finden Sie eine fremde Datei oder ein unbekanntes Administratorkonto, behandeln Sie die Website als kompromittiert: zuerst eine Kopie des aktuellen Zustands als Beweis, dann ein neues Datenbankpasswort und neue Schlüssel in der wp-config.php. Sind dabei personenbezogene Daten betroffen, läuft nach Art. 33 DSGVO die 72-Stunden-Frist für die Meldung an die zuständige Aufsichtsbehörde, in Österreich die Datenschutzbehörde. So arbeite ich bei der Malware-Entfernung für WordPress.

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

Die Meldung auf php.net verlangt keinen Passwortwechsel. Es ist meine 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.

Aktualisierung vom 27. Oktober 2026. Beim Wechsel auf einen neueren PHP-Zweig gibt es einen Fehler, der besonders seltsam aussieht: Statt der Seite lädt der Browser eine Datei herunter, meist index.php. Der Server reicht .php-Dateien dann nicht mehr an den Interpreter weiter und liefert sie als gewöhnliche Dateien aus. Unter Apache steckt oft eine AddHandler-Zeile in der .htaccess dahinter, die .php dem Handler einer PHP-Version zuordnet, die der Hoster entfernt hat (Apache, mod_mime). Ein Befehl bestätigt die Diagnose: curl -sI https://example.com/ liefert Content-Type: application/octet-stream statt text/html. Die Lösung ist eine unterstützte Version im Hosting-Panel und das Löschen der alten AddHandler-Zeile, kein Zurückspielen eines Backups. Was in den meisten Anleitungen fehlt: Solange PHP nicht läuft, lässt sich jede .php-Datei als Quelltext herunterladen, auch die wp-config.php mit Datenbankpasswort und Schlüsseln. Hat der Ausfall länger als einen Moment gedauert, prüfen Sie danach im Access-Log, ob jemand diese Datei abgerufen hat (grep "wp-config.php" access.log). Finden Sie einen Abruf oder haben Sie kein Log, ändern Sie das Passwort des Datenbankbenutzers und erzeugen Sie neue Schlüssel und Salts (Generator von WordPress.org). Neue Salts melden alle Benutzer ab, was hier gewollt ist. Bei der Betreuung übernehme ich den PHP-Wechsel samt dieser Prüfung, siehe Wartung von WordPress-Websites.

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

Stand 22. Oktober 2026, gegen 08:00 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, Automattic, Patchstack und Huntress. Der informative Hinweis von php.net vom 23. Oktober (CVE-2026-115560) wurde am 24. Oktober 2026 ergänzt.