WordPress-Sicherheitslücke: Was du jetzt prüfen solltest

Was ist passiert?

Am 21. Oktober 2026 hat das PHP-Projekt zwei schwere Fehler in PHP geschlossen. Sie tragen die Nummern CVE-2026-109618 und CVE-2026-109619 und laufen unter dem Namen php2shell. Wer sie ausnutzt, kann ohne Login fremden Code auf dem Server ausführen. Eine der beiden Lücken kann zusätzlich Daten aus dem Speicher des Servers preisgeben.

Der Fehler steckt nicht in WordPress, sondern in PHP. Er trifft deshalb alles, was darauf läuft: WordPress, WooCommerce, Joomla, Shopware, TYPO3 und viele andere Systeme. PHP läuft auf einem Großteil aller Websites.

Die Patches kamen früher als geplant. Schon am 20. Oktober kursierte ein Hinweis auf die bevorstehende Veröffentlichung, deshalb hat das PHP-Projekt sie vorgezogen. Laut Cloudflare liefen Angriffsversuche schon Stunden vor den Patches, millionenfach. Ob es erfolgreiche Einbrüche in der Breite gab, war am 22. Oktober noch nicht bestätigt. Das BSI hat eine Warnung herausgegeben, unter anderem die Charité und mehrere Behörden haben ihre Seiten vorsorglich vom Netz genommen.

Ist meine Website betroffen? So prüfst du es in fünf Minuten

Läuft deine Seite auf WordPress oder einem anderen PHP-System, ist sie betroffen, bis jemand das Gegenteil bestätigt. Hast du keinen Zugang zu WordPress, schick die folgenden Schritte an den, der deine Seite betreut.

1. PHP-Version nachsehen. In WordPress findest du sie unter Werkzeuge → Website-Zustand → Bericht → Server (in manchen Versionen heißt der Reiter „Info“). Geschlossen ist die Lücke ab diesen Versionen:

2. Den Hoster schriftlich fragen. Viele Hoster spielen den Schutz ein, ohne dass sich die angezeigte Versionsnummer ändert. Die Nummer allein sagt also nicht alles. Eine kurze Mail reicht: „Ist php2shell auf meinem Paket gepatcht, auch für meine PHP-Version?“ Die Antwort hebst du auf.

3. Alte PHP-Version wechseln. Für PHP 8.1, 8.0 und 7.x gibt das PHP-Projekt keine neue Version heraus, denn nur die Reihen auf der Liste der unterstützten PHP-Versionen bekommen noch Sicherheitsfixes. Laut W3Techs läuft gut ein Drittel aller PHP-Websites noch auf PHP 7 oder 5. Der Wechsel auf 8.3 oder 8.4 geht meist im Kundenbereich des Hosters. Vorher eine Sicherung machen und danach die Seite durchklicken, denn alte Plugins vertragen neue PHP-Versionen nicht immer.

4. Passwörter ändern lassen. Weil eine der Lücken Daten aus dem Speicher preisgeben kann, lass nach dem Patch die wichtigsten Passwörter ändern: WordPress-Admins, Datenbank, Hosting. Auch dann, wenn du keine Auffälligkeiten siehst. Das kostet eine halbe Stunde und nimmt einem möglichen Angreifer die Schlüssel.

Hast du einen eigenen Server oder ein VPS statt eines normalen Hosting-Pakets, patcht niemand für dich. Dann musst du oder dein Dienstleister das Update selbst einspielen.

Woran merke ich, dass schon jemand drin ist?

Das Wichtigste vorweg: Ein Update schließt die Tür, es wirft niemanden hinaus. Wer vor dem Patch eine Hintertür eingebaut hat, bleibt drin. Deshalb lohnt der zweite Blick.

Diese Zeichen kannst du ohne Technikwissen prüfen:

• In der WordPress-Benutzerliste steht ein Admin-Konto, das niemand kennt.
• Deine Seite leitet Besucher manchmal auf fremde Seiten um, oft nur auf dem Handy.
• Bei Google erscheinen unter deiner Domain Begriffe, die nichts mit dir zu tun haben, etwa Arzneimittel oder Glücksspiel.
• Die Google Search Console meldet unter „Sicherheitsprobleme“ einen Befund.
• Dein Hoster schreibt dir wegen ungewöhnlicher Last oder Spam-Versand.

Fehlen diese Zeichen, ist das kein Beweis, dass alles sauber ist. Siehst du eines davon, geh in dieser Reihenfolge vor:

1. Den aktuellen Zustand sichern, damit sich später nachvollziehen lässt, was passiert ist.
2. PHP patchen lassen. Sonst ist die Seite gleich wieder offen.
3. Eine Sicherung von vor dem 17. Oktober einspielen, ab da gab es erste Angriffsversuche. Achtung: Anfragen und Bestellungen seit dieser Sicherung gehen dabei verloren, sichere sie vorher.
4. Alle Passwörter ändern: WordPress, Hosting, Datenbank, FTP.

Kannst du das nicht selbst, gib diese Liste an den, der deine Seite betreut. Sind Kontaktanfragen oder Kundendaten betroffen, läuft ab jetzt eine Meldefrist, mehr dazu in den Fragen unten.

Wer ist eigentlich zuständig: Hoster, Dienstleister oder du?

Hier liegt das eigentliche Problem, und es bleibt auch nach php2shell. Eine WordPress-Seite besteht aus mehreren Schichten. Jede braucht Updates, und für jede ist jemand anderes zuständig.

php2shell betraf die unterste Schicht. Da musste der Hoster ran. Die meisten Lücken stecken aber eine Etage höher: Der Sicherheitsdienst Patchstack zählte 2025 über 11.000 neue Lücken im WordPress-Umfeld, rund 30 am Tag, fast alle in Plugins und Themes. Und genau dort ist die Zuständigkeit oft ungeklärt. Die Agentur, die die Seite gebaut hat, ist nach dem Projekt weg. Der Hoster fühlt sich für Plugins nicht zuständig. Und der Inhaber geht davon aus, dass „die das schon machen“.

Stell deshalb eine einfache Frage, am besten schriftlich: Wer spielt bei meiner Website die Updates ein, wie schnell nach einer kritischen Lücke, und wo steht das? Kann dir niemand diese Frage beantworten, weißt du, wo dein Risiko liegt.

Vier Wege, die Website langfristig abzusichern

Es gibt nicht die eine richtige Lösung. Welche passt, hängt davon ab, wie wichtig die Website für dein Geschäft ist und ob ohnehin ein Relaunch ansteht.

1. Wartungsvertrag. Ein Dienstleister spielt regelmäßig Updates ein, macht Sicherungen und reagiert auf kritische Lücken. Gängige Wartungspakete für WordPress kosten im Markt rund 50 bis mehrere hundert Euro im Monat, vereinzelt gibt es sie deutlich günstiger. Achte im Vertrag auf drei Dinge: welche Schichten abgedeckt sind, wie schnell bei einer kritischen Lücke reagiert wird und ob Sicherungen auch probeweise wiederhergestellt werden. Eine Sicherung, die nie getestet wurde, ist eine Hoffnung.

2. Verwaltetes WordPress-Hosting. Spezialisierte Hoster übernehmen den Server und oft auch die Updates von WordPress und Plugins. Das nimmt viel ab. Ob ein Plugin-Update deine Seite zerschießt, prüft aber auch dort nicht jeder.

3. Abspecken. Jedes Plugin ist eine Tür mehr. Lösch deaktivierte Plugins und Themes und entferne alte Admin-Konten. Für die Zwei-Faktor-Anmeldung brauchst du ein Plugin, nimm dafür ein einziges, gut gepflegtes. Automatische Updates kannst du in der Plugin-Liste für jedes Plugin einzeln einschalten. Das kostet etwa eine Stunde und verkleinert die Angriffsfläche sofort.

4. Eine Website ohne PHP. Websites lassen sich auch so bauen, dass auf dem Server kein PHP läuft und keine Datenbank, die angegriffen werden kann. Texte und Bilder pflegst du dann über eine schlichte Eingabemaske oder lässt sie ändern. Lücken wie php2shell treffen solche Seiten nicht. Automatisch sicher sind sie trotzdem nicht: Auch diese Technik hat eigene Lücken und braucht Updates, dazu gleich mehr. Ein Umstieg lohnt sich nur, wenn ohnehin ein Relaunch ansteht, nicht als Reaktion auf eine einzelne Lücke.

Was wir bei unseren eigenen Websites gelernt haben

Die Websites, die wir bauen, laufen ohne PHP. Als die Lücke bekannt wurde, haben wir trotzdem alle geprüft, die live sind. Betroffen war keine. Zwei Dinge sind uns dabei aufgefallen.

Die vergessene Altinstallation. Bei einem Kunden lief die alte WordPress-Seite nach dem Umzug noch beim alten Hoster weiter. Die Domain zeigte längst auf die neue Website, Besucher sahen davon nichts. Wer aber den alten Server direkt ansprach, landete im alten Shop, samt Login-Seite. Eine solche Installation bekommt keine Updates mehr, weil niemand mehr an sie denkt. Die Lehre: Nach jedem Relaunch die alte Installation sichern und dann löschen. Abschalten reicht nicht, wenn der Server weiterläuft.

Auch wir lagen hinterher. Next.js, das System hinter unseren Websites, hatte eine Woche vorher selbst ein Notfall-Update für kritische Lücken bekommen. Unsere Seiten standen da noch nicht drauf, sie lagen sogar schon mehrere Sicherheits-Updates zurück. Am 22. Oktober haben wir das Update für alle unsere Websites vorbereitet und fast alle noch am selben Tag live gebracht. Seitdem erinnert uns eine Prüfung an offene Sicherheits-Updates. Weniger Angriffsfläche ist ein echter Vorteil. Es ersetzt aber nicht, dass jemand hinschaut.