Kurz gesagt: Die WordPress PHP-Sicherheitslücke, über die gerade berichtet wird, steckt nicht in WordPress, sondern in PHP auf dem Server darunter. Ein WordPress-Update schliesst PHP2Shell deshalb nicht. Entscheidend sind der Patchstand von PHP, der Neustart aller PHP-Prozesse und eine Prüfung typischer Verstecke wie wp-content/uploads und mu-plugins.
Warum ein WordPress-Update PHP2Shell nicht behebt
WordPress ist eine Anwendung, die in PHP geschrieben ist. Die Lücken CVE-2026-109618 und CVE-2026-109619 liegen eine Ebene tiefer, im PHP-Interpreter selbst. Sie erlauben laut PHP-Team das Ausführen von Schadcode aus der Ferne ohne Anmeldung. Bei Apache mit mod_php wurde ein Exploit gezeigt, bevor überhaupt WordPress-Code läuft.
Eine Website mit aktuellem Core, aktuellen Plugins und starken Passwörtern kann also trotzdem angreifbar sein, wenn das PHP darunter alt ist. Umgekehrt beweist ein gepatchtes PHP nicht, dass vorher nichts passiert ist. Die Hintergründe erklären wir unter Was ist PHP2Shell?.
| Ebene | Wer aktualisiert | Schliesst PHP2Shell? |
|---|---|---|
| WordPress-Core | Sie oder Ihre Agentur | Nein |
| Plugins und Themes | Sie oder Ihre Agentur | Nein |
| PHP auf dem Server | Hoster oder Server-Admin | Ja, zusammen mit dem Neustart aller PHP-Prozesse |
WordPress PHP-Sicherheitslücke: PHP-Version prüfen
Im Dashboard finden Sie unter Werkzeuge > Website-Zustand > Bericht im Abschnitt „Server“ die PHP-Version, mit der Ihre Website tatsächlich läuft. Das ist aussagekräftiger als php -v auf der Kommandozeile, denn die Kommandozeile nutzt oft eine andere PHP-Installation als der Webserver.
Die angezeigte Nummer allein genügt trotzdem nicht. Behobene Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Viele Hoster spielen die Korrekturen aber als Backport ein; dann steht weiter eine ältere Nummer da, obwohl gepatcht ist. Wie Sie den echten Stand ermitteln, steht in PHP-Version und Patchstand richtig prüfen. Welche PHP-Versionen Ihre WordPress-Version unterstützt, prüfen Sie laut Systemanforderungen auf wordpress.org.
Wo sich Schadcode in WordPress gern versteckt
Nach einem erfolgreichen Angriff legen Täter meist eine Hintertür ab, um auch nach dem Patch wiederzukommen. WordPress hat dafür bekannte Orte:
- wp-content/uploads/: gedacht für Bilder und PDFs, nicht für PHP-Dateien.
- wp-content/mu-plugins/: „Must-use“-Plugins laden automatisch und lassen sich im Dashboard nicht deaktivieren.
- wp-config.php: enthält Datenbankzugang und Sicherheitsschlüssel; eine eingeschobene Zeile fällt hier kaum auf.
- .htaccess im Hauptverzeichnis und in Unterordnern: Weiterleitungen nur für Suchmaschinen oder das Ausführen ungewöhnlicher Dateiendungen.
- Themes, vor allem
functions.php, sowie deaktivierte, vergessene Plugins. - Datenbank: neue Administratoren in
wp_users, fremdes JavaScript inwp_optionsoder in Beiträgen.
Ungefährliche erste Prüfungen mit WP-CLI und Bordmitteln:
# Core-Dateien gegen die offiziellen Prüfsummen vergleichen
wp core verify-checksums
# Plugins aus dem Verzeichnis auf wordpress.org prüfen
wp plugin verify-checksums --all
# PHP-Dateien im Upload-Ordner auflisten
find wp-content/uploads -type f -name "*.php"
# Alle Administratoren anzeigen
wp user list --role=administrator
Ein Treffer ist ein Anlass zur genauen Untersuchung, noch kein Beweis. Kommerzielle Plugins lassen sich so nicht prüfen. Ausführlich geht es im Ratgeber Backdoors in WordPress finden weiter.
Löschen Sie verdächtige Dateien nicht vorschnell. Sichern Sie zuerst Dateien, Datenbank und die Server-Logs ab dem 20.10.2026. Ohne diese Spuren lässt sich später nicht klären, ob Daten abgeflossen sind.
Plugins, Themes und Admin-Zugänge als zusätzliches Risiko
PHP2Shell braucht keine Plugin-Lücke. Im Alltag bleiben Plugins und Themes aber der häufigste Einstieg in WordPress-Websites. Jedes Plugin bringt eigenen Code, eigene Upload-Funktionen und eigene Update-Zyklen mit. Nicht genutzte Plugins sollten Sie löschen statt nur deaktivieren, denn deaktivierte Dateien liegen weiter auf dem Server.
Für wp-login.php und wp-admin gilt: wenige Administratoren, persönliche Konten statt geteilter Zugänge und eine Zwei-Faktor-Anmeldung. Wenn Sie XML-RPC nicht benötigen, kann es gesperrt werden. Nach einem Verdacht sollten alle Passwörter und die Sicherheitsschlüssel in wp-config.php erneuert werden. Den Datei-Editor im Dashboard schalten Sie dort ebenfalls ab:
define( 'DISALLOW_FILE_EDIT', true );
Was Sie als WordPress-Betreiber jetzt tun sollten
- Beim Hoster schriftlich den PHP-Patchstand und den Neustart aller PHP-Prozesse bestätigen lassen.
- Server-Logs ab dem 20.10.2026 aufbewahren lassen.
- Die Prüfungen oben durchführen oder durchführen lassen.
- WordPress, Plugins und Themes aktualisieren. Das ist richtig, aber kein Ersatz für Schritt 1.
- Bei Auffälligkeiten die Website nicht einfach weiterbetreiben, sondern bereinigen lassen.
Ein Plattform-Update kann bekannte Lücken in WordPress und Plugins schliessen. Es kann weder PHP reparieren noch eingeschleuste Dateien entfernen, die nicht zum Core gehören.
Wie hilft PHP SOS konkret?
- Wir klären mit Ihnen oder Ihrem Hoster den tatsächlichen PHP-Stand Ihrer WordPress-Website, einschliesslich Backports und Neustart.
- Wir sichern Logs, Dateien und Datenbank, bevor etwas verändert wird.
- Wir prüfen Core, Plugins, Uploads, mu-plugins,
.htaccessund Benutzerkonten auf Hintertüren. - Bei Funden übernimmt unsere Malware-Entfernung die Bereinigung bis der Vorfall abgeschlossen und dokumentiert ist; ohne Funde härten wir die Installation im Rahmen der PHP2Shell-Soforthilfe.
Häufige Fragen
Muss ich WordPress wegen PHP2Shell aktualisieren?
Ein aktuelles WordPress ist immer sinnvoll, schliesst PHP2Shell aber nicht. Die Lücke liegt im PHP-Interpreter des Servers. Dafür braucht es ein PHP-Update oder einen bestätigten Backport Ihres Hosters und einen Neustart aller PHP-Prozesse.
Schützt ein Sicherheits-Plugin vor PHP2Shell?
Nur sehr eingeschränkt. Ein Plugin läuft selbst als PHP-Code innerhalb von WordPress. Bei mod_php wurde ein Exploit gezeigt, bevor Anwendungscode überhaupt startet; ein Plugin bekommt so einen Angriff womöglich gar nicht mit.
Warum zeigt WordPress noch eine alte PHP-Version an, obwohl der Hoster gepatcht hat?
Viele Hoster und Linux-Distributionen spielen Korrekturen als Backport in die bestehende Version ein. Die Versionsnummer bleibt dann gleich. Lassen Sie sich den Patchstand vom Hoster schriftlich bestätigen.
Darf in wp-content/uploads eine PHP-Datei liegen?
Im Normalfall nicht. Der Upload-Ordner ist für Medien gedacht. Eine PHP-Datei dort ist ein deutliches Warnsignal und sollte gesichert und fachlich untersucht werden, bevor sie gelöscht wird.