WP2Shell: Kritische WordPress-Sicherheitslücke in Version 7.0 – was passiert ist und was Sie jetzt tun sollten

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.

Die als WP2Shell bekannte WordPress-Sicherheitslücke ist eine Angriffskette, die auf betroffenen Versionen ohne Anmeldung zur Ausführung von Schadcode führen kann.

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 belastbare Prozesse statt kurzfristiger Plug-in-Lösungen.

WP2Shell im Überblick: Warum das Sicherheitsupdate auf WordPress 7.0.2 so wichtig ist

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 Suchmaschinen-Crawler 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.

Wie die WP2Shell-Sicherheitslücke technisch funktioniert

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 führt zu 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. Eine kurze, geschickt gebaute Folge unauthentifizierter HTTP-Requests kann auf anfälligen Systemen ohne passende Gegenmaßnahmen (u. a. abhängig vom Object-Cache-Setup) zur Ausführung von Schadcode führen.

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.

WP2Shell-Angriffskette: Wie zwei Schwachstellen WordPress übernehmen können

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

1. Initialer Zugriff: Die Angriffskette kombiniert die REST-Batch-Route-Confusion mit der SQL-Injection in einer kurzen Folge unauthentifizierter Requests. Es handelt sich nicht um einen einzelnen „Magic Request“.
2. Übernahme und Persistenz: Die öffentlich beschriebene Kette kann temporäre administrative Berechtigungen missbrauchen, einen neuen Administrator anlegen und anschließend ein Backdoor-Plugin hochladen. Danach sind Webshells, manipulierte Cronjobs oder weitere Persistenzmechanismen möglich.

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 WordPress-Sicherheitsupdate. Wer nur auf Edge-Schutz setzt und den Core offen lässt, spekuliert mit der eigenen Domain.

Betroffene WordPress-Versionen: Wer auf 7.0.2, 6.9.5 oder 6.8.6 aktualisieren muss

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:

WordPress 7.0.0 und 7.0.1 müssen mindestens auf WordPress 7.0.2 aktualisiert werden.

*Ä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 setzt vergleichbare Anforderungen als skalierbare, sichere und redaktionell gut pflegbare Lösung um.

Warum kein 4eck-Media-Kunde betroffen war: WordPress-Wartung statt Glück

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.

WordPress sicher betreiben

Diese Beiträge zeigen, wie aktuelle Software, systematische Sicherheitsprüfungen, belastbare Backups und saubere Konfiguration das Risiko durch WordPress-Schwachstellen und Ausfälle messbar reduzieren.

Website-Launch-Checkliste: Was Qualität nach dem Go-live von Pfusch unterscheidet

Matthias Petri

Website prüfen: die 10 Tools, mit denen wir jede Website testen, vor und nach dem Go-live

Matthias Petri

Website-Checkliste vor dem Go-live: Was wir prüfen, bevor eine Website online gehen darf

Matthias Petri

JavaScript-SEO: Herausforderungen für Web-Entwickler und SEO-Manager

Matthias Petri

WordPress-Sicherheitslücke schließen: Diese sechs Schritte sind jetzt nötig

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: WordPress-Version zuverlässig prüfen

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: WordPress-Sicherheitsupdate kontrolliert einspielen

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 Schutzmaßnahmen bis zum Patch

• 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: WordPress auf eine Kompromittierung prüfen

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, Schlüssel und Sessions rotieren

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 WordPress-Wartung dauerhaft etablieren

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.

WordPress härten: So bleibt der nächste Sicherheitsvorfall beherrschbar

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.

WP2Shell-Verdacht? WordPress prüfen, bereinigen und absichern lassen

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.