# WordPress 7.0 und die kritische WP2Shell-Lücke: Was passiert ist und was Sie jetzt tun sollten

> URL: https://4eck-media.de/blog/wordpress-7-0-und-die-kritische-wp2shell-luecke-was-passiert-ist-und-was-sie-jetzt-tun-sollten/  
> Language: de  
> Description: Es gibt Momente im Web, in denen der Unterschied zwischen „wir haben gehört, dass es ein Update gibt“ und „wir haben das Update wirklich eingespielt, verifiziert und die Logs gepr…

---

Es gibt Momente im Web, in denen der Unterschied zwischen „wir haben gehört, dass es ein Update gibt“ und „wir haben das Update wirklich eingespielt, verifiziert und die Logs geprüft“ über Reputation, Umsatz und Vertrauen entscheidet. Der Juli 2026 war so ein Moment.

WordPress betreibt den Löwenanteil des offenen Webs. Wenn im **Core** also nicht in einem randständigen Plugin, sondern im Kern des Systems eine Lücke auftaucht, die ohne Login und ohne speziellen Admin-Zugang ausgenutzt werden kann, dann geht es nicht um Panikmache. Es geht um Handwerk: Verstehen, Priorisieren, Schließen, Nachweisen.

Genau das ist unser Alltag bei 4eck Media. Seit 2010 bauen und betreiben wir technisch saubere WordPress- und WooCommerce-Systeme von mehrsprachigen Corporate Sites bis zu anspruchsvollen Shop- und Multisite-Architekturen. Und weil wir mit **TutKit.com** selbst eine Plattform mit bis zu 20.000 Nutzern täglich betreiben, kennen wir Security nicht aus der Broschüre, sondern aus dem Betrieb.

Für vergleichbare E-Commerce-Anforderungen entwickelt unsere [WooCommerce Agentur](https://4eck-media.de/kompetenzen/woocommerce-onlineshop-erstellen-lassen/) belastbare Prozesse statt kurzfristiger Plug-in-Lösungen.

## 1. Das Lagebild: warum diese Release anders war

Am 17. Juli 2026 veröffentlichte das WordPress-Security-Team mit **WordPress 7.0.2** ein Security Release, das *eine kritische* und *eine hohe* Schwachstelle adressiert. Parallel wurden Backports für die betroffenen Branches ausgeliefert:

- **7.0.x** → Update auf `7.0.2`
- **6.9.x** → Update auf `6.9.5`
- **6.8.x** → Update auf `6.8.6` (SQL Injection)

Die öffentliche Bezeichnung der Angriffskette lautet **WP2Shell**. Dahinter stecken zwei CVE-Einträge, die zusammen deutlich gefährlicher sind als einzeln:

- **CVE-2026-60137 (High):** Facilitated SQL Injection, Crafted Input kann Datenbankabfragen manipulieren. Betroffen ab WordPress 6.8. Gemeldet u. a. von TF1T, dtro und haongo.
- **CVE-2026-63030 (Critical):** Unauthentifizierte Remote Code Execution über Route Confusion im REST-API-Batch-Endpoint. Betroffen ab WordPress 6.9. Gemeldet von Adam Kues (Assetnote / Searchlight Cyber).

WordPress stufte die Lage als so gravierend ein, dass **erzwungene automatische Updates** für betroffene Installationen aktiviert wurden. Das ist kein Routine-Hinweis das ist der Sicherheitsgurt bei Vollbremsung. Trotzdem gilt: Auto-Update heißt nicht automatisch „erledigt“. Wer ernsthaft hostet, *verifiziert*.

Wichtig ist gleich von vornherein zu verstehen: Es kommt kein menschlicher Hacker auf Ihre Website und denkt sich, ich probiere mal einen Angriff. Es passiert automatisiert durch Bots, die ähnlich wie Suchmaschinencralwer das Web durchforsten und genau da reingehen, wo es möglich ist. Und dann werden neue Admins angelegt, für bestehende Admins die Passwörter geändert, Plugins/Schadsoftware installiert, Spamseiten (z. B. für Casino) tausendfach online gestellt etc.

## 2. Was genau passiert ist, technisch und verständlich

Viele Security-Posts bleiben bei „kritisch, bitte updaten“ stehen. Das ist zu wenig, wenn Sie als Entscheider oder IT-Verantwortlicher einschätzen müssen, ob Ihre Seite, Ihr Shop oder Ihr Multisite-Netzwerk wirklich sicher ist. Deshalb der Blick unter die Haube.

### CVE-2026-60137 SQL Injection über WP_Query

Die erste Schwachstelle betrifft die Art und Weise, wie WordPress in bestimmten Query-Parametern insbesondere im Umfeld von `author__not_in` und verwandten `WP_Query`-Pfaden Eingaben verarbeitet. Ein Angreifer kann crafted Input so formen, dass die generierte SQL-Abfrage nicht mehr nur „fragt“, sondern **manipuliert** wird.

SQL Injection im CMS-Kern ist aus zwei Gründen unangenehm: Erstens sitzt sie tief im Request-Handling und ist damit breit erreichbar. Zweitens ist sie oft der *Schlüssel* für weitere Schritte  Datenabzug, Session-Manipulation oder, wie hier, die Vorbereitung einer Code-Execution.

### CVE-2026-63030 REST-API Batch Route Confusion → RCE

Die zweite Lücke betrifft den **Batch-Endpoint der REST-API** (`/wp-json/batch/v1` bzw. den entsprechenden Batch-Mechanismus). Durch eine Route Confusion geraten Methode, Validierung und Berechtigungsprüfung aus dem Takt: Ein Request kann so „verkleidet“ werden, dass er Prüfungen umgeht und intern auf Pfade zugreift, die so nie anonym erreichbar sein sollten.

Entscheidend: In der beschriebenen Ausprägung ist für die kritische Remote-Code-Execution **keine Authentifizierung** nötig. Kein gestohlenes Admin-Passwort. Kein Phishing. Kein kompromittierter Redakteur-Account. Ein einzelner, geschickt gebauter HTTP-Request und auf anfälligen Systemen ohne passende Gegenmaßnahmen (u. a. abhängig vom Object-Cache-Setup) kann Code ausgeführt werden.

Genau diese Kombination SQL Injection plus Batch-Route-Confusion macht WP2Shell zu mehr als „nur einer SQLI“. Es ist eine **Angriffskette**, die auf einer Standardinstallation greifen kann: Core, ohne exotische Plugins, ohne vorherigen Zugriff.

## 3. Die Angriffskette wie aus zwei Bugs ein Übernahme-Szenario wird

In der Praxis sehen Security-Researcher typischerweise zwei Exploit-Muster:

1. **Direkt zur Shell:** Die Kette wird genutzt, um unmittelbar PHP-Code bzw. Systemkommandos im Kontext des Webservers auszuführen oft mit dem Ziel, Webshells abzulegen, Cronjobs zu missbrauchen oder Persistenz zu schaffen.
2. **Über Admin-Übernahme:** Alternativ werden Passwort-Hashes extrahiert, offline gebrochen oder Sessions manipuliert; anschließend landen Malware-Plugins, Backdoors in `wp-content`, manipulierter `mu-plugins`-Code oder geänderte Redirects im Theme.

Nach der öffentlichen Disclosure und dem Auftauchen von Proof-of-Concepts stieg die Ausnutzungswahrscheinlichkeit spürbar. Universitäten, Hosting-Provider und Security-Firmen warnten ausdrücklich: Aufgrund der geringen Angriffskomplexität sei eine breite Ausnutzung wahrscheinlich.

**Wichtig für Entscheider:** Eine WAF (Web Application Firewall) kann den Angriffsdruck senken. Cloudflare und andere haben Regeln ausgerollt. **Eine WAF ersetzt kein Core-Patch.** Wer nur auf Edge-Schutz setzt und den Core offen lässt, spekuliert mit der eigenen Domain.

## 4. Betroffene Versionen die Matrix, die Sie brauchen

Nicht jede WordPress-Version ist gleich betroffen. Die SQL Injection kommt ab 6.8, die volle RCE-Kette ab 6.9. Für den 7.0-Branch und genau dort stecken viele frisch relaunchte Projekte gilt:

| Branch | SQL Injection (CVE-2026-60137) | RCE-Kette (CVE-2026-63030) | Fix |
| --- | --- | --- | --- |
| 6.8.0 – 6.8.5 | betroffen | nein | 6.8.6 |
| 6.9.0 – 6.9.4 | betroffen | betroffen | 6.9.5 |
| 7.0.0 – 7.0.1 | betroffen | betroffen | 7.0.2 |
| < 6.8 | von dieser Kette nicht betroffen* | trotzdem aktuell halten |  |

*Ältere Versionen sind von *dieser* Kette nicht betroffen das macht sie nicht „sicher“. Veraltete Cores, Plugins und PHP-Stacks sind ein eigenes Risikouniversum.

Unsere [WordPress Agentur](https://4eck-media.de/kompetenzen/wordpress-agentur/) setzt vergleichbare Anforderungen als skalierbare, sichere und redaktionell gut pflegbare Lösung um.

## 5. Warum kein 4eck-Media-Kunde betroffen war und was das über Wartung sagt

Lassen Sie uns klar sein: Glück ist keine Strategie. Dass **kein einziges unserer betreuten Kundenprojekte** durch WP2Shell kompromittiert wurde, liegt an einem System nicht an Zufall.

Dieses System sieht in der Praxis so aus:

- **Aktive Core- und Plugin-Wartung:** Security-Releases werden priorisiert, getestet und eingespielt nicht „irgendwann im nächsten Sprint“.
- **Verifikation statt Annahme:** Wir prüfen die tatsächliche WordPress-Version im Dashboard, in der Datei `wp-includes/version.php` und über Monitoring. Auto-Update allein genügt uns nicht als Nachweis.
- **Technische Härtung:** Security Headers, restriktive Dateirechte, saubere Trennung von Staging und Produktion, gezielte Absicherung sensibler Endpunkte, Logging und wo sinnvoll  WAF/CDN-Schichten.
- **Betriebsverstand aus eigener Plattform:** Was wir Kunden empfehlen, betreiben wir selbst mit TutKit.com, PSD-Tutorials und Dutzenden Agenturprojekten seit 2002/2010.

Security ist bei uns kein einmaliger Audit-PDF, der in der Schublade landet. Sie ist Teil von Design, Entwicklung, Go-Live-Checkliste und laufender Betreuung. Genau deshalb können wir heute sagen: **Unsere Kunden waren von diesem Vorfall nicht betroffen.**

## 6. Lösungswege im Detail was Sie jetzt tun sollten

Egal ob Sie selbst hosten, einen Freelancer haben oder mit einer Agentur arbeiten: Die folgende Reihenfolge ist die, die in Incident-Response und sauberer Wartung funktioniert.

### Schritt 1: Version hard verifizieren

Melden Sie sich im WordPress-Backend an und prüfen Sie unter *Dashboard → Aktualisierungen* bzw. unten im Admin-Footer die Version. Zusätzlich:

- Datei `wp-includes/version.php` Feld `$wp_version`
- Hosting-Panel / WP-CLI: `wp core version`
- Externe Checker nur als Hinweis, nie als alleinige Wahrheit

Zielstände: **7.0.2+**, **6.9.5+** oder **6.8.6+** je nach Branch. Alles darunter ist offen.

### Schritt 2: Patch einspielen kontrolliert, aber zügig

Ideal: Staging → Smoke-Test (Login, Checkout, Formulare, kritische Custom-Flows) → Produktion → erneute Versionsprüfung. Wenn Staging fehlt und die Lücke kritisch ist: Produktion patchen und danach intensiv testen. Bei Security-Criticals ist „wir warten auf den nächsten Content-Sprint“ die teurere Option.

### Schritt 3: Temporäre Mitigations (nur bis der Patch steht)

- Batch-REST-Endpunkt am Reverse Proxy / WAF blocken (`/wp-json/batch` und Varianten)
- Anonyme REST-API-Zugriffe dort einschränken, wo das Business es erlaubt
- Managed-Rules der CDN/WAF aktiv halten
- Nach dem Patch Mitigations wieder so lockern, dass legitime Integrationen (Headless, mobile Apps, Automationen) nicht brechen

### Schritt 4: Kompromittierung ausschließen

Ein erfolgreiches Patchen heilt nicht automatisch eine bereits erfolgte Übernahme. Prüfen Sie:

- Unbekannte Administrator-Accounts und geänderte Rollen
- Neue/unbekannte Plugins, Must-Use-Plugins, Drop-ins
- Geänderte Core-Dateien (Integritätscheck / frische Core-Dateien)
- Verdächtige Cron-Jobs, Redirects, `.htaccess`, PHP-Dateien in Upload-Verzeichnissen
- Access-Logs rund um den Disclosure-Zeitraum (Batch-API, ungewöhnliche POST-Last)

Bei konkreten Indicators of Compromise: Isolation, forensische Sicherung, saubere Neuaufsetzung aus vertrauenswürdigem Backup + Patch + Passwort-Rotation nicht „irgendwas löschen und hoffen“.

### Schritt 5: Passwörter, Keys, Sessions rotieren (bei Verdacht zwingend)

Admin- und Editor-Passwörter, Application Passwords, FTP/SFTP, Hosting, Datenbank, CI/CD-Secrets, SMTP, Payment- und API-Keys. Sessions invalidieren. 2FA erzwingen, wo möglich.

### Schritt 6: Monitoring und Wartungsvertrag ernst nehmen

Der beste Zeitpunkt für einen Wartungsvertrag war vor dem Incident. Der zweitbeste ist jetzt. Uptime-Checks allein sind kein Security-Programm. Sie brauchen Update-Policy, Backup-Strategie mit Restore-Test, Logging, Alarmierung und jemanden, der um 9:12 Uhr nach einem Emergency-Release weiß, was zu tun ist.

## 7. Härtung darüber hinaus damit der nächste Incident leiser wird

WP2Shell ist ein Core-Ereignis. Die nächste kritische Lücke kann im Plugin stecken, im Theme, im Server-Stack oder in einer falsch konfigurierten Staging-Kopie, die öffentlich indexierbar ist. Deshalb arbeiten wir bei 4eck Media mit einem Härtungs-Mindeststandard:

- **Least Privilege:** so wenige Admin-Accounts wie möglich, getrennte Rollen, keine geteilten Passwörter.
- **Plugin-Hygiene:** nur was gebraucht wird, aktiv maintained, regelmäßig auditiert. Jedes tote Plugin ist Angriffsfläche.
- **Security Headers & Transport:** HSTS, CSP wo machbar, sichere Cookie-Flags, TLS-only.
- **Backups, die wiederherstellbar sind:** Versioniert, offsite, restore-getestet nicht nur „irgendwo im Hosting-Panel“.
- **Staging ≠ Produktion im Netz:** Auth, robots, separate Credentials, keine Kopie mit echten Kundendaten ohne Schutz.
- **Performance und Security zusammen denken:** PageSpeed und Core Web Vitals sind kein Widerspruch zu Härtung aufgeblähte Plugin-Friedhöfe schaden beidem.

## 8. Sie sind betroffen oder unsicher? Dann lassen Sie uns das sauber lösen

Nicht jedes Unternehmen hat ein internes Security-Team. Nicht jede „WordPress-Betreuung“ prüft nach einem Emergency-Release wirklich die Version. Wenn Sie unsicher sind, ob Ihre Installation auf 7.0.0 / 7.0.1 (oder einem anderen anfälligen Stand) hing, wenn Auto-Update bei Ihnen deaktiviert ist, wenn Logs merkwürdig aussehen oder das Backend sich „irgendwie anders“ anfühlt dann ist jetzt der Moment für professionelle Hilfe, nicht für Hoffnung.

**4eck Media unterstützt Unternehmen genau in diesen Situationen:**

- Sofort-Check: Version, Patch-Status, offensichtliche Compromise-Indikatoren
- Kontrolliertes Einspielen der Security-Releases inkl. Smoke-Tests
- Forensische Erstbewertung und bereinigte Wiederherstellung bei Vorfall
- Härtung, WAF/CDN-Abstimmung, Backup- und Update-Prozesse
- Laufende Wartung für WordPress, WooCommerce, Multisite und mehrsprachige Setups

Wir sind die Tech-Agentur aus Waren (Müritz) für professionelle WordPress-Entwicklung, WooCommerce, PageSpeed, Barrierefreiheit, SEO und GEO. Über 350 Kundenprojekte seit 2010. Und bei Security gilt für uns derselbe Maßstab wie bei Performance: **messbar, nachvollziehbar, betrieben nicht behauptet.**

Unsere eigenen Kunden waren von WP2Shell nicht betroffen. Wenn Sie es waren oder den Beweis brauchen, dass Sie es nicht sind sprechen Sie uns an. Wir schließen die Lücke, räumen auf und bauen den Betrieb so, dass der nächste Security-Freitag bei Ihnen kein Notfall wird.

*Quellen & Hinweis: Grundlage dieses Beitrags u. a. das offizielle WordPress 7.0.2 Security Release (17.07.2026), Advisories zu CVE-2026-60137 und CVE-2026-63030 (WP2Shell), Analysen von Searchlight Cyber / Assetnote, Cloudflare, Rapid7 sowie Hochschul- und Hosting-Security-Alerts. Dieser Artikel ersetzt keine individuelle forensische Analyse. Bei konkretem Vorfall: System isolieren und Fachleute hinzuziehen.*