Am 17. Juli hat das WordPress-Projekt Sicherheitsupdates veröffentlicht. Wenige Stunden später kursierte fertiger Angriffscode, kurz danach liefen die ersten Attacken. Das Bundesamt für Sicherheit in der Informationstechnik hat die Lücke inzwischen mit Warnstufe Orange bewertet und weist ausdrücklich auf die Ausnutzung in freier Wildbahn hin.

Die Kombination trägt den Namen wp2shell. Sie erlaubt es, ohne Login Schadcode auf einer WordPress-Seite auszuführen. Wenn Sie eine WordPress-Website betreiben und in den letzten zwei Wochen nicht aktualisiert haben, ist dieser Beitrag der wichtigste, den Sie heute lesen.

Was genau passiert ist

wp2shell ist keine einzelne Schwachstelle, sondern eine Kette aus zwei Fehlern, die einzeln unangenehm und zusammen fatal sind:

  • CVE-2026-60137 – eine SQL-Injection im Parameter author__not_in von WP_Query. Also in genau der Klasse, die praktisch jede Datenbankabfrage in WordPress zusammensetzt.
  • CVE-2026-63030 – eine Verwechslung von Routen in der Batch-Schnittstelle der REST-API (WP_REST_Server::serve_batch_request_v1()). Darüber lässt sich Code ausführen.

Verkettet ergibt das eine unauthentifizierte Codeausführung: Der Angreifer braucht keinen Zugang, kein Passwort, keinen Benutzer. Ein Aufruf genügt. Das BSI bewertet die Kette mit einem CVSS-Wert von 9.8 von 10 – höher geht es praktisch nicht. Beobachtet wurde, dass Angreifer sich anschließend dauerhafte Hintertüren einrichten, sogenannte Webshells.

Betroffene und korrigierte Versionen

Die Codeausführungs-Lücke betrifft WordPress 6.9.0 bis 6.9.4 sowie 7.0.0 und 7.0.1. Die SQL-Injection reicht weiter zurück und schließt zusätzlich 6.8.0 bis 6.8.5 ein.

Korrigiert ist beides in 6.8.6, 6.9.5 und 7.0.2 – erschienen am 17. Juli 2026.

Was WordPress-Betreiber jetzt tun sollten

Der Reihenfolge nach:

  • Aktualisieren, sofort. Auf 6.8.6, 6.9.5 oder 7.0.2, je nach Zweig. Automatische Updates für Kernversionen sind bei vielen Installationen abgeschaltet – verlassen Sie sich nicht darauf, sondern schauen Sie nach.
  • Von einer Kompromittierung ausgehen, wenn Sie spät dran waren. Das ist der unangenehme Teil. Wer erst Tage nach dem 17. Juli aktualisiert hat, hat die Lücke geschlossen – aber nicht unbedingt entfernt, was in der Zwischenzeit hineingekommen ist. Ein Update entfernt keine Hintertür, die vorher eingerichtet wurde.
  • Nach Spuren suchen. Prüfen Sie Zugriffe auf /wp-json/batch/v1 und ?rest_route=/batch/v1 in den Server-Logs, dazu neue oder geänderte PHP-Dateien in wp-content (besonders in uploads, wo nichts Ausführbares hingehört) und neu angelegte Administratoren.
  • Wenn Sie nicht sofort aktualisieren können, sperren Sie die Batch-Schnittstelle serverseitig oder über eine Web Application Firewall. Cloudflare hat entsprechende Regeln bereits am Erscheinungstag ausgerollt, auch für kostenlose Zugänge – vorausgesetzt, der Datenverkehr läuft tatsächlich darüber.
  • Im Zweifel aus einem Backup wiederherstellen, das älter ist als der 17. Juli, und danach sofort aktualisieren. Das ist der einzige Weg, bei dem Sie sicher sein können.

Warum diese Lücke schwerer wiegt als die üblichen

WordPress-Sicherheitsmeldungen betreffen fast immer Plugins. Das ist ärgerlich, aber überschaubar: Man wirft das Plugin raus oder tauscht es aus. Die gängige Empfehlung „installiere so wenige Erweiterungen wie möglich" funktioniert.

Diesmal nicht. wp2shell steckt vollständig im Kern von WordPress. Kein Plugin, keine exotische Konfiguration, keine Vorbedingung. Eine schlanke, sauber gepflegte Installation war genauso angreifbar wie eine mit vierzig Erweiterungen. Damit fällt das Argument weg, mit dem sich WordPress-Sicherheit sonst erklären lässt.

Dazu kommt der Hebel. WordPress betreibt einen erheblichen Teil aller Websites weltweit. Ein Fehler im Kern ist deshalb kein Einzelfall, sondern ein Massenziel: Es lohnt sich für Angreifer, sofort einen automatisierten Scanner über das halbe Internet laufen zu lassen. Genau das ist passiert – zwischen Veröffentlichung und ersten Angriffen lagen Stunden, nicht Wochen. Diese Zeitspanne, die „Time-to-Exploit", schrumpft seit Jahren, und das BSI weist in seiner Warnung ausdrücklich darauf hin.

Weshalb ich für Kundenseiten kein WordPress einsetze

Ich werde das oft gefragt, meist mit einem gewissen Erstaunen: WordPress kennt jeder, es ist kostenlos, es gibt für alles ein Plugin. Warum also nicht?

Weil ich für die Seiten meiner Kunden verantwortlich bin – und weil ich diese Verantwortung nicht an ein Ökosystem abgeben möchte, in dem ich weder den Kern noch die Erweiterungen kenne, die im Laufe der Jahre dazukommen.

Eine typische WordPress-Seite ist ein Zusammenbau aus einem Kern, einem Theme und einer Handvoll Plugins von unterschiedlichen Anbietern, die unterschiedlich gut gepflegt werden. Jedes Teil ist eine eigene Update-Baustelle und eine eigene potenzielle Lücke. Und weil das überall gleich aussieht, ist jede dieser Baustellen für einen Angreifer im Voraus bekannt: Er weiß, wo das Login liegt, wie die API heißt, welche Dateien wo stehen. Das ist der Preis für Verbreitung.

Deshalb habe ich mit dem pixCMS ein eigenes System entwickelt. Nicht, weil ich es besser könnte als tausende WordPress-Entwickler – sondern weil ich bei einem selbst gebauten System weiß, was drin ist, und es geradebiegen kann, ohne auf einen fremden Anbieter zu warten.

Was das pixCMS konkret anders macht

  • Kein Plugin-Basar. Was eine Seite können muss, wird gebaut. Es gibt keine dreißig Erweiterungen, die man im Blick behalten müsste, und keine, die nächstes Jahr vom Entwickler aufgegeben wird.
  • Der Verwaltungsbereich liegt nicht an der Standardstelle. Es gibt kein /wp-admin, das man rund um die Uhr mit Passwortlisten beschießen kann.
  • pixSecure wehrt die Vorarbeit ab. Ein Massenangriff wie bei wp2shell fängt nicht mit dem fertigen Exploit an, sondern mit Abtasten: Welche Version läuft, welche Pfade antworten, wo ist das Login. Genau dieses Klopfen erkennt pixSecure – Muster für SQL-Injection und XSS, schädliche Bots und Scraper, zu viele Fehlversuche am Login – und sperrt die angreifende Adresse automatisch. Der CMS-Zugang hängt zusätzlich an einem zweiten Faktor, ein Passwort allein reicht nicht.
  • Und der Kunde sieht, dass es arbeitet. Einmal im Monat geht ein Bericht raus: wie viele Angriffsversuche abgefangen wurden, welcher Art sie waren und aus welchen Ländern sie kamen. Ohne dass jemand etwas tun musste. Wer sich versehentlich selbst aussperrt – kommt vor, etwa beim Testen –, kommt über eine Captcha-Seite wieder herein.
  • Absicherung steckt im Kern, nicht in einem Zusatzmodul. Strenge Content-Security-Policy, HTTP-Schutzheader, CSRF-Absicherung und Rate-Limits für Formulare kommen mit jeder Installation und jedem Update mit – man kann sie nicht versehentlich weglassen.
  • Datenbankzugriffe ausschließlich über vorbereitete Abfragen. Genau die Klasse von Fehler, die bei wp2shell die Kette eröffnet hat, wird damit strukturell verhindert.
  • Updates kommen von mir, zentral. Ich sehe, welche Kundenseite auf welchem Stand läuft, und spiele Korrekturen ein – individuelle Anpassungen werden dabei geschützt und nicht überschrieben. Sicherungen laufen automatisch im Hintergrund. Das ist der Kern von pixCare, meiner Website-Betreuung: pixSecure ist in jedem Paket enthalten, und um Aktualisierungen muss sich niemand selbst kümmern.

Und die ehrliche Einordnung

Kein System ist fehlerfrei, auch das pixCMS nicht. Wer etwas anderes behauptet, hat entweder nicht genug Software geschrieben oder verkauft Ihnen etwas.

Der Unterschied liegt woanders. Ein Fehler in einem System, das ein paar Dutzend Seiten betreibt, ist für Angreifer kein Geschäftsmodell – niemand baut einen Massenscanner für eine Handvoll Ziele. Und wenn doch etwas gefunden wird, ist klar, wer es behebt: Sie schreiben mir, und ich kümmere mich. Sie müssen nicht darauf hoffen, dass ein Plugin-Entwickler auf der anderen Seite der Welt noch aktiv ist.

Das ist, glaube ich, der Punkt, der bei solchen Meldungen untergeht. Die Frage ist nicht, ob ein System jemals eine Lücke hat. Die Frage ist, wie viele Leute gleichzeitig danach suchen – und wer am Montagmorgen den Hörer abnimmt, wenn es passiert.

Sie betreiben WordPress und sind unsicher?

Der erste Schritt kostet nichts: Schauen Sie nach, welche Version läuft, und aktualisieren Sie. Wenn Sie dabei unsicher sind oder nicht beurteilen können, ob in den letzten Wochen schon etwas passiert ist, schicken Sie mir Ihre Adresse über den Website-Check. Ich sehe mir an, was von außen sichtbar ist, und sage Ihnen ehrlich, ob Handlungsbedarf besteht – auch wenn die Antwort „alles in Ordnung, nichts zu tun" lautet.

Und wenn Sie ohnehin überlegt hatten, Ihre Website neu aufzusetzen: Das hier ist ein brauchbarer Anlass, die Systemfrage einmal grundsätzlich zu stellen, statt sie noch drei Jahre mitzuschleppen.

Quellen und weiterführende Informationen: die Cybersicherheitswarnung des BSI, die Berichterstattung bei heise online sowie die technischen Analysen von wiz.io und Rapid7.