PHP2Shell: Warum das WordPress-Update gegen die kritische PHP-Lücke nichts hilft und was Sie heute prüfen müssen

Das PHP-Projekt hat am 21. Oktober 2026 um 16 Uhr deutscher Zeit außerplanmäßige Sicherheitsversionen veröffentlicht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie schließen zwei Lücken im PHP-Interpreter selbst, geführt als CVE-2026-109618 und CVE-2026-109619 und in der Berichterstattung „PHP2Shell“ genannt. Ein Angreifer kann darüber ohne Anmeldung eigenen Code auf dem Webserver ausführen. Das Bundesamt für Sicherheit in der Informationstechnik hat am selben Tag eine Cybersicherheitswarnung herausgegeben. Für Sie als Betreiber heißt das: Ein Klick auf „Aktualisieren“ im WordPress-Dashboard ändert an der Lage nichts. Die Korrektur sitzt eine Ebene tiefer, beim Hoster.

Was passiert ist

Die Fehler stecken in der Speicherverwaltung von PHP, nicht in WordPress, einem Plugin oder Theme. Nach Darstellung der PHP Foundation bricht eine präparierte Anfrage die Verarbeitung ab, etwa indem sie das Speicherlimit ausreizt. Das Aufräumen danach läuft nicht sauber durch, und eine spätere Anfrage im selben PHP-Prozess erreicht Speicher, der eigentlich freigegeben ist. Wer diesen Speicher gezielt füllt, lenkt PHP in die Ausführung eigener Befehle. Die PHP Foundation schreibt, dass die vollständige Codeausführung mit Standardeinstellungen nachgewiesen wurde, auch unter PHP-FPM, der bei den meisten Hostern üblichen Betriebsart.

Ungewöhnlich war der Ablauf. Einzelheiten zu den Lücken sickerten am 20. Oktober vorzeitig durch, worauf das PHP-Projekt die geplante Veröffentlichung vom 22. auf den 21. Oktober vorzog. Das BSI nennt in seiner Warnung keine bestätigten Angriffe, verweist aber auf unbestätigte Berichte über existierende Exploits. Die PHP Foundation hatte zum Zeitpunkt der Veröffentlichung keinen funktionierenden Exploit gesehen, beobachtete aber kursierende Machbarkeitsnachweise. Die Zeit zwischen Patch und ersten Angriffsversuchen ist bei einer Lücke dieser Art kurz.

Was das für Ihre Website bedeutet

Betroffen ist jede Website, die auf einer nicht korrigierten PHP-Version läuft. Das gilt für WordPress und WooCommerce genauso wie für Joomla, Shopware oder TYPO3. Nach Angaben der PHP Foundation reichen die Fehler weit in alte Versionen zurück. Korrekturen gibt es nur für die vier gepflegten Zweige 8.2 bis 8.5. Wer noch PHP 8.1, 8.0 oder 7.4 einsetzt, bekommt keinen Patch, weil diese Versionen nicht mehr gepflegt werden. Für diese Seiten führt kein Weg an einem Versionswechsel vorbei, den ich in meinem Beitrag zu PHP-Versionen im Hosting beschrieben habe.

Zwei verbreitete Annahmen stimmen diesmal nicht. Erstens schützt ein aktuelles WordPress nicht, weil der Fehler unterhalb von WordPress liegt. Zweitens helfen Sicherheits-Plugins wie Wordfence oder Solid Security nicht gegen den Angriff selbst. Sie laufen innerhalb von PHP und kommen erst zum Zug, wenn PHP die Anfrage schon verarbeitet hat. Automattic weist in seiner Mitteilung ausdrücklich darauf hin. Was vorgelagert wirken kann, ist eine Web Application Firewall beim Hoster oder bei Cloudflare, für die es laut Automattic bereits Regeln gibt. Das ist eine Übergangshilfe, kein Ersatz für das Update.

Was Sie jetzt tun sollten

1. PHP-Version ablesen. In WordPress unter Werkzeuge → Website-Zustand → Reiter „Info“ → Abschnitt „Server“ steht die laufende PHP-Version. Alternativ zeigt sie die PHP-Einstellung im Kundenmenü Ihres Hosters. Sicher sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder neuer. Der Zweig allein sagt nichts: PHP 8.3 ist erst ab 8.3.36 geschützt.
2. Beim Hoster nachfragen, wenn die Version darunter liegt. Bei Shared Hosting und Managed WordPress spielt der Anbieter das Update ein. Viele haben das am 21. Oktober getan, manche brauchen länger. Fragen Sie nach der genauen Versionsnummer; eine Antwort nach dem Schema „WordPress ist aktuell“ reicht nicht.
3. Zweig wechseln, wenn Sie auf 8.1 oder älter sind. Die meisten Hoster erlauben den Wechsel im Kundenmenü. Vorher auf einer Kopie oder zumindest mit frischem Backup prüfen, ob Theme und Plugins mit 8.2 oder 8.3 zurechtkommen. Wie ich dabei vorgehe, steht im Beitrag zur PHP-Mindestversion bei WooCommerce.
4. Eigenen Server selbst aktualisieren. Wer einen eigenen Server betreibt, spielt die Pakete der Distribution ein, startet PHP-FPM neu und prüft mit php -v. Bis dahin empfiehlt Automattic für Seiten ohne Datei-Upload, Multipart-Anfragen am Webserver zu blockieren und file_uploads abzuschalten.
5. Protokolle ansehen. Auffällig sind laut den von Automattic zitierten Wiz-Forschern ungewöhnliche Multipart-Anfragen, gefolgt von Speicherlimit-Fehlern oder einer Häufung von HTTP-500-Antworten. Wer so etwas aus den Tagen vor dem Update findet, sollte die Seite wie eine möglicherweise kompromittierte behandeln.

Was Sie nicht tun müssen: die Seite vom Netz nehmen, wenn der Hoster das Update bestätigt hat. Was Sie nicht tun sollten: auf das nächste Wartungsfenster warten. Wer mehrere Installationen betreut, geht sie an einem Tag durch; bei meiner WordPress-Betreuung gehört die PHP-Version ohnehin zu den Punkten, die bei jedem Wartungstermin kontrolliert werden.

Quellen

• PHP-Projekt: PHP 8.3.36 Released, Security advisory
• BSI: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit
• PHP Foundation: Today's PHP security release and how we're strengthening PHP security

Kurz beantwortet

Reicht es, WordPress, Plugins und Theme zu aktualisieren?

Nein. Die Lücken liegen im PHP-Interpreter auf dem Server. Nur eine korrigierte PHP-Version schließt sie, und die spielt der Hoster oder der Serveradministrator ein.

Woran erkenne ich, ob meine Seite geschützt ist?

An der genauen Versionsnummer unter Werkzeuge → Website-Zustand → Info → Server. Geschützt sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder neuer. Jede kleinere Nummer im selben Zweig ist offen.

Ich bin noch auf PHP 8.1 oder älter. Was nun?

Für diese Zweige gibt es keine Korrektur mehr. Wechseln Sie im Kundenmenü des Hosters auf 8.2 oder 8.3, nachdem Sie mit einem aktuellen Backup geprüft haben, dass Theme und Plugins mitspielen.