WordPress Core (CVE-2026-60137)

Am 17. Juli 2026 veröffentlichte WordPress die Versionen 7.0.2, 6.9.5 und 6.8.6, um zwei Lücken im Kern zu schließen. Laut Patchstack trafen die ersten Ausnutzungsversuche rund 90 Minuten später auf seine Sensoren. Dieser Artikel behandelt die SQL-Injection-Hälfte dieses Paars. Für sich genommen ist sie mittelschwer. Zusammen mit CVE-2026-63030 übergibt sie einem anonymen Angreifer die ganze Website.

Was ist CVE-2026-60137

WP_Query ist die Klasse, mit der WordPress Beiträge aus der Datenbank holt. Ihr Parameter author__not_in, über die REST API als author_exclude erreichbar, wurde nicht sauber bereinigt, sodass ein präparierter Wert in der SQL-Abfrage landete: eine klassische SQL Injection. WordPress spricht von einer „facilitated“ Injection. Laut NVD-Beschreibung funktioniert sie für sich allein nur, wenn ein Plugin oder Theme nicht vertrauenswürdige Eingaben an den Parameter weitergibt, und Patchstack weist darauf hin, dass sie Daten lesen, aber nicht schreiben kann. Das erklärt den CVSS-Score von 5.9 der CNA, WPScan. Der ADP-Eintrag der CISA nennt 9.1, und Stand 1. Oktober 2026 hat NIST keine eigene Bewertung veröffentlicht. Der verwundbare Code kam mit WordPress 6.8; ältere Versionen sind nicht betroffen.

Ab 6.9 liefert eine zweite Lücke das fehlende Stück. CVE-2026-63030 ist eine Routenverwechslung im Batch-Endpunkt der REST API (/batch/v1): Eine Teilanfrage wird für einen Handler geprüft und dann von einem anderen ausgeführt. Laut Patchstack kann eine nicht authentifizierte Anfrage die SQL Injection so an dem Schema vorbeischmuggeln, das die Eingabe normalerweise bereinigen würde. Der öffentliche Exploit nutzt die Injection dann, um Daten zu fälschen, auf die WordPress selbst reagiert, und endet mit einem neuen Administratorkonto. Das ist Privilege Escalation vom anonymen Besucher zum Administrator; danach ist der Rest laut Patchstack Routine: ein Plugin hochladen, das in Wahrheit eine Web-Shell ist, und Code auf dem Server ausführen. Adam Kues von Assetnote / Searchlight Cyber meldete die Kette und veröffentlichte sie unter dem Namen „wp2shell“; die Injection selbst meldeten TF1T, dtro und haongo.

Was die Angreifer taten

Das war ein N-Day, kein Zero-Day: Erst kam der Patch, dann kamen die Angriffe. Der Fix stand etwa anderthalb Stunden vor dem Release im öffentlichen Code von WordPress, und Patchstack nennt diesen Commit faktisch die Offenlegung: Jeder konnte die Änderung nachlesen. Die ersten Ausnutzungsversuche folgten drei Stunden nach dem Commit. Die US-Behörde CISA nahm beide CVEs am 21. Juli in ihren Katalog aktiv ausgenutzter Schwachstellen auf, am selben Tag, an dem das niederländische NCSC beobachteten Missbrauch meldete. Das BSI stufte die Lage mit 3 von 4 (orange) ein und verwies auf aktive Ausnutzung.

Patchstack beschrieb die ersten Tage als Ansturm vieler verschiedener Akteure statt eines koordinierten Botnetzes; in seinen Daten versuchten nur drei IP-Adressen die vollständige Kette bis zum Administratorkonto. CrowdSec zählte 62.802 eindeutige angreifende IP-Adressen in den 15 Tagen bis zum 23. August 2026 und stufte die Lücke weiterhin als aktiv ausgenutzt ein. Es gibt auch gezielte Angriffe: GreyNoise beschreibt einen Akteur, den es Kapibala nennt, nach seiner Einschätzung vermutlich chinesischsprachig, der die Kette ab etwa 20. Juli einsetzte und damit bei mindestens 49 Organisationen in 29 Ländern Erfolg hatte, darunter vier in Deutschland und eine in den Niederlanden. Bei einer westlichen Regierungsstelle stahl der Akteur mehr als 18.000 Datensätze.

Warum eine 5.9 trotzdem ein Notfall war

Wer nach einzelnen CVSS-Werten priorisiert, hätte diese CVE ins nächste Wartungsfenster geschoben. Das ist die Lehre: Angreifer denken in Ketten, bewerten Sie eine mittelschwere Lücke also zusammen mit allem, womit sie sich kombinieren lässt. Die zweite Lehre betrifft die Zeit. Neunzig Minuten zwischen Patch und Angriff lassen keinen Raum für einen Change-Prozess, und das erzwungene automatische Update hilft nur dort, wo es tatsächlich ankommt. CrowdSec sah Zehntausende Adressen, die weiterhin Websites fanden, bei denen das nicht der Fall war: automatische Updates abgeschaltet, ein Hoster, der die Version festschreibt, oder eine Staging-Kopie, für die sich niemand zuständig fühlt. Das sind veraltete Komponenten in Reinform.

Was jetzt zu tun ist

• Prüfen Sie, welche Version auf jeder WordPress-Installation tatsächlich läuft, auch auf Staging-, Test- und vergessenen Kampagnenseiten. Verlassen Sie sich nicht darauf, dass das erzwungene Update angekommen ist.
• Betreiben Sie das neueste Release. Stand 1. Oktober 2026 ist das 7.1.2, das auch CVE-2026-87902 behebt, eine eigenständige Core-Lücke, die die CISA seit dem 25. September als ausgenutzt führt. Für diese CVE allein ist das Minimum 7.0.2, 6.9.5 oder 6.8.6.
• Lief eine Website nach dem 17. Juli 2026 mit einer verwundbaren 6.9- oder 7.0-Version, suchen Sie nach Administratoren, die Sie nicht angelegt haben, nach Plugins, die Sie nicht kennen, nach PHP-Dateien unter wp-content/uploads und nach allem in wp-content/mu-plugins.
• Können Sie nicht sofort aktualisieren? Sperren Sie /wp-json/batch/v1 und ?rest_route=/batch/v1 am Netzwerkrand, und testen Sie die Regel auch gegen die Variante mit rest_route im POST-Body. CrowdSec und Patchstack stießen auf Regeln, die nur auf die URL schauten.
• Entwickeln Sie Plugins oder Themes? Reichen Sie Anfrageeingaben nie ungeprüft an WP_Query weiter; wandeln Sie Autoren-IDs zuerst in Ganzzahlen um. Siehe Eingabevalidierung.
• Nehmen Sie Ihre WordPress-Websites in einen regelmäßigen Penetrationstest auf, die vergessenen zuerst.