Bei WordPress-Sicherheitslücken entscheidet oft nicht die Schwere der einzelnen Lücke, sondern die Geschwindigkeit, mit der aus einem Advisory ein Werkzeug für Angriffe wird. Genau das ist hier der Punkt: Zwei Schwachstellen im WordPress-Core lassen sich ab bestimmten Versionen zu einer Kette verbinden, die ohne Anmeldung und ohne zusätzliche Plugins funktionieren kann. Für Betreiber ist das keine abstrakte Produktwarnung. Es ist ein Patch-Fenster, das sich schnell schließt.
Die Warnung von CERT.at beschreibt zwei Lücken: CVE-2026-60137, eine SQL-Injection im Parameter author__not_in von WP_Query, und CVE-2026-63030, eine Schwachstelle in der REST-API, die als Batch-Route-Confusion eingeordnet wird. Die zweite Lücke ist im GitHub Security Advisory als „Critical“ eingestuft. In Kombination kann die Kette ab WordPress 6.9 zur Ausführung beliebigen Codes führen. Das ist die unangenehme Kategorie: nicht nur Datenbankabfrage manipulieren, nicht nur Rechte erweitern, sondern im Ergebnis Kontrolle über Website und darunterliegendes System riskieren.
Der gefährliche Teil ist die fehlende Hürde
Viele WordPress-Vorfälle hängen an Erweiterungen, Themes oder schlecht gepflegten Einzelinstallationen. Diese Meldung liegt anders. Laut CERT.at verweist Searchlight Cyber darauf, dass die Angriffskette ohne vorherige Authentifizierung und in einer Standardinstallation ohne Plugins nutzbar ist. Damit fällt ein Teil der üblichen Beruhigungsargumente weg. Es reicht nicht zu sagen, man habe keine riskanten Plugins installiert. Es reicht auch nicht, darauf zu setzen, dass nur eingeloggte Nutzer angreifen könnten.
Hinzu kommt: Für CVE-2026-63030 sind bereits mehrere öffentlich verfügbare Proof-of-Concept-Exploits auf GitHub veröffentlicht worden. Ein Proof of Concept ist nicht automatisch ein Massenangriff. Aber er senkt die Eintrittshürde. Aus einer technischen Beschreibung wird nachvollziehbarer Code, aus Analyse wird Wiederholung. CERT.at formuliert deshalb klar, dass mit Angriffen auf ungepatchte Systeme gerechnet wird.
Das ist für Sicherheitsverantwortliche der eigentliche Wendepunkt. Nicht jede Organisation muss die Details von WP_Query oder REST-API-Routing vollständig nachvollziehen. Sie muss aber verstehen, dass sich die Lage verändert, sobald funktionierende Beispiele öffentlich kursieren. Dann ist die Frage nicht mehr, ob eine Installation theoretisch angreifbar ist. Die Frage ist, ob sie im nächsten Scanlauf noch ungepatcht gefunden wird.
Welche Versionen betroffen sind
CVE-2026-60137 betrifft laut CERT.at WordPress 6.8.0 bis 6.8.5, 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1. CVE-2026-63030 betrifft WordPress 6.9.0 bis 6.9.4, 7.0.0 bis 7.0.1 und 7.1 Beta 1. WordPress-Versionen vor 6.8 sind nach der CERT.at-Meldung nicht betroffen.
Die korrigierten Versionen sind entsprechend klar benannt: WordPress 7.0.2 behebt beide Schwachstellen, WordPress 6.9.5 ebenfalls. WordPress 6.8.6 behebt CVE-2026-60137. Für die Beta-Linie nennt CERT.at WordPress 7.1 Beta 2 als korrigierte Fassung für beide Lücken. Wer eine der betroffenen Versionen betreibt, sollte nicht auf eine planmäßige Wartung am Wochenende warten. Das Update gehört in den Notfallprozess.
Auto-Updates helfen, ersetzen aber keine Kontrolle
Das WordPress.org-Team hat für betroffene Versionen erzwungene Updates über das Auto-Update-System aktiviert. Das ist wichtig, weil WordPress in sehr unterschiedlichen Umgebungen läuft: bei kleinen Vereinen, Agenturen, Medienseiten, Shops, Behördenprojekten und internen Portalen. Viele dieser Installationen haben keinen dauerhaft besetzten Sicherheitsbetrieb. Automatische Updates sind hier keine Bequemlichkeit, sondern Schadensbegrenzung.
Trotzdem ist „Auto-Update ist aktiviert“ kein ausreichender Abschlussvermerk. Updates können ausbleiben, wenn Dateirechte falsch gesetzt sind, Managed-Hosting-Prozesse eingreifen, Caches oder Deployment-Pipelines dazwischenliegen, Wartungsfenster blockieren oder eine Installation faktisch nicht mehr betreut wird. Gerade WordPress-Landschaften bestehen häufig aus mehr als der bekannten Hauptseite: alte Kampagnenseiten, Subdomains, Testsysteme, Agentur-Backups im Webroot. Angreifer unterscheiden nicht zwischen produktiv, alt und vergessen.
Operativ heißt das: Version prüfen, Update einspielen, Update-Erfolg verifizieren. Nicht nur im Dashboard, sondern möglichst auch im Inventar und über externe Sichtbarkeit. Wer viele WordPress-Instanzen betreibt, braucht jetzt keine lange Grundsatzdebatte, sondern eine Liste: Welche Installationen laufen auf 6.8.x, 6.9.x, 7.0.x oder 7.1 Beta 1? Welche wurden automatisch aktualisiert? Welche sind geblockt? Welche sind nicht mehr erforderlich und können abgeschaltet werden?
Notmaßnahmen sind nur Übergang, nicht Lösung
Falls ein Update nicht sofort möglich ist, nennt CERT.at temporäre Schritte, die auf Angaben von Searchlight Cyber beruhen. Dazu gehören die Deaktivierung der REST-API für nicht authentifizierte Nutzer, das Blockieren von /wp-json/batch/v1 sowie des Query-Parameters rest_route=/batch/v1 per Web Application Firewall. Beide Muster müssen berücksichtigt werden. Alternativ kann ein Plugin eingesetzt werden, das Batch-Requests an die REST-API nur für authentifizierte Nutzer zulässt.
Diese Maßnahmen sind allerdings kein gleichwertiger Ersatz für den Patch. CERT.at weist darauf hin, dass sie den regulären Betrieb beeinträchtigen können und nur als temporäre Notmaßnahme bis zur Aktualisierung gedacht sind. Das ist plausibel: Die REST-API ist in vielen WordPress-Setups kein Randbauteil mehr. Themes, Editoren, Integrationen und externe Anwendungen können darauf angewiesen sein. Wer hier grob blockiert, reduziert Risiko, kann aber Funktionen beschädigen.
Deshalb sollte die Reihenfolge nicht verwechselt werden. WAF-Regeln und REST-API-Einschränkungen sind sinnvoll, wenn ein System aus technischen oder organisatorischen Gründen nicht sofort aktualisiert werden kann. Sie sind keine Strategie, um ein anfälliges Core-System weiterlaufen zu lassen.
Die Lehre ist nüchtern
Dieser Fall zeigt keine neue Wahrheit über WordPress, sondern eine alte operative Regel: Weit verbreitete Software braucht belastbares Patch-Management. Je größer die Installationsbasis, desto attraktiver ist eine Lücke, die ohne Anmeldung und ohne Zusatzkomponenten funktioniert. Und je schneller Beispielcode öffentlich verfügbar ist, desto kürzer wird die Zeit, in der Betreiber noch kontrolliert reagieren können.
Für einzelne Website-Betreiber ist die Handlung eindeutig: auf WordPress 7.0.2, 6.9.5 oder 6.8.6 aktualisieren, je nach eingesetzter Linie, und bei Beta-Installationen auf 7.1 Beta 2 wechseln. Für Organisationen mit mehreren Sites ist der größere Punkt wichtiger: Inventar, Zuständigkeit und Verifikation. Ein Update, das angenommen wird, aber nicht geprüft wurde, ist im Sicherheitsbetrieb nur eine Hoffnung.
