WordPress unter Beschuss: Kritische WP2Shell-Lücke wird aktiv ausgenutzt

Das Wichtigste in Kürze

Was ist passiert?

WordPress hat mit Version 7.0.2 zwei Sicherheitsprobleme im Kern des Content-Management-Systems geschlossen. Die erste Schwachstelle, CVE-2026-60137, betrifft die Verarbeitung des Parameters author__not_in in WP_Query. Unzureichend bereinigte Eingaben können unter bestimmten Bedingungen eine SQL-Injection ermöglichen.

Die zweite Schwachstelle, CVE-2026-63030, verursacht eine Verwechslung von Routen im Batch-Endpunkt der WordPress-REST-API. In Kombination mit der SQL-Injection kann daraus eine nicht authentifizierte Remote Code Execution entstehen: Ein externer Angreifer benötigt weder ein WordPress-Konto noch eine Interaktion durch einen Administrator.

Welche WordPress-Versionen sind betroffen?

Die beiden CVEs haben unterschiedliche Versionsbereiche. Deshalb ist die pauschale Aussage «WordPress 6.8 bis 7.0 ist vollständig übernehmbar» falsch: Die kritische RCE-Kette beginnt erst mit WordPress 6.9. Die ältere 6.8-Linie enthält jedoch die separate SQL-Injection und muss ebenfalls aktualisiert werden.

So funktioniert die Angriffskette – vereinfacht erklärt

Die Bezeichnung «WP2Shell» steht nicht für einen einzelnen Programmfehler, sondern für die Kombination zweier Schwächen. Sicherheitsforscher konnten zeigen, dass die Route-Confusion der REST-API die normalerweise vorhandenen Einschränkungen der SQL-Injection aushebelt. Daraus entsteht ein Angriffsweg bis zur Kontrolle über die WordPress-Instanz.

Aus Sicherheitsgründen verzichteten WordPress und mehrere Anbieter zunächst auf tiefe technische Details. Trotzdem erschienen bereits kurz nach der Veröffentlichung der Patches zahlreiche Proof-of-Concept-Varianten. VulnCheck zählte bis zum 19. Juli mehr als zwei Dutzend unterschiedliche öffentliche Implementierungen und beobachtete ab dem 20. Juli Aktivitäten gegen produktive Systeme.

Aktive Angriffe: Wie belastbar sind die Meldungen?

Mehrere voneinander unabhängige Sicherheitsunternehmen berichten von Ausnutzungsversuchen. Patchstack, Hexastrike, WatchTowr und VulnCheck meldeten Angriffe beziehungsweise Treffer in Honeypots und Produktivumgebungen. Damit ist die Situation nicht mehr nur theoretisch: Verwundbare, öffentlich erreichbare Installationen müssen als akut gefährdet gelten.

Wie viele Websites tatsächlich noch verwundbar sind, ist dagegen unklar. TechCrunch verwies auf offizielle WordPress- Versionsstatistiken, nach denen sehr viele Installationen in den betroffenen Versionszweigen liefen. Eine Stichprobe von rund 3’500 Sites führte zu einer Schätzung von weniger als 15 Prozent verwundbarer Systeme und einer möglichen Grössenordnung von rund 90 Millionen Websites. Diese Zahl ist jedoch eine Hochrechnung, keine bestätigte Inventur – insbesondere, weil erzwungene Auto-Updates und Provider-Massnahmen die Lage laufend verändern.

Automatische Updates helfen – sind aber keine Garantie

Wegen der Schwere der Lücken hat das WordPress-Sicherheitsteam erzwungene Hintergrundupdates für betroffene Installationen aktiviert. Das ist ungewöhnlich und dürfte einen grossen Teil der Websites bereits geschützt haben. Dennoch können Updates scheitern oder bewusst blockiert sein – etwa durch Dateirechte, spezielle Hosting-Konfigurationen, deaktivierte automatische Aktualisierungen oder stark angepasste Installationen.

Cloudflare hat am 17. Juli neue WAF-Regeln für kostenlose und kostenpflichtige Kunden aktiviert, sofern der Webverkehr der Site über den Cloudflare-Proxy und die Web Application Firewall läuft. Diese Regeln reduzieren das Risiko während des Updates, ersetzen den Patch aber ausdrücklich nicht.

Was Betreiber jetzt sofort tun sollten

• Version kontrollieren: Im WordPress-Dashboard unter «Aktualisierungen» prüfen, ob mindestens 6.8.6, 6.9.5 oder 7.0.2 installiert ist.
• Core unverzüglich aktualisieren: Eine getestete Sicherung erstellen, den Patch aber nicht wegen eines aufwendigen Wartungsfensters unnötig verschieben.
• Managed Hosting verifizieren: Nicht nur auf eine allgemeine Statusmeldung des Providers vertrauen, sondern die Version jeder einzelnen Instanz prüfen.
• WAF als Zusatzschutz nutzen: Bereits bereitgestellte Regeln des Hosting- oder WAF-Anbieters aktivieren; sie dienen nur als Zwischenmassnahme.
• Administratoren prüfen: Unbekannte Admin-Konten, kürzlich angelegte Benutzer und unerwartete Rollenänderungen untersuchen.
• Dateien und Logs kontrollieren: Neue PHP-Dateien, Änderungen an Themes oder Plugins sowie auffällige REST-API-Batch-Anfragen untersuchen.
• Zugangsdaten wechseln: Bei Verdacht auf Kompromittierung WordPress-, Hosting-, Datenbank-, SFTP- und API-Zugangsdaten rotieren.
• Sauber wiederherstellen: Bei bestätigtem Einbruch nicht nur einzelne Dateien löschen, sondern die Instanz aus einer nachweislich sauberen Quelle neu aufbauen.

Nach dem Update: Wurde die Site bereits kompromittiert?

Ein Patch entfernt die Schwachstelle, aber nicht automatisch einen zuvor angelegten Administrator, eine Webshell oder manipulierte Inhalte. Besonders Websites, die nach dem 17. Juli noch mehrere Stunden oder Tage auf einer verwundbaren Version öffentlich erreichbar waren, sollten deshalb zusätzlich überprüft werden.

wp core version
wp core verify-checksums --include-root
wp user list --role=administrator

Prüfsummen erkennen Veränderungen an offiziellen WordPress-Core-Dateien, decken aber nicht automatisch alle Manipulationen in wp-content, der Datenbank oder serverweiten Konfigurationsdateien auf. Bei ernsthaften Verdachtsmomenten ist eine forensische Sicherung vor der Bereinigung sinnvoll.

Was die Lücke für Schweizer KMU und Agenturen bedeutet

Für Schweizer KMU, Vereine, Gemeinden und Agenturen ist das Risiko besonders relevant, weil WordPress-Installationen häufig über Jahre laufen und Wartung teilweise ausgelagert wird. Bei einem Angriff drohen nicht nur veränderte Webseiten, sondern auch gestohlene Kundendaten, kompromittierte Formulare, Phishing-Seiten, Suchmaschinen-Spam und der Missbrauch des Servers für weitere Angriffe.

Agenturen und Hosting-Dienstleister sollten nicht nur ihre eigenen Systeme, sondern sämtliche verwalteten Kundeninstanzen inventarisieren. Eine einzige vergessene Staging-Site, alte Kampagnen-Landingpage oder nicht mehr betreute Subdomain kann weiterhin öffentlich erreichbar sein und als Einstiegspunkt dienen.

Fazit: Patchen, prüfen und nicht bei der Versionsnummer aufhören

WP2Shell gehört zu den seltenen WordPress-Core-Problemen, bei denen eine Standardinstallation ohne verwundbares Plugin übernommen werden kann. Die gute Nachricht: WordPress, Hosting- und WAF-Anbieter reagierten schnell, Sicherheitsupdates stehen für alle betroffenen Versionszweige bereit und viele Installationen wurden automatisch aktualisiert.

Die schlechte Nachricht ist das nahezu sofortige Auftauchen öffentlicher Exploits und aktiver Angriffe. Betreiber sollten deshalb heute noch kontrollieren, ob ihre Site tatsächlich auf 7.0.2, 6.9.5 beziehungsweise 6.8.6 oder neuer läuft. War eine Installation nach der Veröffentlichung der Patches weiterhin verwundbar, gehört auch eine Kompromittierungsprüfung zum Pflichtprogramm. Nur zu aktualisieren und danach nichts weiter zu kontrollieren, kann einen bereits bestehenden Zugang der Angreifer unentdeckt lassen.

Quellen und Datenbasis

Die technische Einstufung und die Versionsbereiche basieren primär auf den offiziellen WordPress- und GitHub-Advisories. Angaben zur aktiven Ausnutzung stammen aus Beobachtungen mehrerer Sicherheitsanbieter. Schätzungen zur Zahl verwundbarer Websites sind mit hoher Unsicherheit verbunden und wurden entsprechend als Hochrechnungen gekennzeichnet.

1. Swiss IT Magazine: WordPress-Lecks – sofort aktualisieren
2. WordPress.org: WordPress 7.0.2 Security Release
3. GitHub Advisory: CVE-2026-60137
4. GitHub Advisory: CVE-2026-63030
5. Cloudflare: WAF-Schutz für die WordPress-Schwachstellen
6. VulnCheck: WP2Shell – Analyse und aktive Ausnutzung
7. SecurityWeek: WP2Shell wird aktiv ausgenutzt
8. TechCrunch: Schätzung zur Zahl potenziell verwundbarer Websites
9. WordPress Developer Resources: Core-Dateien mit WP-CLI prüfen