Author Image
Marcel Denzin
Datum Juli 28, 2026

BSI-Warnung: Kritische WordPress-Sicherheitslücke „WP2Shell“ – jetzt handeln

Banner

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt aktuell vor zwei WordPress-Schwachstellen, die sich einzeln schon ernst nehmen lassen – in Kombination aber deutlich gefährlicher werden. Zusammen ermöglichen sie Angreifern die vollständige Übernahme einer Website: ohne Login, ohne zusätzliches Plugin, ohne jede Vorbedingung. Wenn du eine der betroffenen Versionen einsetzt, prüfe das heute – nicht erst nächste Woche.

Genau dieser Aufschub ist das Problem. Die meisten erfolgreichen Angriffe passieren nicht, weil kein Patch existiert, sondern weil der vorhandene Patch nicht eingespielt wurde.

Was ist passiert?

Am 17.07.2026 hat WordPress ein außerplanmäßiges Sicherheitsupdate veröffentlicht. Es schließt zwei Schwachstellen, die zunächst unabhängig voneinander entdeckt wurden:

CVE-2026-60137 – SQL-Injection in WP_Query. Der Parameter author__not_in wird nicht ausreichend geprüft, bevor er in eine Datenbankabfrage einfließt. WP_Query ist eine der zentralen Klassen im WordPress-Kern – über sie laufen unzählige Abfragen an die Datenbank. Eine SQL-Injection bedeutet vereinfacht: Ein Angreifer schleust eigene Datenbankbefehle in eine eigentlich harmlose Anfrage ein und kann so Daten auslesen oder verändern, die er nie zu sehen bekommen sollte.

CVE-2026-63030 („WP2Shell“) – Schwachstelle in der REST-API. Betroffen ist der Batch-Endpunkt /wp-json/batch/v1. Über ihn lassen sich Anfragen so umleiten, dass sie mit erhöhten Rechten verarbeitet werden – also mit Berechtigungen, die der Anfragende eigentlich gar nicht hat.

Jede der beiden Lücken ist für sich genommen kritisch. Der eigentliche Sprengstoff liegt aber in der Kette: Kombiniert man SQL-Injection und REST-API-Lücke, entsteht daraus eine nicht authentifizierte Remote Code Execution (RCE). Im Klartext heißt das: Ein Angreifer kann aus der Ferne beliebigen Programmcode auf dem Server ausführen – und damit die Website und, je nach Serverkonfiguration, auch benachbarte Systeme übernehmen. „Nicht authentifiziert“ ist dabei der entscheidende Teil: Es braucht kein gestohlenes Passwort und keinen Nutzer-Account. Der offene Zugang genügt.

Vom Patch zum Exploit in wenigen Tagen

Seit dem Wochenende nach der Veröffentlichung haben Sicherheitsforscher mehrerer Firmen – unter anderem Searchlight Cyber, VulnCheck, PatchStack und Rapid7 – die Schwachstelle im Detail auseinandergenommen. Das Ergebnis fiel eindeutig aus: Innerhalb weniger Tage tauchten funktionsfähige Exploit-Codes öffentlich auf GitHub auf, und kurz darauf lagen erste Berichte über aktive Ausnutzung „in freier Wildbahn“ vor. Das BSI hat seine Cybersicherheitswarnung deshalb am 20.07.2026 aktualisiert und die Einstufung bekräftigt.

Dieser kurze Weg vom Sicherheitsupdate zum einsatzbereiten Angriffswerkzeug ist typisch – und der Grund, warum „später updaten“ bei kritischen Lücken selten eine gute Idee ist. Sobald ein Patch öffentlich ist, können Angreifer daraus rückwärts ableiten, welche Stelle geschlossen wurde, und gezielt nach Servern suchen, die noch nicht aktualisiert haben.

Warum das für dein Unternehmen relevant ist

WordPress betreibt einen erheblichen Teil aller Websites weltweit – vom kleinen Unternehmensblog über die Firmen-Präsenz bis zum Onlineshop. Diese Verbreitung ist im Alltag praktisch, im Ernstfall aber ein Risiko: Angreifer müssen keine einzelne Seite ins Visier nehmen, sie können mit automatisierten Scannern das gesamte Netz nach verwundbaren Installationen absuchen.

Drei Punkte machen genau diese Lücke zu einem der kritischeren WordPress-Vorfälle der letzten Jahre:

  • Keine Authentifizierung nötig – der Angreifer braucht keinen Zugang und kein Passwort.
  • Standardinstallation bereits angreifbar – es muss kein exotisches Plugin und keine ungewöhnliche Konfiguration vorliegen.
  • Öffentlich verfügbarer Exploit-Code – die Hürde für Angreifer ist minimal, das nötige Werkzeug liegt frei vor.

Ein erfolgreicher Angriff kann konkret bedeuten: das Auslesen der Datenbank inklusive der Passwort-Hashes aller Nutzer, das Anlegen eines versteckten Admin-Accounts, das Einschleusen von Schadcode (etwa für Spam, Phishing oder Weiterleitungen auf betrügerische Seiten), den kompletten Ausfall der Website – oder, im schlimmsten Fall, einen meldepflichtigen Datenschutzvorfall nach DSGVO. Werden dabei personenbezogene Daten kompromittiert, greift in der Regel die 72-Stunden-Meldefrist an die zuständige Datenschutz-Aufsichtsbehörde. Der Reputationsschaden kommt zum technischen Schaden noch hinzu.

Betroffene Versionen im Überblick

WordPress-Version Betroffen von
6.8.0 – 6.8.5 nur CVE-2026-60137 (SQL-Injection)
6.9.0 – 6.9.4 vollständige Angriffskette (RCE)
7.0.0 – 7.0.1 vollständige Angriffskette (RCE)
7.1 Beta vollständige Angriffskette (RCE)

Nicht betroffen bzw. bereits behoben sind die Versionen 6.8.6, 6.9.5, 7.0.2 sowie 7.1 Beta2. Wenn deine Installation auf einem dieser Stände (oder neuer) läuft, bist du auf der sicheren Seite – ein kurzer Blick ins Dashboard schafft in unter einer Minute Klarheit.

Was du jetzt tun solltest

1. WordPress-Version prüfen und aktualisieren. WordPress.org hat für viele Installationen automatische Zwangsupdates ausgerollt. Das ist gut, ersetzt aber keine manuelle Kontrolle – automatische Updates scheitern häufiger, als man denkt, etwa an Dateiberechtigungen oder Konflikten mit Themes. Prüfe im Adminbereich unter Dashboard → Aktualisierungen, ob deine Installation tatsächlich auf 6.8.6, 6.9.5 oder 7.0.2 (bzw. neuer) steht. Die aktuelle Versionsnummer findest du außerdem unten rechts im Dashboard.

2. Vor dem Update ein Backup ziehen. Sichere Datenbank und Dateien, bevor du aktualisierst. Sollte beim Einspielen etwas schiefgehen, kannst du sauber zurück – und im Fall einer bereits erfolgten Kompromittierung hast du einen sauberen Vergleichsstand.

3. Bei Verzögerung Übergangsmaßnahmen setzen. Lässt sich das Update nicht sofort einspielen, kannst du den betroffenen REST-API-Endpunkt (/wp-json/batch/v1 bzw. ?rest_route=/batch/v1) vorübergehend über eine Web Application Firewall blockieren – zum Beispiel über eine entsprechende Cloudflare-WAF-Regel. Das ist ausdrücklich eine Notlösung, kein Ersatz für den Patch.

4. Auf Kompromittierung prüfen. Weil bereits aktive Angriffe gemeldet werden, reicht das Update allein nicht aus. Kontrolliere nach dem Patch auf unbekannte Admin-Accounts, kürzlich veränderte oder neu angelegte Dateien und ungewöhnliche Datenbankeinträge. Wenn dir dabei etwas seltsam vorkommt, zieh im Zweifel Unterstützung hinzu, bevor du Spuren überschreibst.

5. Mehrere Installationen zentral im Blick behalten. Wenn du mehrere Seiten betreust – etwa für verschiedene Marken, Standorte oder Tochtergesellschaften – erfasse den Patch-Status zentral, statt dich auf Einzelmeldungen zu verlassen. Genau die eine Installation, an die niemand denkt, wird erfahrungsgemäß zuerst getroffen.

Unsere Empfehlung

Gerade wenn die Website nebenbei mitläuft und niemand hauptamtlich für IT-Sicherheit zuständig ist, entsteht das Risiko fast von selbst. Das Update landet auf dem „mache ich nächste Woche“-Stapel – und genau in diesem Zeitfenster passieren die meisten erfolgreichen Angriffe.

Wir prüfen für dich kurzfristig, ob deine WordPress-Installation betroffen ist, spielen die notwendigen Updates ein und richten bei Bedarf zusätzliche Schutzmaßnahmen ein, etwa über Cloudflare. Melde dich einfach, wenn du unsicher bist, ob deine Website aktuell und sauber ist – eine kurze Prüfung ist allemal günstiger als ein Ernstfall.

Quelle: BSI-Cybersicherheitswarnung 2026-271984-1032 (Version 1.1, Stand 20.07.2026)

Häufig gestellte Fragen

Schnelle Antworten, nur einen Klick entfernt

„WP2Shell" ist der inoffizielle Name für die Schwachstelle CVE-2026-63030 im REST-API-Batch-Endpunkt von WordPress. In Kombination mit der SQL-Injection CVE-2026-60137 ermöglicht sie eine nicht authentifizierte Remote Code Execution – ein Angreifer kann also ohne Login beliebigen Code auf dem Server ausführen und die Website übernehmen.

Von der SQL-Injection sind die Versionen 6.8.0 bis 6.8.5 betroffen. Die vollständige Angriffskette mit Remote Code Execution betrifft die Versionen 6.9.0 bis 6.9.4, 7.0.0 bis 7.0.1 sowie 7.1 Beta. Behoben ist die Lücke in 6.8.6, 6.9.5, 7.0.2 und 7.1 Beta2.

Deine Versionsnummer findest du im WordPress-Adminbereich unter „Dashboard → Aktualisierungen" oder unten rechts im Dashboard-Fußbereich. Steht dort 6.8.6, 6.9.5, 7.0.2 oder neuer, bist du vor dieser Lücke geschützt.

Ja. Die Schwachstelle steckt im WordPress-Kern, nicht in einem Plugin. Schon eine Standardinstallation ohne zusätzliche Erweiterungen ist angreifbar, sofern sie auf einer der betroffenen Versionen läuft.

Nicht zwingend. WordPress.org hat für viele Installationen automatische Zwangsupdates ausgerollt, aber diese scheitern gelegentlich an Dateiberechtigungen oder Theme-Konflikten. Kontrolliere die Versionsnummer deshalb manuell im Dashboard, statt dich blind auf das Auto-Update zu verlassen.

Als Übergangslösung kannst du den betroffenen REST-API-Endpunkt (/wp-json/batch/v1 bzw. ?rest_route=/batch/v1) über eine Web Application Firewall blockieren, etwa mit einer Cloudflare-WAF-Regel. Das verschafft Zeit, ersetzt aber nicht das eigentliche Sicherheitsupdate.

Typische Anzeichen sind unbekannte Administrator-Konten, kürzlich geänderte oder neu angelegte Dateien, ungewöhnliche Einträge in der Datenbank sowie unerklärliche Weiterleitungen oder Spam-Inhalte. Prüfe diese Punkte auch dann, wenn du bereits aktualisiert hast – das Update entfernt keinen Schadcode, der vor dem Patch eingeschleust wurde.

Wenn bei einem erfolgreichen Angriff personenbezogene Daten betroffen sind, liegt in der Regel ein meldepflichtiger Datenschutzvorfall vor. Dieser muss der zuständigen Aufsichtsbehörde grundsätzlich innerhalb von 72 Stunden gemeldet werden. Im Zweifel solltest du frühzeitig rechtlichen Rat einholen.

Hast du Fragen?

Als Full-Service Online-Marketing-Agentur unterstützen wir dich gerne.

Das könnte dich auch interessieren: