ServiceNow patchte die eigene Cloud zuerst, Sie 103 Tage später

Die Meldung ging am ersten April ein

Am 1. April 2026 schickte Adam Kues von Assetnote, dem Forschungsarm von Searchlight Cyber, einen Bericht an ServiceNow, der einen Weg beschrieb, ohne jede Zugangsdaten Code auf der ServiceNow AI Platform auszuführen. Das Unternehmen reagierte schnell. In ihrer eigenen Schilderung der Offenlegung halten die Forscher fest, ServiceNow habe "binnen 24 Stunden nach unserer Meldung starke Gegenmaßnahmen auf allen Cloud-Instanzen ausgerollt" und in den Wochen danach Patches für die zugrunde liegenden Fehler nachgeliefert. Jeder Kunde auf einer von ServiceNow gehosteten Instanz war Anfang April geschützt, und niemand musste dafür etwas tun oder auch nur davon wissen.

Die Kunden mit eigenem Betrieb erfuhren bis zum 13. Juli nichts. An diesem Tag veröffentlichte ServiceNow das Advisory KB3137947 und stellte Updates für selbst betriebene Installationen bereit. Die Schwachstelle wird als CVE-2026-6875 geführt. ServiceNow vergab als eigene CNA einen CVSS-4.0-Wert von 9,5 von 10. Der Vektor weist eine hohe Angriffskomplexität aus, verlangt aber keine Rechte und keine Nutzerinteraktion, und genau diese Kombination macht eine aus dem Internet erreichbare Instanz für jeden interessant, der in der Breite scannt.

Zwischen diesen beiden Daten liegen 103 Tage. Für ein SaaS-Unternehmen ist das eine sauber geführte koordinierte Offenlegung. Für den Teil der Kundschaft, der die Plattform selbst betreibt, ist es ein Vierteljahr mit einer kritischen Lücke vor der Authentifizierung, die der Hersteller im eigenen Bestand längst geschlossen hatte.

Eine Sandbox, die bereit war, JavaScript auszuwerten

Die Schwachstelle steckt in der Sandbox der ServiceNow AI Platform, also in jener Schicht, die Plattformcode ausführen lassen soll, ohne dass er an etwas herankommt, an das er nicht herankommen darf. Der Einstiegspunkt ist die GlideRecord-API, die JavaScript-Auswertung innerhalb von Abfragefiltern unterstützt. Von Nutzern gelieferte Eingaben erreichten einen addQuery-Aufruf mit dem Präfix javascript:, und die Plattform wertete sie aus.

Eine zweite Sandbox sollte genau das abfangen und gefährliche Funktionen blockieren. Die Forscher kamen an ihr vorbei, und zwar mit einer Gadget-Kette aus Object.clone und Class.create.constructor, die zusammen während Script Includes die Ausführung beliebiger Funktionen erlaubt. Der demonstrierte Einstiegspunkt war der Endpunkt /assessment_thanks.do über dessen Parameter sysparm_assessable_type, und nichts davon setzte eine Anmeldung voraus.

Was ein Angreifer damit gewinnt, ist kein Fuß in der Tür irgendeiner Produktecke. Die Analyse von Searchlight beschreibt das Auslesen von Daten aus Tabellen, das Anlegen von Administratorkonten und das Ausführen von Shell-Befehlen auf allen konfigurierten MID-Server-Proxys, die, wie die Forscher anmerken, üblicherweise in den internen Netzen der Unternehmen stehen. Der MID Server ist genau das Element, das in Ihren Bestand zurückreicht, um Assets zu erfassen und Automatisierung auszuführen. Er ist die Brücke, und die Brücke ist über den Fehler erreichbar.

Wer das Risiko tatsächlich getragen hat

Der übliche Reflex in europäischen Vorstandsetagen lautet, der Eigenbetrieb sei die konservative Variante. Die Daten bleiben auf dem eigenen Blech, die Frage nach dem Speicherort ist in einem Satz beantwortet, und man erspart der Aufsicht ein unangenehmes Schaubild. In den regulierten Branchen der EU, in der öffentlichen Verwaltung, im Bankwesen und in den größeren Mittelstandsgruppen ist dieser Reflex der Grund dafür, dass ein erheblicher Teil der ServiceNow-Landschaften nicht in der Cloud von ServiceNow läuft.

Dieses Advisory dreht das um. Wer die Cloud des Herstellers gewählt hatte, war in den ersten Apriltagen durch eine Gegenmaßnahme geschützt, die er nie anfordern musste. Wer sich für den Eigenbetrieb entschieden hatte, um die Kontrolle zu behalten, trug eine Lücke für Remote Code Execution ohne Authentifizierung durch April, Mai, Juni und den halben Juli und wurde erst informiert, als die Korrektur auslieferbar war. Kontrolle über den Betrieb hieß am Ende Eigentum am Zeitfenster der Gefährdung.

Nichts davon macht das Vorgehen von ServiceNow unlauter. Gegenmaßnahmen in einen Bestand auszurollen, den man selbst betreibt, geht schlicht schneller, als Patches in einen Bestand zu bringen, den man nicht betreibt, und Details eines Advisories zurückzuhalten, bis die Kunden handeln können, ist gängige Praxis und keine Vertuschung. Die Lehre für Betreiber ist enger und brauchbarer: "Der Hersteller hat es behoben" und "bei uns ist es behoben" sind zwei verschiedene Aussagen, und in diesem Fall lagen hundert Tage dazwischen.

Beide Aussagen sind gleichzeitig wahr

Am Wochenende des 18. und 19. Juli meldete die Threat-Intelligence-Gruppe Defused aktive Ausnutzung, wobei die ersten Versuche am Freitag, dem 17. Juli, beobachtet wurden. Das Advisory von ServiceNow hält am Montagmorgen weiterhin fest, man sei sich "derzeit keiner Ausnutzung gegen ServiceNow-Instanzen bewusst". Nebeneinandergelegt sieht das nach einem Hersteller aus, der sich mit dem Eingeständnis Zeit lässt.

Die Sache ist interessanter, und genau diese Auflösung ist der Kern der Geschichte. Die beiden Seiten vermessen unterschiedliche Grundgesamtheiten. ServiceNow verfügt über direkte Telemetrie in dem Bestand, den das Unternehmen selbst hostet, und dieser Bestand ist seit Anfang April durch Gegenmaßnahmen abgesichert, dort wird also tatsächlich nichts ausgenutzt. Defused beobachtet den Verkehr im offenen Internet, und dort stehen die von Kunden selbst betriebenen Instanzen. Die Grundgesamtheit, die der Hersteller nicht sehen kann, ist genau jene, die noch ungepatcht ist.

Der Satz des Herstellers ist damit zutreffend und zugleich als Eingangsgröße für Ihre Risikobewertung wertlos. "Keine bestätigte Ausnutzung" von einem SaaS-Anbieter ist eine Aussage über den Bestand dieses Anbieters, solange er nicht ausdrücklich etwas anderes sagt. Wenn Sie die Software selbst betreiben, beschreibt allein jener Ausnutzungsstatus Ihre Lage, den Sie aus Ihren eigenen Protokollen ableiten.

Der Exploit wartete nicht auf den Proof of Concept

Defused wurde konkret in der Beschreibung des Beobachteten. Die Payloads träfen, so die Meldung, "denselben Pre-Auth-Sink, den @SLCyberSec dokumentiert hat (/assessment_thanks.do), aber das Gadget für den Sandbox-Ausbruch erreicht dieselbe Code-Execution-Primitive auf einem anderen Weg als deren veröffentlichter PoC". Die Angreifer spielten den Exploit der Forscher also nicht einfach nach. Sie hatten dieselbe Primitive eigenständig erreicht und vom selben Ausgangspunkt aus ihre eigene Arbeit geleistet.

Dieses Detail zerlegt eine Planungsgewohnheit, die in änderungsgesteuerten Betrieben weit verbreitet ist: das Erscheinen eines öffentlichen Proof of Concept als Startsignal zu nehmen und im nächsten Wartungsfenster danach zu patchen. Hier traf die eigenständig entwickelte Fähigkeit zeitgleich mit der öffentlichen Analyse ein und nicht danach, und das Advisory selbst war am 13. Juli die letzte verlässliche Warnung, die überhaupt noch kam.

Was Sie vor Dienstag prüfen sollten

Fangen Sie bei der Release-Familie an, denn die Namen der Korrekturen erklären sich nicht von selbst. Die gepatchten Versionen sind Brazil EA und Brazil GA, Australia Patch 2, Zurich Patch 7b oder Zurich Patch 9 sowie Yokohama Patch 12 Hot Fix 1b oder Yokohama Patch 13. Alles unterhalb der jeweiligen Linie ist verwundbar, und eine selbst betriebene Instanz, die seit dem 13. Juli kein Wartungsfenster hatte, hat niemand für Sie repariert.

Gehen Sie anschließend davon aus, dass das Zeitfenster eine Rolle gespielt hat. Ziehen Sie die Zugriffsprotokolle für /assessment_thanks.do und sehen Sie sich gezielt den Parameter sysparm_assessable_type an. Prüfen Sie die Anlage von Administratorkonten über den gesamten Zeitraum statt nur über die letzten zwei Wochen, denn die Lücke erlaubt einem Angreifer genau das. Gehen Sie danach an die MID Server, suchen Sie nach unerwarteter Prozessausführung, und behalten Sie im Kopf, dass diese Hosts im internen Netz stehen und nicht davor. Genau das macht aus einem Plattformfehler ein Problem der lateralen Bewegung.

Wenn Sie fündig werden, läuft die Uhr auch regulatorisch und nicht nur technisch. Für wesentliche und wichtige Einrichtungen in der EU verlangt NIS2 eine Frühwarnung an das nationale CSIRT binnen 24 Stunden ab Kenntnis eines erheblichen Sicherheitsvorfalls und eine ausführlichere Meldung binnen 72 Stunden. Im Vereinigten Königreich, wo NIS2 nicht gilt, bleibt das NCSC der Meldeweg, und es ist dieselbe Arbeit an den Beweisen, die eine Meldung überhaupt lohnend macht.

Weiterlesen: Eine Anfrage konnte Ihre WordPress-Seite kapern  |  Patchen von SharePoint schließt die Tür nicht mehr