Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die unter dem Namen PHP2Shell bekannt geworden sind (CVE-2026-109618 und CVE-2026-109619). Sie stecken nicht in WordPress, sondern eine Ebene darunter: in PHP selbst. Und weil jede WordPress-Website auf PHP läuft, ist auch jede WordPress-Website betroffen – bis das PHP auf dem Server aktualisiert ist.
In diesem Beitrag erfährst Du, was hinter PHP2Shell steckt, warum Dir ein WordPress-Update oder ein Sicherheits-Plugin hier nicht hilft und wie Du in wenigen Minuten prüfst, ob Deine Website geschützt ist.
Stand: 21. Oktober 2026. Die Lage entwickelt sich gerade schnell – prüfe im Zweifel die Statusseite Deines Hosters.
PHP2Shell ist der Name für zwei Fehler in der Speicherverwaltung von PHP. Vereinfacht gesagt: Ein Angreifer schickt eine speziell gebaute Anfrage an Deine Website, PHP gerät beim Verarbeiten dieser Anfrage in einen fehlerhaften Zustand – und am Ende kann der Angreifer eigenen Code auf Deinem Server ausführen. Das nennt man Remote Code Execution, und es ist die gefährlichste Klasse von Sicherheitslücken überhaupt.
Beide Lücken wurden mit 9,2 von 10 Punkten bewertet (CVSS v4.0, kritisch). Entdeckt hat sie das Sicherheitsunternehmen Wiz; betroffen sind PHP-Versionen zurück bis PHP 5.4 – also rund 14 Jahre PHP-Geschichte. Besonders heikel: Für einen Angriff braucht es keinen Login. Ein Auslöser sind sogenannte Multipart-Anfragen – genau das Format, mit dem Browser Formulare und Datei-Uploads verschicken.
Bei normalen WordPress-Sicherheitslücken steckt der Fehler in einem Plugin oder Theme. Dann hilft ein Update – oder eine Firewall, die den Angriff erkennt, bevor er das Plugin erreicht. Bei PHP2Shell ist das anders:
Wie ernst die Lage ist, zeigt der Hoster Mittwald: Er hat am 21. Oktober zunächst Formular-Uploads auf allen Servern abgeschaltet und dann vorsorglich den gesamten eingehenden Verkehr zu den Kundenwebsites gesperrt, bis das PHP-Update eingespielt war. Auch mehrere Kommunen und Organisationen haben ihre Websites vorübergehend vom Netz genommen.
Das geht direkt im WordPress-Backend, ohne Server-Zugang:
Geschützt bist Du mit einer dieser Versionen oder neuer:
Wichtig: Zeigt Deine Website eine ältere Nummer an, heißt das nicht in jedem Fall, dass sie ungeschützt ist. Linux-Distributionen wie Debian oder Ubuntu bauen Sicherheitskorrekturen oft in ältere Versionsnummern ein. Ob das bei Dir der Fall ist, kann Dir nur Dein Hoster sagen – schau auf seine Statusseite oder frag beim Support nach.
Das ist der häufigste Fall bei WordPress-Websites. Hier aktualisiert der Hoster das PHP – Du selbst kannst an der PHP-Installation nichts ändern. Die großen Anbieter rollen die Updates bereits aus, teilweise automatisch ohne Dein Zutun.
Für PHP 8.1, 8.0, 7.4 und ältere Versionen gibt es kein reguläres Update mehr. Das PHP-Projekt hat zwar wegen der Schwere der Lücke minimale Korrekturen im Quellcode bereitgestellt, aber die muss Dein Hoster selbst einbauen – darauf verlassen kannst Du Dich nicht.
Die sichere Lösung: Stelle die PHP-Version im Kundenbereich Deines Hosters auf PHP 8.3 oder 8.4 um. Das ist bei fast allen Hostern mit wenigen Klicks erledigt. Aber Vorsicht: Ältere Themes und Plugins vertragen den Sprung nicht immer. Lege vorher ein vollständiges Backup an und teste die Umstellung idealerweise auf einer Kopie Deiner Website – wie das geht, zeigen wir Dir in unserer Anleitung zum WordPress-Staging.
Betreibst Du Deinen Server selbst, spielst Du die aktualisierten PHP-Pakete Deiner Distribution ein und startest danach PHP-FPM bzw. den Webserver neu – sonst laufen die alten, verwundbaren PHP-Prozesse weiter. Am stärksten gefährdet sind laut PHP-Projekt Server mit Apache und mod_php.
Kannst Du nicht sofort aktualisieren, nennt das PHP-Projekt Übergangsmaßnahmen, die das Risiko verringern – ausdrücklich aber keinen vollständigen Schutz bieten:
session.upload_progress.enabled = 0 in der php.ini oder im FPM-Pool setzen (nicht per .user.ini oder ini_set() – das greift zu spät).memory_limit = -1 serverseitig per php_admin_value setzen und den Speicher stattdessen über Container- oder cgroup-Grenzen begrenzen.post_max_size verkleinern (8 MB ohne, 32 MB mit Datei-Uploads) und auf Webserver- oder Proxy-Ebene die Größe von Anfragen sowie die Zahl der Formularfelder, Multipart-Teile und Header begrenzen.Die PHP-Entwickler selbst warnen, dass diese Einstellungen nur bestimmte Angriffswege blockieren, andere Varianten aber nicht. Nimm sie also nur als Notbehelf für wenige Stunden – das Update ersetzen sie nicht. Nutzt Du Cloudflare, hast Du einen zusätzlichen Puffer: Cloudflare hat für alle Kunden Firewall-Regeln gegen PHP2Shell aktiviert. Auch das ist aber nur ein Teilschutz.
Das PHP-Update schließt die Lücke – es entfernt aber nichts, was ein Angreifer vorher schon auf Deinem Server abgelegt hat. Da die Lücke bereits vor dem Update ausgenutzt wurde, lohnt sich ein kurzer Kontrollblick:
wp-content/uploads/? Dort gehören normalerweise nur Bilder und Dokumente hin.wp-content/mu-plugins/ mit Dateien, die Du nicht selbst angelegt hast?Findest Du etwas Verdächtiges, gilt: Passwörter für WordPress, Datenbank, FTP/SFTP und Hosting-Kundenbereich ändern, die Sicherheitsschlüssel in der wp-config.php erneuern – und die Website gründlich bereinigen lassen. Einfach die eine verdächtige Datei zu löschen reicht in der Regel nicht, weil Angreifer meist mehrere Hintertüren hinterlassen.
Ja, solange das PHP auf Deinem Server nicht aktualisiert ist. Die Lücke steckt in PHP selbst und betrifft jede WordPress-Website unabhängig von WordPress-Version, Theme und Plugins. Geschützt bist Du ab PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 – oder wenn Dein Hoster die Korrektur bestätigt hat.
Nein. Der Angriff greift bereits beim Einlesen der Anfrage durch PHP, bevor WordPress geladen wird. Ein WordPress- oder Plugin-Update ändert daran nichts – nur ein PHP-Update schließt die Lücke.
Nicht verlässlich. Diese Sicherheits-Plugins laufen selbst in PHP und kommen zu spät, weil der Angriff vor dem Start von WordPress passiert. Firewall-Regeln vor dem Server, etwa bei Cloudflare, bieten einen Teilschutz, ersetzen das Update aber nicht.
Das PHP-Update spielt Dein Hoster ein. Du solltest aber Deine PHP-Version prüfen, die Statusseite Deines Hosters im Blick behalten und nach dem Update Formulare und Checkout testen. Läuft Deine Website noch auf PHP 8.1 oder älter, musst Du die PHP-Version selbst im Kundenbereich umstellen.
Typische Hinweise sind unbekannte Administratoren, PHP-Dateien im Ordner wp-content/uploads, unbekannte Dateien in wp-content/mu-plugins, Umleitungen auf fremde Seiten oder fremde Unterseiten Deiner Domain bei Google. Im Verdachtsfall alle Zugangsdaten ändern und die Website gründlich bereinigen lassen.
Bei PHP wurden zwei kritische Sicherheitslücken bekannt: CVE-2026-109618 und CVE-2026-109619. Betroffen sind bestimmte PHP-Versionen.
Bei den von uns betreuten Websites achten wir stets darauf, eine aktuelle PHP-Version zu verwenden, sofern dies technisch und providerseitig möglich ist. Das ist in der aktuellen Situation vorteilhaft: Für die aktuellen PHP-Versionen sind Sicherheitsupdates verfügbar, die von den Providern auf Serverebene eingespielt werden.
Das Einspielen dieser PHP-Patches ist Aufgabe des Providers. Da wir die Server nicht verwalten, können wir den Vorgang weder selbst durchführen noch beeinflussen. Nach unserem aktuellen Kenntnisstand haben die meisten Provider die erforderlichen Patches bereits eingespielt. Wenn Sie den genauen Status für Ihren Server erfahren möchten, fragen Sie bitte direkt bei Ihrem Provider nach.