WordPress-Kern: zwei Lücken, ein Versions-Check

Wenn die Lücke nicht im Zusatzmodul steckt, sondern im Fundament

Meldungen über Schwachstellen in Websites betreffen fast immer eine Erweiterung: ein Plugin, einen Editor, einen Formular-Baustein. Für Betreiber ist das unangenehm, aber wenigstens eingrenzbar. Die erste Frage lautet dann schlicht, ob dieses eine Modul überhaupt installiert ist. Lautet die Antwort nein, ist das Thema erledigt.

Bei den beiden Schwachstellen, die WordPress am 17. Juli 2026 geschlossen hat, greift diese Eingrenzung nicht. Sie stecken im Kern des Systems — also in dem Teil, den jede WordPress-Installation mitbringt, unabhängig davon, welches Design und welche Erweiterungen darauf aufsetzen. Und sie sind nicht unabhängig voneinander zu betrachten: Beide lassen sich miteinander verketten, und am Ende dieser Kette steht die Ausführung fremden Programmcodes auf dem Webserver, ohne dass sich jemand anmelden müsste.

Trotzdem ist die ehrliche Überschrift zu diesem Beitrag nicht „Ihre Website ist offen", sondern „prüfen Sie Ihre Version". Denn WordPress hat für betroffene Installationen erzwungene automatische Updates aktiviert — ein erheblicher Teil der Seiten wurde also bereits aktualisiert, ohne dass jemand etwas tun musste. Warum es dennoch sinnvoll ist, den eigenen Stand nachzusehen, und wie das in wenigen Minuten geht, steht weiter unten.

Auf einen Blick

• Betroffen ist der WordPress-Kern, nicht ein einzelnes Plugin: die Versionszweige 6.8, 6.9 und 7.0 unterhalb der jeweiligen Korrekturversion. Versionen vor 6.8 sind von diesen beiden Lücken nicht betroffen.
• Behoben sind sie in WordPress 7.0.2 sowie in den Rückportierungen 6.9.5 und 6.8.6, alle veröffentlicht am 17. Juli 2026. WordPress beschreibt die beiden Fälle als eine kritische und eine hoch eingestufte Schwachstelle.
• Die erste Lücke (Kennung CVE-2026-60137) ist eine SQL-Injection über den Abfrageparameter author__not_in — also über eine Angabe, mit der sich Beiträge bestimmter Autoren von einer Ausgabe ausschließen lassen.
• Die zweite Lücke (Kennung CVE-2026-63030) ist eine Routen-Verwechslung an einem Sammel-Endpunkt der REST-Schnittstelle: Eine Anfrage kann dort anders zugeordnet werden, als es vorgesehen ist.
• Der eigentliche Punkt ist die Verkettung. Einzeln sind beide Lücken begrenzt; zusammen ergeben sie Codeausführung ohne Anmeldung.
• Der Status: Die US-Behörde CISA hat beide Schwachstellen am 21. Juli 2026 in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen. Das BSI führt sie in einer Cyber-Sicherheitswarnung vom 20. Juli 2026 mit der Risikostufe 3 (sehr hoch).
• Die Entlastung: WordPress hat für betroffene Installationen erzwungene automatische Updates ausgelöst. Viele Seiten stehen deshalb längst auf einem korrigierten Stand.

Was die beiden Lücken sind — in Alltagssprache

WordPress holt die Inhalte einer Seite nicht als fertige Datei vom Server, sondern setzt sie bei jedem Aufruf aus einer Datenbank zusammen: Beiträge, Autoren, Kategorien, Sortierung. Für diese Abfragen gibt es eine zentrale Mechanik, die eine ganze Reihe von Angaben entgegennimmt — darunter auch die genannte Angabe author__not_in, mit der sich Beiträge bestimmter Autoren aus einer Liste heraushalten lassen.

Eine SQL-Injection bedeutet in diesem Zusammenhang: Was als schlichte Angabe gedacht ist, wird nicht streng genug von der eigentlichen Datenbankabfrage getrennt. Ein Teil dessen, was hineingereicht wird, kann dadurch als Anweisung an die Datenbank wirken statt nur als Wert. Das ist eine der ältesten und bestuntersuchten Fehlerklassen in der Webentwicklung — und sie ist deshalb so ernst zu nehmen, weil die Datenbank hinter einer Website in aller Regel alles enthält, was die Website ausmacht.

Die zweite Lücke liegt an einer anderen Stelle. Moderne WordPress-Installationen bieten eine Programmierschnittstelle an, die REST-Schnittstelle. Über sie arbeitet unter anderem der Editor, über sie binden Apps und angeschlossene Systeme Inhalte an. Diese Schnittstelle ist in einzelne Adressen unterteilt, sogenannte Routen, und jede Route hat ihre eigenen Prüfungen dafür, wer was tun darf. Zusätzlich gibt es einen Sammel-Endpunkt, der mehrere Anfragen gebündelt annimmt, damit nicht jede einzeln über die Leitung muss. Genau dort kann eine Anfrage anders zugeordnet werden, als es der Aufbau vorsieht — die Prüfung passt dann nicht mehr zuverlässig zu dem, was tatsächlich ausgeführt wird.

Warum die Verkettung mehr wiegt als jede Lücke für sich

Beide Schwachstellen sind auch für sich genommen behandlungsbedürftig: Die US-Behörde CISA hat sie einzeln in ihren Katalog aufgenommen und für jede eine eigene Frist gesetzt. Einzeln bleibt ihre Wirkung allerdings begrenzt — die eine setzt voraus, dass ein Angreifer die betroffene Abfrage überhaupt erreicht; die andere verschiebt Zuständigkeiten innerhalb der Schnittstelle, ohne selbst Code auszuführen. Was die Verkettung hinzufügt, ist deshalb nicht der Anlass zum Handeln, sondern die Reichweite: Am Ende der Kette steht das, was in der Sicherheitswelt als Remote Code Execution bezeichnet wird — die Ausführung fremden Programmcodes auf dem Server, aus der Ferne und ohne gültige Zugangsdaten. Wie die beiden Lücken dabei technisch ineinandergreifen, ist für die Praxis ohne Belang.

Für Sie als Betreiber hat das eine einfache praktische Folge: Es gibt hier nichts abzuwägen und nichts zu priorisieren. Es lohnt nicht, „die kritischere zuerst" zu schließen. Die Korrekturversionen enthalten ohnehin beide Korrekturen, und beide gehören zusammen.

Wie ernst ist es? Ein Blick auf die Einordnungen

Die belastbarste Einordnung liefert nicht eine Zahl, sondern der Umstand, dass beide Schwachstellen im CISA-Katalog stehen. Dort werden ausschließlich Lücken geführt, für die eine tatsächliche Ausnutzung belegt ist. Die Behörde hat US-Bundesbehörden dafür Fristen gesetzt: den 24. Juli 2026 für die Schnittstellen-Lücke — also drei Tage nach der Aufnahme — und den 4. August 2026 für die SQL-Injection. Diese Fristen binden deutsche Unternehmen nicht. Aber eine Frist von drei Tagen ist ein deutliches Signal, wie dringend die Behörde den Fall selbst bewertet. In dieselbe Richtung weist die Risikostufe 3 (sehr hoch), mit der das BSI seine Warnung versehen hat.

Bei den Punktzahlen wird es dagegen unübersichtlich, und das gehört offen gesagt. Für beide Schwachstellen führt die maßgebliche Schwachstellen-Datenbank jeweils zwei Bewertungen nebeneinander, die deutlich auseinandergehen — und zwar bei jeder der beiden in die entgegengesetzte Richtung: Was die eine Quelle als kritisch einstuft, bewertet die andere als hoch, und beim zweiten Fall ist es genau umgekehrt, dort steht eine mittlere Einstufung gegen eine kritische. Die Spanne reicht damit insgesamt von mittel bis kritisch.

Wir bilden daraus bewusst keinen Mittelwert und geben auch keine der Zahlen als „die" Bewertung aus — eine gemittelte Zahl würde eine Genauigkeit vortäuschen, die es hier nicht gibt. Für die Praxis ist das ohnehin nicht die entscheidende Größe. Entscheidend sind die belegte Ausnutzung, die Einstufung des BSI und die Tatsache, dass eine korrigierte Version bereitsteht.

Eine Klarstellung noch, weil solche Meldungen schnell zugespitzt werden: Der CISA-Katalog vermerkt bei beiden Schwachstellen ausdrücklich, dass eine Nutzung durch Ransomware-Kampagnen unbekannt ist. Das ist weder ein Beleg dafür noch eine Entwarnung — es ist schlicht ein offener Punkt, und man sollte ihn nicht in die eine oder andere Richtung auffüllen.

Vieles ist längst behoben — und trotzdem lohnt der Blick

Erzwungene automatische Updates sind ein Mechanismus, den WordPress genau für solche Fälle vorhält. Er greift ohne Zutun des Betreibers, und er hat hier für einen großen Teil der betroffenen Installationen die Sache bereits erledigt. Das ist die gute Nachricht, und sie darf so stehen bleiben. Drei Gründe sprechen dennoch dafür, den eigenen Stand einmal nachzusehen.

• Automatische Updates lassen sich abschalten — und das geschieht überdurchschnittlich oft bei genau den Installationen, die stark angepasst sind oder von einer Agentur gepflegt werden, weil dort jedes Update erst geprüft werden soll. Ausgerechnet gut betreute Seiten können deshalb außerhalb des Automatismus stehen.
• Ein alter Versionsstand ist kein Entwarnungsgrund. Wer auf einer Version vor 6.8 steht, ist von diesen beiden Lücken nicht betroffen. Er ist damit aber auch weit von der laufenden Pflege des Systems entfernt — und dieser Abstand ist für sich genommen die schlechtere Ausgangslage, unabhängig von diesen zwei Kennungen.
• Ein Update sagt nichts über die Zeit davor. Das ist allgemeine Betriebslogik und keine Aussage über diesen Fall: Ein eingespielter Patch schließt eine Tür, er räumt aber nicht auf, was zuvor geschehen sein könnte. Für die hier beschriebenen Lücken liegen uns keine Belege über konkrete betroffene Websites vor. Wenn Ihre Seite über längere Zeit ungepflegt lief, ist ein prüfender Blick auf unerklärliche Administrator-Konten und unbekannte Dateien dennoch grundsätzlich sinnvoll.

In zwei Minuten geklärt

Sie müssen dafür nicht selbst an der Website arbeiten. Es genügt, die richtige Frage zu stellen — an die eigene IT, an die Agentur oder an den Dienstleister, der die Seite betreut.

• Welche WordPress-Version läuft? Der installierte Versionsstand wird im Adminbereich von WordPress angezeigt. Wer dort keinen Zugang hat, stellt genau diese Frage an den Betreuer der Website — sie ist in einer Minute beantwortbar, und eine ausweichende Antwort ist für sich schon ein Hinweis.
• Liegt der Stand auf oder über der Korrekturversion des eigenen Zweigs? Die Zuordnung steht in der Tabelle unten.
• Sind automatische Kern-Updates aktiv? Falls nicht: Wer hat sie abgeschaltet, aus welchem Grund, und wer spielt Sicherheitsupdates stattdessen ein?
• Seit wann steht der korrigierte Stand? Ein automatisches Update wird ausgerollt, nachdem eine Lücke öffentlich geworden ist; es schließt die Tür, sagt aber nichts über die Zeit davor. Lässt sich der Zeitpunkt nicht benennen, gehört eine kurze Sichtung dazu: neu angelegte Administratorkonten, veränderte oder unbekannte Dateien, auffällige Einträge in den Zugriffsprotokollen. Das ist allgemeine Betriebslogik und keine Aussage über Ihre Website.

Was Sie über diesen Fall hinaus mitnehmen sollten

Der eigentliche Wert einer solchen Meldung liegt weniger in den beiden Kennungen als in den Fragen, die sie sichtbar macht. Wer betreibt Ihre Website tatsächlich — Sie selbst, eine Agentur, ein Hoster, oder ist es über die Jahre unklar geworden? Wer spielt Sicherheitsupdates ein, und geschieht das automatisch oder von Hand? Und woran würden Sie überhaupt merken, dass es passiert ist?

Wenn eine dieser drei Fragen unbeantwortet bleibt, ist das die eigentliche Baustelle — nicht diese eine Julimeldung. Eine Website ist eine laufende Anwendung, kein einmal angeschafftes Möbelstück. Sie braucht jemanden, der zuständig ist, und einen nachvollziehbaren Nachweis, dass Updates ankommen.

Wenn Sie nicht sicher sind, auf welchem Stand Ihre Website läuft oder wer sie aktuell hält, sehen wir uns das mit Ihnen an: Wir klären den Versions- und Patch-Stand, prüfen, ob Sicherheitsupdates zuverlässig ankommen, und richten auf Wunsch eine laufende Wartung mit Monitoring und Sicherungen ein — damit die nächste Meldung dieser Art für Sie eine Zwei-Minuten-Frage bleibt.