Kurz gesagt: Ein WordPress-Update hilft nicht gegen die PHP-Lücke PHP2Shell, weil der Fehler nicht in WordPress steckt, sondern in PHP, der Software auf dem Server, die WordPress ausführt. Laut Dr. Web plant WordPress.org deshalb auch kein eigenes Update. Schützen kann nur ein PHP-Update auf dem Server mit Neustart aller PHP-Prozesse. Das spielt in der Regel Ihr Hoster oder Serverbetreiber ein.
Der Aufhänger: „Wir haben doch alles aktualisiert“
Nach den ersten Schlagzeilen zu PHP2Shell haben viele Betreiber das Naheliegende getan: WordPress-Dashboard öffnen, auf „Jetzt aktualisieren“ klicken, Plugins und Themes gleich mit. Danach ist alles grün, und das Gefühl sagt: erledigt.
Bei dieser Lücke trügt das Gefühl. Das liegt nicht an WordPress, sondern daran, wo der Fehler sitzt. Auch Cloudflare weist in seiner Meldung darauf hin, dass ein Update von Anwendungscode oder Plugins die Lücken nicht behebt.
WordPress-Update und PHP-Lücke: das Schichtenmodell
Eine WordPress-Website besteht aus mehreren Schichten, die aufeinander aufbauen. Jede Schicht hat eigene Updates und oft eigene Zuständige:
| Schicht | Beispiel | Wer aktualisiert typischerweise | Betroffen von PHP2Shell? |
|---|---|---|---|
| Betriebssystem | Debian, Ubuntu, AlmaLinux | Hoster oder Serveradmin | nein, aber liefert oft das PHP-Paket |
| Webserver | Apache, Nginx, LiteSpeed | Hoster oder Serveradmin | Betriebsart beeinflusst das Risiko |
| PHP-Laufzeit | PHP-FPM, mod_php | Hoster oder Serveradmin | ja, hier liegt die Lücke |
| WordPress-Kern | WordPress | Betreiber oder Agentur | nein |
| Plugins und Themes | WooCommerce, Page-Builder | Betreiber oder Agentur | nein |
Der Update-Knopf im Dashboard erreicht nur die unteren beiden Zeilen. Die PHP-Laufzeit liegt darunter und ist für WordPress unsichtbar. Wie andere Systeme auf PHP aufbauen, beschreibt der Beitrag CMS und Shops auf PHP.
Warum WordPress die Lücke nicht schließen kann
Man könnte meinen, WordPress könne ja „drumherum programmieren“. Das funktioniert bei PHP2Shell aus zwei Gründen nicht.
Erstens liegen beide Fehler in der Art, wie PHP Anfragen verarbeitet und danach aufräumt. Das passiert unabhängig davon, welches Programm in PHP läuft. Zweitens hat das PHP-Team für Apache mit mod_php einen Exploit gezeigt, der greift, bevor überhaupt Anwendungscode ausgeführt wird. WordPress, seine Plugins und jedes Sicherheits-Plugin kommen dann gar nicht erst zum Zug.
Aus demselben Grund hilft auch kein „Härtungs-Plugin“, das Einstellungen per ini_set() ändert. php.net rät ausdrücklich davon ab, Übergangsmaßnahmen auf diesem Weg zu setzen.
Und bei Managed WordPress?
Bei Managed-WordPress-Angeboten kümmert sich der Anbieter oft nicht nur um WordPress-Updates, sondern auch um den Server darunter. Das ist für PHP2Shell ein Vorteil, aber kein Automatismus. Fragen Sie konkret, ob das PHP-Update eingespielt und alle PHP-Prozesse neu gestartet wurden. Die Aussage „Wir halten Ihr WordPress aktuell“ beantwortet diese Frage nicht.
Viele Websites, eine PHP-Installation
Agenturen und Unternehmen mit mehreren Websites sollten eine Besonderheit kennen: Auf einem Server teilen sich oft viele WordPress-Installationen dieselbe PHP-Version. Ist diese ungepatcht, sind alle betroffen, unabhängig davon, wie gut jede einzelne Website gepflegt ist. Umgekehrt schützt ein PHP-Update alle Installationen auf einmal, sofern danach alle zugehörigen PHP-Prozesse neu gestartet werden. Wer mehrere PHP-Versionen parallel betreibt, muss jede einzeln aktualisieren.
Ein grünes WordPress-Dashboard sagt nichts über PHP2Shell aus. Entscheidend ist der Patchstand von PHP auf dem Server und der Neustart aller PHP-Prozesse.
Die PHP-Version in WordPress richtig lesen
WordPress zeigt die PHP-Version an: im Dashboard unter Werkzeuge, Website-Zustand, im Bereich Bericht beim Abschnitt Server. Das ist ein guter erster Hinweis, aber kein Beweis.
Steht dort ein Zweig wie 8.1 oder älter, ist das ein klares Warnsignal, denn dafür gibt es keine offiziellen Updates mehr. Steht dort 8.2.35, 8.3.36, 8.4.27 oder 8.5.12, ist der behobene Stand installiert. Steht dort eine ältere Nummer eines unterstützten Zweigs, kann trotzdem ein Backport eingespielt sein. Distributionen und Hoster ändern die Nummer dabei oft nicht. Klarheit schafft nur die Bestätigung des Hosters oder ein Blick in das Paket-Changelog. Wie das geht, steht unter PHP-Version und Patchstand prüfen.
Was WordPress-Betreiber stattdessen tun sollten
- Hoster oder Serverbetreiber fragen: Ist PHP gepatcht, wann, und wurden alle PHP-Prozesse neu gestartet? Antwort schriftlich.
- PHP-Zweig prüfen: Läuft die Website auf 8.1 oder älter, den Wechsel auf einen unterstützten Zweig planen. Welche Version Ihre WordPress-Version unterstützt, steht in den Systemanforderungen auf wordpress.org. Den Wechsel im Kundenmenü beschreibt PHP-Version im Hosting-Kundenbereich ändern.
- Auf Spuren prüfen: neue PHP-Dateien in
wp-content/uploads, unbekannte Administratorkonten, fremde Einträge inmu-plugins. Die typischen Verstecke beschreibt die Seite WordPress und PHP2Shell. - WordPress trotzdem aktuell halten: Kern, Plugins und Themes schließen andere Lücken. Das bleibt Pflicht, nur eben eine andere.
- Zuständigkeit klären: Wenn eine Agentur die Website betreut, festhalten, ob sie auch für PHP zuständig ist oder nur für WordPress.
Gerade der letzte Punkt sorgt oft für Lücken. Die Agentur pflegt WordPress, der Hoster den Server, und jeder glaubt, der andere habe PHP2Shell im Blick.
Wie hilft PHP SOS konkret?
- Schichten klären: Wir stellen fest, wer bei Ihrer WordPress-Website für welche Schicht zuständig ist.
- PHP aktualisieren: Auf eigenen oder verwalteten Servern spielen wir das PHP-Update ein und starten alle Prozesse neu.
- WordPress prüfen: Wir suchen nach Spuren eines Angriffs in Dateien, Datenbank und Konten.
- Nachweis: Sie erhalten den Patchstand schriftlich, auch zur Weitergabe an Agentur oder Kunden.
Den Ablauf beschreibt der PHP-Patch-Service.
Fazit
Das WordPress-Update ist gute Pflege, aber gegen PHP2Shell die falsche Schicht. Die Lücke sitzt eine Etage tiefer, in PHP auf dem Server. Wer das versteht, stellt die richtige Frage an die richtige Stelle: Ist PHP gepatcht, neu gestartet und belegt?
Häufige Fragen
Bringt WordPress ein Sicherheitsupdate gegen PHP2Shell?
Laut Dr. Web plant WordPress.org kein Update gegen PHP2Shell, weil die Lücke im PHP-Interpreter auf dem Server liegt. Abhilfe schafft nur ein PHP-Update durch den Hoster oder Serverbetreiber.
Wo sehe ich in WordPress die PHP-Version?
Im Dashboard unter Werkzeuge, Website-Zustand, im Bereich Bericht beim Abschnitt Server. Die angezeigte Nummer sagt aber nicht sicher, ob der Patch eingespielt ist, weil Hoster Korrekturen oft als Backport ohne neue Versionsnummer einbauen.
Schützt ein Sicherheits-Plugin vor PHP2Shell?
Nur sehr begrenzt. Ein Plugin läuft selbst in PHP und wird erst aktiv, wenn WordPress geladen ist. Bei Apache mit mod_php wurde laut PHP-Team ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Dort kann ein Plugin nicht eingreifen.
Soll ich WordPress trotzdem aktualisieren?
Ja. Aktuelle Versionen von WordPress, Themes und Plugins schließen andere Lücken und sind Teil guter Pflege. Sie lösen nur nicht das Problem PHP2Shell.