Drei ServiceNow-Lücken mit Maximalwert: Selbsthoster müssen patchen

ServiceNow veröffentlichte am 27. August 2026 Korrekturen für drei kritische Schwachstellen der ServiceNow AI Platform. CVE-2026-18885, CVE-2026-18886 und CVE-2026-74820 erhielten jeweils den maximalen CVSS-v4.0-Wert 10,0. Laut der Sicherheitsmitteilung von ServiceNow wurden gehostete Instanzen aktualisiert und die Updates an Partner sowie selbst hostende Kunden ausgeliefert.

Damit entscheidet der Hosting-Typ über die unmittelbare Aufgabe: In der ServiceNow-Cloud hat der Anbieter die Korrekturen eingespielt, während Betreiber eigener Instanzen den passenden Release- und Patchstand selbst installieren müssen. Zum Berichtsstand vom 28. August erklärte ServiceNow, keine böswillige Ausnutzung der drei neuen Lücken zu kennen.

Drei Angriffswege ohne Anmeldung

Alle drei Schwachstellen sind über das Netzwerk erreichbar. ServiceNow bewertet die Angriffskomplexität als niedrig; weder vorherige Berechtigungen noch eine Benutzerinteraktion sind erforderlich. Eine erfolgreiche Ausnutzung ist nach den Herstellerbeschreibungen dennoch an nicht näher veröffentlichte Umstände gebunden.

• CVE-2026-18885: Eine Code-Injection in der GraphQL Composite Data API kann nicht angemeldeten Angreifern die Ausführung beliebigen Codes ermöglichen. Dabei könnten sie auf Instanzdaten zugreifen oder diese außerhalb der vorgesehenen Grenzen verändern.
• CVE-2026-18886: Eine unzureichende Zugriffskontrolle im Prozessor für den Upload von Systemkonfigurationsbildern kann das unbefugte Erstellen oder Ändern von Instanzdaten und damit eine Rechteausweitung erlauben.
• CVE-2026-74820: Eine SQL-Injection über eine dynamische Schema-ORDER-BY-Klausel kann beliebige SQL-Anweisungen gegen die zugrunde liegende Datenbank ermöglichen. Als mögliche Folgen nennt ServiceNow den Zugriff auf Instanzdaten und deren Veränderung.

Der gemeinsame CVSS-Vektor weist bei allen drei Fehlern hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit aus. Die CVE-Nummern stehen trotzdem für getrennte Schwachstellen und sollten in Inventar, Schwachstellenmanagement und Patchnachweis einzeln erfasst werden.

Patch-Matrix für Xanadu bis Australia

Die veröffentlichten Versionsangaben bezeichnen mehrere parallel gepflegte Patchlinien. Sie sind daher nicht als Abfolge zu lesen, die vollständig nacheinander installiert werden müsste. Entscheidend ist der korrigierte Stand derjenigen Linie, auf der die konkrete Instanz läuft.

Die von BleepingComputer dokumentierte Patch-Matrix nennt diese Grenzen:

• Xanadu: Patch 11 Hot Fix 7a.
• Yokohama: Patch 12 Hot Fix 3b oder Patch 13 Hot Fix 4, je nach Patchlinie.
• Zurich: Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m für den m-Branch, Patch 10 Hot Fix 3 für den Standardzweig sowie Patch 11 oder Patch 12.
• Australia: Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 oder Patch 5, jeweils passend zur vorhandenen Linie.

Als betroffen werden Builds vor dem jeweils einschlägigen korrigierten Stand geführt. Eine wichtige Ausnahme betrifft CVE-2026-18886: Ihr CVE-Datensatz stuft den Bereich vor Australia Patch 5 als „unknown“ ein, während die entsprechenden Einträge für CVE-2026-18885 und CVE-2026-74820 „affected“ lauten. Administratoren dieses Zweigs sollten den exakten Build deshalb gegen den einzelnen CVE-Datensatz und den ServiceNow-Hinweis prüfen, statt aus der zusammengefassten Matrix einen einheitlichen Status für alle drei Fehler abzuleiten.

Cloud und Eigenbetrieb trennen die Verantwortung

Bei von ServiceNow gehosteten Instanzen ist die technische Bereitstellung nach Herstellerangaben erfolgt. Das bedeutet nicht, dass Kunden Release und Konfiguration ignorieren können: Für interne Nachweise und Risikobewertungen bleibt festzuhalten, welcher Instanzstand tatsächlich vorliegt und ob abhängige Änderungen berücksichtigt werden müssen.

Im Eigenbetrieb liegt auch die Installation beim Betreiber. Er muss zunächst Release-Familie, Patchlinie und vollständigen Build bestimmen und anschließend den dazugehörigen korrigierten Stand einspielen. Aussagen wie „Zurich ist betroffen“ oder „Australia ist sicher“ sind ohne Patchlinie zu ungenau, weil innerhalb einer Release-Familie mehrere Wartungszweige mit eigenen Schwellen existieren.

Der Titelzusatz „Selbsthoster müssen patchen“ beschreibt damit einen konkreten Unterschied: ServiceNow hat diesen Kunden die Aktualisierungen bereitgestellt, aber nicht deren selbst betriebene Systeme aktualisiert. Erst die Installation des passenden Builds schließt die drei Lücken auf der jeweiligen Instanz.

Das neue Trio ist nicht CVE-2026-6875

Die drei am 27. August veröffentlichten CVSS-10-Lücken dürfen nicht mit CVE-2026-6875 vermischt werden. Diese im Juli veröffentlichte Schwachstelle ist ein mit CVSS 9,5 bewerteter Pre-Authentication-Sandbox-Escape der ServiceNow AI Platform. Nach der damaligen Veröffentlichung wurden Ausnutzungsaktivitäten gemeldet; ServiceNow erklärte jedoch, bei seiner Untersuchung keine Verbindung zu vom Unternehmen gehosteten Instanzen festgestellt zu haben.

Für CVE-2026-18885, CVE-2026-18886 und CVE-2026-74820 war die Lage am 28. August eine andere: ServiceNow kannte keine böswillige Ausnutzung, und die Prüfung von The Hacker News fand keinen öffentlich verfügbaren Exploit-Code für das Trio. Das ist eine zeitgebundene Bestandsaufnahme, kein Nachweis technischer Unausnutzbarkeit.

Auch CVE-2026-6876 gehört nicht zu den drei Maximalwert-Lücken: Der ebenfalls in der August-Mitteilung behandelte Sandbox-Escape betrifft die Now Platform und wurde mit CVSS 8,7 bewertet. Für die Patchentscheidung sollten Sicherheitsteams deshalb jede CVE separat führen und den Status der neuen drei Fehler nicht aus Meldungen über CVE-2026-6875 oder CVE-2026-6876 ableiten.

Offen bleibt, ob und wann technische Details oder Exploit-Code zu den drei neuen Schwachstellen veröffentlicht werden. Bestätigt sind derzeit die Angriffsvoraussetzungen, die möglichen Auswirkungen und die releaseabhängigen Korrekturen. Bei selbst gehosteten Instanzen ist die Maßnahme erst abgeschlossen, wenn der passende Build installiert und der Stand dokumentiert ist.