WordPress 7.0.2: Was ist passiert und warum sollten Sie sofort aktualisieren?
Am 17. Juli 2026 hat WordPress die Version 7.0.2 veröffentlicht, ein Sicherheitsupdate, das zwei Sicherheitslücken behebt: eine kritische und eine mit hohem Schweregrad. Es handelt sich nicht um ein gewöhnliches Wartungsupdate: Die kritische Sicherheitslücke ermöglicht es einem Angreifer ohne jegliche Anmeldedaten, Code auf dem Server einer WordPress-Website mit Standardinstallation auszuführen.
Wenn Sie eine WordPress-Website betreiben, ist dies eine dieser Nachrichten, die Sie jetzt lesen sollten – und nicht erst am Montag.
Was ist passiert?
Das Update behebt zwei Probleme, die verantwortungsbewusst über das HackerOne-Programm von WordPress gemeldet wurden:
- CVE-2026-63030, auch „wp2shell“ genannt: Eine Verwechslung bei der Routenverwaltung des Batch-Endpunkts der REST-APIs, die in Kombination mit der anderen Schwachstelle zur Remote-Code-Ausführung (RCE) führt. Es handelt sich um die kritische Sicherheitslücke, die von Adam Kues vom Assetnote-Team von Searchlight Cyber entdeckt wurde.
- CVE-2026-60137: eine SQL-Injection, gemeldet vom Team bestehend aus TF1T, dtro und haongo. Dies ist das zweite Glied in der Kette.
Was diesen Fall vom Üblichen unterscheidet, ist die Leichtigkeit der Ausnutzung. Den Forschern zufolge erfordert der Angriff keine Voraussetzungen: keine Anmeldung, kein Plugin von Drittanbietern, keine besondere Konfiguration. Eine Standard-WordPress-Installation ist bereits durch eine einfache anonyme HTTP-Anfrage angreifbar. Und der Batch-Endpunkt der REST-APIs ist Teil des Kerns, standardmäßig aktiviert und ohne Authentifizierung erreichbar: Es handelt sich also nicht um einen Konfigurations-Sonderfall.
Die Ausführung von Code aus der Ferne ist die schwerwiegendste Klasse von Sicherheitslücken, die es gibt. Eine erfolgreiche Ausnutzung bedeutet in der Praxis, dass der Angreifer die Kontrolle über die Website erlangt.
Was kann ein Angreifer tun, und welche Folgen hat dies?
„Die Kontrolle über die Website übernehmen“ klingt abstrakt. Konkret bedeutet dies: Da ein Angreifer Code auf dem Server ausführen kann, ist er in der Lage:
- Versteckte Administratorkonten erstellen und den Zugriff auch nach einem Update aufrechterhalten.
- Persistente Backdoors installieren, die oberflächliche Bereinigungen überstehen.
- Daten aus der Datenbank stehlen: Kundenstammdaten, Bestellungen, E-Mail-Adressen, Passwörter (die, selbst wenn sie verschlüsselt sind, offline in Ruhe geknackt werden können).
- Weiterleitungen zu Malware- oder Betrugsseiten einfügen oder Spam und versteckte Links einbauen, die das Google-Ranking zerstören.
- Seiten verunstalten (Defacement) oder die Website offline nehmen.
- Deinen Server nutzen, um andere Websites anzugreifen oder Spam zu versenden, wodurch deine Domain auf Blocklisten landet.
- Zugriff auf andere Websites, die auf demselben Hosting-Server gehostet werden, sofern die Umgebung nicht isoliert ist.
- Die Website verschlüsseln oder sperren und Lösegeld fordern.
Ein oft unterschätztes Risiko betrifft API-Schlüssel. Wenn auf der Website oder dem Server Schlüssel für nutzungsabhängige Dienste konfiguriert sind – beispielsweise für KI-Modelle, den Versand von E-Mails oder SMS sowie Cloud-Dienste –, kann ein Angreifer, der Zugriff erlangt, diese stehlen und in Ihrem Namen nutzen. Die Folge kann eine sehr hohe Rechnung sein, die schnell fällig wird und vielleicht sogar eintrifft, bevor Sie den Einbruch überhaupt bemerken.
Und die eigentliche Rechnung kommt erst nach dem Angriff: Arbeitstage für die Bereinigung und Wiederherstellung, gegebenenfalls die Meldung an die Datenschutzbehörde, wenn personenbezogene Daten verletzt wurden (DSGVO), der Vertrauensverlust bei den Kunden und die Umsatzverluste, während die Website außer Betrieb oder kompromittiert ist.
Welche Versionen sind gefährdet?
Hier sorgen viele Artikel für Verwirrung, daher lohnt es sich, genau zu sein. Nicht alle WordPress-Versionen sind anfällig für die RCE-Kette.
| Version | Situation | Korrekte Version |
|---|---|---|
| 7.0.0 – 7.0.1 | Anfällig für beide Sicherheitslücken | 7.0.2 |
| 6.9.0 – 6.9.4 | Anfällig für beide Sicherheitslücken | 6.9.5 |
| 6.8.x | Nur anfällig für SQL-Injection | 6.8.6 |
| 7.1 Beta | Anfällig für beide Schwachstellen | 7.1 Beta 2 |
| Versionen vor 6.8 | Nicht betroffen | — |
Der für die RCE-Kette anfällige Code ist ab Version 6.9 vorhanden, die im Dezember 2025 veröffentlicht wurde. Eine Website, die eine ältere Version verwendet, ist dieser spezifischen Sicherheitslücke nicht ausgesetzt; das macht sie jedoch nicht sicher, da diese Versionen andere bekannte Probleme aufweisen.
Warum die Situation dringend ist
Angesichts der Schwere des Problems hat das Team von WordPress.org über das Auto-Update-System erzwungene Updates für Websites aktiviert, auf denen betroffene Versionen laufen. Dies ist eine außergewöhnliche Maßnahme, die nur ergriffen wird, wenn das Risiko konkret und weit verbreitet ist.
Searchlight Cyber hat die technischen Details des Exploits bewusst zurückgehalten, um den Administratoren Zeit für das Update zu geben, und lediglich ein öffentliches Überprüfungstool veröffentlicht. Doch bereits in den Stunden nach der Bekanntgabe wurden Proof-of-Concept-Angriffe gemeldet und erste Anzeichen für eine tatsächliche Ausnutzung beobachtet. Um es ganz klar zu sagen: Wenn eine Ihrer Websites auf einer betroffenen Version läuft, lautet die richtige Herangehensweise nicht „Ich aktualisiere sie, sobald ich Zeit habe“, sondern „Ich betrachte diese Website als gefährdet, bis sie aktualisiert ist“.
So überprüfst du deine Version in 30 Sekunden
Melde dich im WordPress-Dashboard an und schau in den Bereich „Auf einen Blick“: Dort wird die Version angezeigt. Alternativ findest du sie unter „Updates“ oder in der Datei readme.html im Stammverzeichnis der Installation. Wenn du viele Websites verwaltest, gibt es öffentliche Online-Prüfprogramme und Tools wie WPScan zum Scannen.
Was Sie sofort tun sollten
- Aktualisiere den Core. Über das Dashboard: „Updates“ → „Jetzt aktualisieren“. Wenn die Website automatische Updates unterstützt, hat der Vorgang möglicherweise bereits von selbst begonnen: Überprüfe dennoch, ob er erfolgreich war, da ein erzwungenes Update bei Installationen mit bestimmten Dateiberechtigungen stillschweigend fehlschlagen kann.
- Stelle sicher, dass du tatsächlich die richtige Version verwendest (7.0.2, 6.9.5 oder 6.8.6, je nach Zweig).
- Wiederhole diesen Vorgang auf allen von dir verwalteten Websites, einschließlich Staging-Umgebungen und vergessener Projekte. Eine verlassene Website auf demselben Server ist immer noch eine offene Tür.
Wenn du nicht sofort aktualisieren kannst
Das kommt vor: eine Website mit umfangreichen Anpassungen, bei der das Update zunächst getestet werden muss. In diesem Fall empfehlen die Forscher vorübergehende Maßnahmen, wie die Einschränkung des anonymen Zugriffs auf die REST-APIs oder das Blockieren von Anfragen an den Batch-Endpunkt auf Ebene der Webanwendungs-Firewall. Zwei Hinweise: Diese Abhilfemaßnahmen können legitime Integrationen, die die REST-APIs nutzen, beeinträchtigen; sie sind daher nur vorübergehende Notlösungen und kein Ersatz für das Update; außerdem kursiert das Gerücht, dass ein persistenter Objekt-Cache (Redis, Memcached) Schutz biete, doch dies ist kein Schutz und sollte auch nicht als solcher verstanden werden.
So stellen Sie fest, ob Sie kompromittiert wurden
Wenn Ihre Website nach der Bekanntgabe weiterhin auf einer anfälligen Version lief, schließt das Update zwar die Tür, beseitigt aber kein bereits erfolgtes Eindringen. Es lohnt sich, kürzlich hinzugefügte unbekannte Administratoren, Dateien, die zu verdächtigen Zeitpunkten geändert wurden (insbesondere im wp-content und im Stammverzeichnis) geänderte Dateien, die Zugriffsprotokolle zu den REST-Endpunkten sowie geplante Aktivitäten, die du nicht erkennst. Wenn du etwas findest, ist es nicht der richtige Weg, die Datei einfach zu löschen und auf das Beste zu hoffen: Es ist eine Wiederherstellung aus einem Backup vor dem Einbruch erforderlich, gefolgt von der Aktualisierung und dem Ändern aller Anmeldedaten.
Die Lehre daraus: Warum Wartung kein optionaler Kostenfaktor ist
Dieser Vorfall verdeutlicht einen Grundsatz, den ich meinen Kunden oft wiederhole: Die Sicherheit einer WordPress-Website ist kein Zustand, sondern ein Prozess.
Beachten Sie eines: Plugins spielen hier keine Rolle. Der klassische Ratschlag „Verwenden Sie nur wenige Plugins und halten Sie diese auf dem neuesten Stand“ ist zwar unumstößlich, hätte hier aber niemanden geschützt. Die Schwachstelle lag im Core, in Code, der standardmäßig bei jeder Installation aktiv ist. Die einzige wirkliche Abwehrmaßnahme bestand darin, das Update schnellstmöglich zu installieren.
Und hier zeigt sich der Unterschied zwischen einer gepflegten und einer vernachlässigten Website. Es ist keine Frage der Kompetenz des Betreibers: Es muss einfach jemand bemerken, dass ein kritisches Sicherheitsupdate erschienen ist, prüfen, welche Websites betroffen sind, das Update installieren und kontrollieren, ob es erfolgreich war. An einem Freitagabend im Sommer, während du gerade mit anderen Dingen beschäftigt bist.
Das Paradoxon einer gut gemachten Wartung ist, dass es so aussieht, als würde nichts passieren, wenn sie funktioniert. Tage wie dieser sind die Ausnahme, an denen man sieht, wozu sie gut ist.
Häufig gestellte Fragen
Häufig gestellte Fragen
Il mio sito si aggiorna da solo, sono a posto?
Probabilmente sì, perché per questa release sono stati attivati gli aggiornamenti forzati. Ma gli aggiornamenti automatici possono fallire, ad esempio per permessi sui file. Vale sempre la pena verificare la versione manualmente in bacheca.
Uso WordPress 6.8, sono vulnerabile?
Alla catena RCE no: quel codice esiste dalla 6.9. Sei però interessato dalla SQL injection, corretta nella 6.8.6. Aggiorna comunque.
Basta disattivare i plugin per proteggersi?
No. La vulnerabilità è nel core di WordPress, non in un plugin. Disattivare i plugin non cambia nulla.
Se ho Redis o Memcached sono al sicuro?
No. Il percorso di sfruttamento divulgato riguarda i casi senza cache a oggetti persistente, ma non va inteso come una protezione. L'unico rimedio è l'aggiornamento.
Come faccio a sapere se il mio sito è stato attaccato?
Controlla nuovi utenti amministratori, file modificati di recente e i log di accesso verso gli endpoint REST. In caso di dubbio, fatti dare un'occhiata da qualcuno che sa dove guardare.