WordPress patchte am Freitag, die Exploits kamen am Sonntag

Freitag um Viertel vor sechs am Abend

WordPress hat am 17. Juli 2026 eine Sicherheitsversion veröffentlicht, die zwei Schwachstellen im Kern abdeckt. Das Forschungsteam von Searchlight Cyber, das die schwerwiegendere der beiden gefunden hat, gab ihr den Namen wp2shell. Die vergebenen Kennungen sind CVE-2026-63030, eine Routenverwechslung im Batch-Endpunkt der REST-API in Kombination mit SQL-Injection, und CVE-2026-60137, eine SQL-Injection, die über den Parameter author__not_in von WP_Query erreichbar ist.

Um 17:45 Uhr Ostküstenzeit am Tag des Patches veröffentlichte Rapid7 seine Analyse und hielt zwei Punkte fest. Technische Exploit-Details waren noch nicht veröffentlicht, und es lagen keine öffentlich bestätigten Angriffe in freier Wildbahn vor. Wer diese Einschätzung am Freitag gelesen hat, durfte mit gutem Grund annehmen, für das Update eine ganz normale Arbeitswoche Zeit zu haben.

Die hatte er nicht. PatchStack begann noch am selben Abend kurz vor 19 Uhr Ostküstenzeit über die Ausnutzung beider CVEs zu berichten, also etwa eine Stunde nach der Momentaufnahme von Rapid7. Bis Sonntag, dem 19. Juli, hatte VulnCheck über zwei Dutzend verschiedene Proof-of-Concept-Exploits verifiziert, die auf die Lücke zielen.

Zwei Fehler, und Ihre Version hat zwei verschiedene Antworten

Die meiste Berichterstattung behandelt das als ein Ereignis mit einem Namen. Es sind zwei Schwachstellen mit unterschiedlicher Reichweite, und dieser Unterschied entscheidet darüber, was Sie tatsächlich tun müssen. Ein Irrtum in die eine Richtung kostet ein Wochenende, ein Irrtum in die andere lässt ein Loch offen.

CVE-2026-63030, die Kette zur Codeausführung aus der Ferne, betrifft WordPress 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1. Behoben ist sie in 6.9.5 und 7.0.2 sowie in der 7.1-Beta-Linie ab Beta 2. CVE-2026-60137, die SQL-Injection in WP_Query, reicht weiter zurück. Sie betrifft 6.8.0 bis 6.8.5 sowie dieselben Bereiche 6.9 und 7.0, und für den älteren Zweig lautet der Fix 6.8.6.

In der Praxis führt das dazu, dass eine Seite auf 6.8.x die Schlagzeilen zu wp2shell liest, prüft, ob sie im Bereich 6.9 oder 7.0 liegt, daraus schließt, nicht betroffen zu sein, und aufhört. Diese Seite ist der vollständigen Kette zur Codeausführung ohne Authentifizierung nicht ausgesetzt, wohl aber der SQL-Injection, und sie muss trotzdem auf 6.8.6 gehoben werden. Versionsprüfungen gegen die falsche CVE sind der wahrscheinlichste Weg, auf dem eine Organisation das in dieser Woche falsch macht.

Das Sicherheitsnetz deckt die Seiten ab, auf die es am wenigsten ankommt

Die WordPress-Maintainer haben reagiert, indem sie Updates auf betroffene Installationen erzwungen haben, bei denen automatische Aktualisierungen aktiviert waren. Das ist die richtige Entscheidung, und sie dürfte über das Wochenende sehr viele Seiten geschützt haben, ohne dass jemand sie anfassen musste.

Sehen Sie sich an, welche Seiten damit nicht geschützt waren. Automatische Updates werden bewusst abgeschaltet, und die Gründe sind immer dieselben. Ein Change-Management-Prozess, ein Plugin, das bei einem früheren Minor-Release kaputtgegangen ist, eine Pipeline von Staging nach Produktion, ein Agenturvertrag, der die Verantwortung für Updates einem Menschen zuweist, ein Compliance-Regime, das ungeprüfte Änderungen an der Produktion untersagt. Jeder einzelne dieser Gründe kennzeichnet eine Installation, die jemand für wichtig genug hält, um sie aktiv zu betreuen.

Das automatische Sicherheitsnetz ist damit umgekehrt zur geschäftlichen Bedeutung korreliert. Das Hobbyblog hat sich am Freitagabend selbst aktualisiert. Das Kundenportal, das Buchungssystem und die Seite, die Zahlungen entgegennimmt, standen über ein Wochenende auf der verwundbaren Version, in dem funktionierender Exploit-Code von null auf über zwei Dutzend angewachsen ist. Wenn Ihre Organisation Auto-Updates als Zeichen von Reife deaktiviert hat, dann ist das hier das Wochenende, an dem diese Entscheidung ihren Preis hatte.

Was die Kurve dieses Wochenendes tatsächlich misst

Die nützliche Zahl ist hier kein CVSS-Score, und die Anbieter sind sich über die Schwere ohnehin nicht ganz einig. Rapid7 führt CVSS 7.5 für die Kette zur Codeausführung, während das zugehörige Advisory sie als kritisch einstuft, und VulnCheck hält die SQL-Injection für die kritischere der beiden. Ein Streit darüber, welche Zahl ins Ticket kommt, ist eine schlechte Verwendung der Zeit, die Ihnen bleibt.

Die Zahl, auf die es ankommt, ist der Abstand zwischen Patch und Waffenfähigkeit. Hier waren es Stunden bis zu den ersten Meldungen über Ausnutzung und rund zwei Tage bis zur breiten öffentlichen Verfügbarkeit von Exploits. Das ist das tatsächliche Service-Level, das Ihr Patch-Prozess einhalten muss, und so gut wie keine Organisation erreicht es mit ihrer erklärten Richtlinie. Ein Behebungsfenster von dreißig Tagen, wie es in Compliance-Rahmenwerken üblich ist, ist bei einem Fehler dieser Art keine Patch-Richtlinie. Es ist eine Beschreibung dessen, wie lange Sie exponiert waren.

In den späteren Exploits steckt ein zweites Detail, das den üblichen Rückfallweg versperrt. VulnCheck berichtet, dass bis Sonntag weitere Implementierungen zur Codeausführung aus der Ferne aufgetaucht sind, die die Administrator-Authentifizierung vollständig umgehen. Teams, die sich auf gehärtete Admin-Konten, eingeschränkte Anmeldeseiten oder Zwei-Faktor-Authentifizierung an wp-admin als kompensierende Maßnahme stützen wollten, sollten wissen, dass diese Maßnahmen im Pfad dieses Angriffs gar nicht vorkommen.

Vier Dinge, die sich heute lohnen

Erstens: Inventarisieren Sie, bevor Sie patchen. Finden Sie jede WordPress-Installation, die Ihre Organisation tatsächlich besitzt, einschließlich der Marketing-Microsites, der Kampagnen-Landingpages, der Konferenzseite von vor zwei Jahren und allem, was eine längst ausgeschiedene Agentur gebaut hat. Die verwundbare Installation ist fast nie die, die im Anlagenverzeichnis steht. Es ist die, von der niemand mehr wusste, dass sie noch Traffic ausliefert.

Zweitens: Prüfen Sie jede einzelne gegen die richtige CVE. Alles auf 6.8.x geht auf 6.8.6. Alles auf 6.9.x geht auf 6.9.5. Alles auf 7.0.x geht auf 7.0.2. Lassen Sie nicht zu, dass eine einzige Annahme über einen Versionsbereich für den gesamten Bestand gilt.

Drittens: Behandeln Sie jede ungepatchte Installation, die über das Wochenende am Internet hing, als potenziell kompromittiert und nicht bloß als verwundbar, und suchen Sie nach Belegen, statt deren Abwesenheit vorauszusetzen. Patchen schließt die Tür. Es entfernt niemanden, der bereits drinnen ist. Viertens, und das ist der dauerhafte Punkt: Halten Sie schriftlich fest, wie lange Ihre Organisation bei diesem Vorfall tatsächlich bis zum Patch gebraucht hat, und vergleichen Sie das mit der Zahl, die Sie in Ihrer Richtlinie veröffentlichen. Der Abstand zwischen diesen beiden Werten ist das, was Sie beheben müssen, denn die nächste Schwachstelle im Kern läuft nach derselben Uhr.

Weiterlesen: Der nginx-Patch ist da, der Exploit kommt im August  |  ServiceNow patchte die eigene Cloud zuerst, Sie 103 Tage später