Kritische Sicherheitslücke im WordPress-Core ermöglicht Remote Code Execution (RCE) – was passiert ist und was Betreiber einer möglicherweise gehackten WordPress-Webseite wissen sollten.
Was ist im Juli 2026 bei WordPress passiert?
Am 17. Juli 2026 veröffentlichte WordPress ein Sicherheitsrelease für eine kritische und eine hochgradige Sicherheitslücke im WordPress-Core. Besonders problematisch war die Kombination aus einer SQL-Injection und einer Schwachstelle bei REST-API-Batch-Routen.
Die als CVE-2026-63030 geführte Schwachstelle konnte in Verbindung mit CVE-2026-60137 zu Remote Code Execution (RCE) führen. Vereinfacht bedeutet das: Unter bestimmten Voraussetzungen konnte ein Angreifer eigenen Schadcode auf dem Server ausführen und eine WordPress-Installation dadurch weitgehend kompromittieren.
„Aus einer manipulierten Anfrage konnte unter bestimmten Bedingungen ein Angriff entstehen, bei dem nicht mehr nur Daten ausgelesen oder verändert werden, sondern Schadcode auf dem Server ausgeführt werden kann.“
WordPress stufte die Sicherheitsprobleme als kritisch bzw. hochgradig ein. Für CVE-2026-63030 wird im National Vulnerability Database (NVD) ein CVSS-Score von 9,8 angegeben.
Betroffen waren insbesondere WordPress-Versionen der Reihen 6.8, 6.9 und 7.0. Die entsprechenden Sicherheitsupdates wurden mit 6.8.6, 6.9.5 und 7.0.2 veröffentlicht. WordPress aktivierte aufgrund der Schwere der Schwachstellen außerdem erzwungene automatische Updates für betroffene Installationen.
Was wir bei Kundenseiten von Nicore Design festgestellt haben
Auch einige von Nicore Design betreute WordPress-Kundenseiten (ohne Wartungsvertrag oder Sicherheitspaket) waren von den Angriffen beziehungsweise deren Auswirkungen betroffen.
Der Vorfall fiel genau in unsere Urlaubszeit von Juli bis August. Gleichzeitig häuften sich die automatisierten Status- und Sicherheitsmeldungen unserer Firewalls sowie Anfragen an unseren WordPress-Notdienst. Bei einigen Webseiten waren sowohl Frontend als auch WordPress-Backend nicht mehr erreichbar.
Vorhandene Firewalls und automatische Backups konnten bei den betroffenen Kundenseiten den Schaden jedoch deutlich begrenzen und eine Wiederherstellung aus einem vorhandenen Sicherungsstand ermöglichen.
- Da es im Internet noch keine genaue Auflistung der Auswirkungen gibt, haben wir unsere Erfahrungen aus Kundenseiten und Notdienst-Anfragen ausgewertet.
Auswertung über die WordPress-Kompromittierungen:
Was wir bei kompromittierten WordPress-Webseiten bereits tun konnten
Nach Analyse mehrerer Webseiten fanden wir Muster und konnten uns gezielt auf die Suche machen.
- infizierte Dateien durch Abgleich mit dem WordPress-Core identifizieren (Zeitstempel, Dateigröße, Zugriffsrechte)
- Schadcode analysieren, Verschlüsselungen decodieren und nach Rückwärtssuche reparieren
- Datenbank von schädlichen Einträgen säubern
- SEO-Spam-Angriffe stoppen und Seitenindexierung korrigieren
Wenn es brennt: Welcher Hoster löscht das Feuer?
Bei einem WordPress-Angriff zählt nicht nur, wie gut ein Hoster wirbt, sondern was passiert, wenn eine Website tatsächlich kompromittiert wurde. Unsere Erfahrungen mit betroffenen Kundenseiten bei verschiedenen Hostern zeigen deutliche Unterschiede und wir vergeben dafür ein persönliches Ranking.
- Hetzner: hat umgehend mit automatischer PHP-Skript-Sperre reagiert, die Webseite wurde in Quarantäne versetzt und hinter einem Passwortschutz für die Öffentlichkeit gesperrt
- Alphahosting: der Kundensupport hat sich 3 Wochen nach Infizierung persönlich per E-Mail gemeldet und auf eine mehr als offensichtlich fremde PHP-Datei im Stammverzeichnis hingewiesen » die infizierten WordPress-Dateien wurden nicht erkannt und die Webseite war generell nicht erreichbar (Serverfehler 500)
- IONOS: hat ca. 1 Monat nach der Infizierung E-Mail an Kunden gesendet, dass der „Site Scan von SiteLock (Basisversion)“ verdächtige Scripte gefunden hat, weitere Information wären im vollständigen Scanbericht im Kundenbereich, wo aber kein Scanbericht zu einzelnen Dateien zu finden war, sondern nur allgemeine Hinweise
Anmerkung: für den „Site Scan“ ist es z.B. schon eine Gefährdung, dass WordPress und Plugins generell verwendet werden und man versucht immer wieder das kostenpflichtiges Upgrade zu verkaufen, diese E-Mail erhalten Kunden regelmäßig - Bytecamp: hat einen Malware-Scanner welcher im Kundenbereich mit regelmäßigen automatischen Scans beschrieben wird » die vollständig infizierte Webseite und mehrere zusätzlichen Ordern + Dateien wurden nicht erkannt und es stand nach wie vor „Es wurde keine Malware auf Ihrem Webspace gefunden.“ im Status
- Strato: keine Reaktion von irgendeiner Seite
Fazit: Was bei diesen Anbietern fehlt, die teils spezialisiertes WordPress-Hosting anbieten, ist der sogenannte „WP Checksum“. Diese Funktion überprüft die Dateiintegrität von WordPress, um fehlende oder manipulierte Dateien im Core, bei Plugins oder Themes zu erkennen, aufzulisten und ggf. gleich zu entfernen bzw. den Core durch die aktuellste Version von WordPress zu ersetzen. Anbieter mit einem Malware-Scanner bieten keine Möglichkeit einen Scan manuell anzustoßen.
Update 02.09.2026: Mal eine positive Nachricht! Auf Nachfrage bei Kunden und Geschäftspartnern stellte sich heraus, dass Webseiten, welche mit dem Sicherheitsnetzwerk Cloudflare abgesichert waren, nicht kompromittiert wurden. Laut Protokoll wurden Angriffe auf die beiden Sicherheitslücken CVE-2026-63030 und CVE-2026-60137 direkt abgeblockt.
Fazit zum Juli 2026 Exploit
Die Kombination von veränderten WordPress-Core Dateien, dem versteckten Platzieren von zusätzlichen Dateien und der Veränderung von Zugriffsrechten (Lesen, Schreiben, Ausführen) führte dazu, dass WordPress-basierende Firewalls und Malware-Scanner (in der kostenlosen Version) diese Infizierungen nicht (vollständig) erkannten oder Tiefenscans nicht vollständig durchführen konnten.
- selbst über externe FTP-Zugänge oder dem Web-FTP von einigen Hostern konnten Dateien nicht gelöscht werden
- infizierte Dateien haben sich selbst immunisiert und immer wieder Datenbankeinträge oder weitere Dateien erzeugt
- Seitenaufrufe durch Besucher haben den Schadcode immer wieder ausgeführt
- Cron-Jobs haben automatisiert den Schadcode ausgeführt
Was tun, wenn WordPress gehackt wurde?
Wenn eine WordPress-Webseite plötzlich nicht mehr funktioniert oder konkrete Hinweise auf einen Angriff vorliegen, sollte die WordPress-Instanzen nicht einfach nur neu installiert oder ein beliebiges Backup eingespielt werden.
Sinnvoll ist eine systematische Prüfung von:
- WordPress-Core und benutzerdefinierte Dateien
- Plugins und Themes
- Datenbank und verdächtigen Einträgen
- WordPress-Benutzern und Administratoren
- WP-Cron und geplanten Aufgaben
- Firewall- und Server-Logs
- vorhandenen Backups
Ein vorhandenes Backup ist besonders hilfreich, sollte aber vor der Wiederherstellung darauf geprüft werden, ob es aus einem Zeitpunkt vor der möglichen Kompromittierung stammt. In diesem aktuellen Fall waren nur Datenbank-Backups vor dem 17. Juli nutzbar.
FAQ zur WordPress-Sicherheitslücke im Juli 2026
Am 17. Juli 2026 veröffentlichte WordPress ein Sicherheitsrelease mit mehreren Sicherheitskorrekturen. Besonders relevant waren eine SQL-Injection sowie eine REST-API-Batch-Routen-Verwechslung in Verbindung mit SQL-Injection, die zu Remote Code Execution führen konnte.
Remote Code Execution bedeutet, dass ein Angreifer unter bestimmten Voraussetzungen eigenen Code auf einem entfernten System ausführen kann. Bei einer WordPress-Webseite kann dies eine weitreichende Kompromittierung der Installation ermöglichen.
Die RCE-relevante Schwachstelle ist als CVE-2026-63030 registriert. Die damit kombinierbare SQL-Injection wird unter CVE-2026-60137 geführt.
WordPress bezeichnete das Sicherheitsrelease vom 17. Juli 2026 als Release mit einem kritischen und einem hochgradigen Sicherheitsproblem. Für CVE-2026-63030 weist NVD einen CVSS-Score von 9,8 aus und stuft die Schwachstelle damit als kritisch ein.
WordPress 6.9 war von beiden Sicherheitsproblemen betroffen. WordPress 6.8 war von der SQL-Injection betroffen. Für WordPress 7.0 wurde das Sicherheitsupdate 7.0.2 veröffentlicht. Die entsprechenden behobenen Versionen waren 6.9.5, 6.8.6 und 7.0.2.
Das Sicherheitsupdate schließt die betreffende Schwachstelle. Wenn eine Webseite jedoch bereits vor dem Update kompromittiert wurde, entfernt ein Update nicht automatisch bereits eingeschleusten Schadcode. In diesem Fall sollte die Installation zusätzlich auf manipulierte Dateien, Datenbankeinträge, Benutzerkonten und andere Hinterlassenschaften untersucht werden.
Hinweise können unter anderem eine plötzlich nicht erreichbare Webseite, unbekannte Administratoren, veränderte Inhalte, Weiterleitungen, verdächtige Dateien oder ungewöhnliche Firewall- und Servermeldungen sein. Keines dieser Merkmale ist allein ein sicherer Beweis für einen Angriff. Bei einem konkreten Verdacht ist eine technische Untersuchung erforderlich.
Eine Firewall kann viele bekannte oder verdächtige Angriffe erkennen und blockieren und liefert wichtige Informationen über Angriffsversuche. Sie ersetzt jedoch weder Sicherheitsupdates noch Backups. Gerade bei einem Vorfall wie im Juli 2026 können mehrere Schutzebenen entscheidend sein.
Mit einem sauberen Backup kann eine kompromittierte WordPress-Webseite auf einen bekannten Zustand vor dem Angriff zurückgesetzt werden. Entscheidend ist dabei, dass der Sicherungsstand selbst nicht bereits kompromittiert wurde.
Zunächst sollte geklärt werden, ob ein technisches Problem oder eine mögliche Kompromittierung vorliegt. Bei einem Sicherheitsverdacht sollten vorhandene Firewall- und Servermeldungen gesichert, Backups geprüft und die Installation technisch untersucht werden. Ein vorschnelles Löschen oder Überschreiben der Installation kann wichtige forensische Hinweise beseitigen.
Die Mischung macht das Gift
Wichtig: Eine nicht erreichbare WordPress-Webseite ist nicht automatisch gehackt. Manchmal werden durch automatische Updates von WordPress-Core, Theme, Plugins oder PHP-Version Inkompatibilitäten erzeugt und die Webseite läuft auf einen PHP-Fehler oder kritischen Fehler. Bei einem konkreten Verdacht sollten jedoch Dateien, Datenbank, Benutzerkonten und Server- bzw. Firewall-Logs überprüft werden!