Sicherheitslücke: Warum Sie WordPress sofort auf 7.0.2 aktualisieren sollten

Markus Seyfferth

Autor Dr. Web

18. Juli 2026

5 Min. Lesezeit

WordPress 7.0.2 schließt zwei Sicherheitslücken, von denen eine allein als moderat gilt und erst im Verbund mit der zweiten gefährlich wird. WordPress.org hat den Patch über das Auto-Update-System erzwungen, statt auf die Update-Disziplin der Betreiber zu setzen. Der Auslöser steckt in einer einzigen fehlenden Prüfung.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Genau drei Dateien hat das Sicherheitsrelease WordPress 7.0.2 angefasst^[4], und in einer davon sitzt der eigentliche Fehler. Aaron Jorbin hat die Version am 17. Juli veröffentlicht, zusammen mit den Rückportierungen 6.9.5 und 6.8.6^[1].

Das Wichtigste in Kürze

WordPress 7.0.2, 6.9.5 und 6.8.6 schließen eine SQL-Injection in WP_Query (CVE-2026-60137) sowie eine REST-API-Schwachstelle, die verkettet zu Remote Code Execution führt (CVE-2026-63030)
Betroffen sind alle Installationen ab 6.8.0. Ältere Versionen bleiben außen vor, die Kette zur Fernsteuerung greift erst ab 6.9
WordPress.org hat erzwungene Auto-Updates aktiviert, ein Schritt, den das Projekt nur bei kritischer Einstufung geht
Der Kern des Fehlers: Der Parameter author__not_in wurde nur dann auf Ganzzahlen geprüft, sofern er als Array ankam

Was ist an author__not_in schiefgelaufen?

Zwei ABUS 85/40 Vorhängeschlösser nebeneinander, eines mit Bügel und „author__in“-Label, das andere ohne Bügel und mit „author__not_in“-Label, sowie einem orangefarbenen Anhänger „Drinnen!“ — WP_Query: author__not_in-Parameter als String umgeht Ganzzahl-Validierung und gelangt ungefiltert in SQL-NOT-IN-Klausel

In WP_Query lief die Prüfung auf Ganzzahlen ausschließlich innerhalb einer is_array()-Abfrage. Kam der Parameter author__not_in als Zeichenkette an, landete der Wert ungefiltert in der NOT IN-Klausel der Datenbankabfrage^[2].

Der Beweis liegt im Zwillingszweig direkt darunter. Für author__in ruft derselbe Code beim Zusammenbauen der Liste ein zweites Mal absint() auf. Bei author__not_in fehlte genau dieser zweite Aufruf, und von zwei fast identischen Blöcken wurde einer angreifbar.

Deshalb spricht das Advisory von einer erleichterten Injection: WordPress selbst übergibt an dieser Stelle nie eine Zeichenkette. Angreifbar wird der Code erst, sobald ein Plugin oder Theme Nutzereingaben durchreicht. Solche Injektionen über Drittcode kennen Betreiber bereits aus dem Fall des Page Builders Avada mit einer Million betroffener Sites. Seit 7.0.2 erledigt wp_parse_id_list() die Arbeit und erzwingt Ganzzahlen, unabhängig vom Eingabeformat.

Wie wird daraus eine Fernsteuerung?

Erst die zweite Lücke macht die Injection kritisch. Über den Batch-Endpunkt der REST-API ließen sich Teilanfragen so verschieben, dass Parameter bei der falschen Route landeten und deren Prüfungen umgingen^[3].

Der Patch macht das an zwei Stellen sichtbar. Die Methode serve_request() bricht jetzt ab, sobald bereits eine Verarbeitung läuft, damit interne Teilanfragen den regulären Weg nehmen. Und im Batch-Handler wandert eine fehlerhafte Teilanfrage zusätzlich ins Trefferarray, das vorher aus dem Tritt geriet, sobald eine einzige Anfrage an der Validierung scheiterte.

Die Verkettung erklärt die Einstufung: einzeln moderat, gemeinsam kritisch. Adam Kues von Assetnote (Searchlight Cyber) hat den REST-Teil gemeldet, das Team aus TF1T, dtro und haongo die Injection. Verwundbar war damit auch das frisch erschienene WordPress 7.0 „Armstrong“.

Die Schwere einer einzelnen CVE taugt nicht als Maßstab für die eigene Update-Planung. WordPress hat diesmal zu Recht durchgegriffen, statt auf die Update-Disziplin der Betreiber zu hoffen.
— Michael Dobler, Herausgeber Dr. Web

3 Dateien

hat das Sicherheitsrelease 7.0.2 geändert: class-wp-query.php, class-wp-rest-server.php und rest-api.php

ab 6.8.0

sind Installationen von der SQL-Injection betroffen, ältere Versionen bleiben außen vor

2 CVEs

einzeln moderat und kritisch, verkettet ergeben sie Remote Code Execution

So greift die Kette ineinander

Batch-Endpunkt

Eine Teilanfrage scheitert an der Validierung. Dadurch gerät die Zuordnung im Batch-Handler der REST-API aus dem Tritt.

Falsche Route

Parameter landen bei einem Handler, dessen Prüfungen sie nie durchlaufen haben. CVE-2026-63030 heißt deshalb Route-Confusion.

Ungefilterte Abfrage

In WP_Query kommt author__not_in als Zeichenkette an, umgeht die Ganzzahl-Prüfung und landet roh in der SQL-Abfrage.

Was sollten Betreiber im DACH-Raum jetzt prüfen?

Zuerst die Versionsnummer im Dashboard kontrollieren. Erzwungene Updates laufen über dieselbe Verbindung zu WordPress.org wie reguläre Auto-Updates, weshalb sie Installationen hinter Firewalls, in Deployment-Pipelines oder mit deaktivierten Updates nicht zuverlässig erreichen.

Kunden von Managed-Hosting sind meist schon versorgt, denn viele Anbieter aus unserem WordPress-Hosting-Vergleich spielen Core-Sicherheitsreleases selbst ein. Auf eigenen Servern lohnt der Blick in die Zugriffslogs, solange die Installation noch ungepatcht läuft. Eine aktive Ausnutzung ist bislang nicht belegt.

Unter dem NIS2-Umsetzungsgesetz wird daraus eine Rechtsfrage. Betroffene Unternehmen brauchen ein nachweisbares Schwachstellenmanagement, und ein ausgenutzter Webauftritt kann als erheblicher Sicherheitsvorfall binnen 24 Stunden ans BSI gehören. Gehen dabei Kundendaten verloren, greift zusätzlich die 72-Stunden-Frist aus Artikel 33 DSGVO. Das Grundgerüst dafür beschreibt unser Ratgeber zur Absicherung von WordPress-Installationen.

Automatische Updates bleiben trotzdem ein zweischneidiges Werkzeug. Beim Plugin Smart Slider haben sechs Stunden genügt, um 800.000 Sites zu gefährden, und die 90 Plugin-Lücken im Mai haben gezeigt, wie schnell Agenturen das Update-Rennen verlieren. Ein erzwungener Core-Patch nimmt genau diesen Wettlauf aus der Hand, diesmal zugunsten der Betreiber.