ServiceNow schließt drei kritische Lücken: Selbsthoster müssen handeln

Am 28. August 2026 wurden drei von ServiceNow behobene Schwachstellen der ServiceNow AI Platform öffentlich: CVE-2026-18885, CVE-2026-18886 und CVE-2026-74820. Der Bericht von BleepingComputer beschreibt Codeausführung, Rechteausweitung und SQL-Injection ohne Anmeldung oder Benutzerinteraktion; alle drei Fehler sind nach CVSS 4.0 mit 10,0 bewertet.

ServiceNow hat diese drei Lücken geschlossen und das Sicherheitsupdate auf seinen gehosteten Instanzen ausgerollt. Laut ServiceNow-Advisory KB3152242 wurden die Korrekturen Partnern und selbst hostenden Kunden bereitgestellt; dort müssen sie jedoch noch auf dem jeweils passenden Release-Zweig installiert werden.

Drei CVEs, drei unterschiedliche Angriffswirkungen

Das gemeinsame Risikoprofil ist eindeutig: Der Angriffsvektor liegt im Netzwerk, die Komplexität wird als niedrig eingestuft, besondere Angriffsvoraussetzungen sind nicht angegeben und weder ein Benutzerkonto noch die Mitwirkung eines Anwenders ist erforderlich. Die betriebliche Wirkung unterscheidet sich dennoch deutlich.

• CVE-2026-18885 – Code Injection: Ein nicht authentifizierter Angreifer kann unter bestimmten Umständen beliebigen Code innerhalb der Plattform ausführen. Dadurch kann er Instanzdaten außerhalb der vorgesehenen Zugriffsgrenzen lesen oder verändern. Authentifizierung: keine; Benutzerinteraktion: keine; CVSS 4.0: 10,0.
• CVE-2026-18886 – unzureichende Zugriffskontrolle: Die Schwachstelle kann das unbefugte Erstellen oder Verändern von Instanzdaten und damit eine Rechteausweitung ermöglichen. Anders als bei CVE-2026-18885 beschreibt ServiceNow hier keine beliebige Codeausführung. Authentifizierung: keine; Benutzerinteraktion: keine; CVSS 4.0: 10,0.
• CVE-2026-74820 – SQL-Injection: Ein nicht angemeldeter Angreifer kann unter bestimmten Umständen beliebige SQL-Anweisungen gegen die Datenbank einer Instanz ausführen und dadurch Daten außerhalb der vorgesehenen Berechtigungen lesen oder verändern. Authentifizierung: keine; Benutzerinteraktion: keine; CVSS 4.0: 10,0.

Ein vorgeschalteter Benutzer-Login ist daher kein ausreichender Beleg für Schutz. Entscheidend ist, ob der verwundbare Plattformbestandteil erreichbar ist und auf welchem vollständigen Build die Instanz tatsächlich läuft. ServiceNow hat keine weiteren technischen Bedingungen für die Formulierung „unter bestimmten Umständen“ veröffentlicht.

Diese Patch-Stände nennt die Warnung

Die Cyberwarnung von NHS England vom 28. August führt für alle drei CVSS-10,0-Lücken dieselben aktualisierten Stände auf. Weil mehrere Patch-Linien parallel existieren, ist die jeweils zur installierten Linie passende Angabe maßgeblich und nicht der numerisch höchste Wert der gesamten Release-Familie.

• Xanadu: Patch 11 Hot Fix 7a.
• Yokohama: Patch 12 Hot Fix 3b beziehungsweise Patch 13 Hot Fix 4 für die jeweilige Patch-Linie.
• Zurich: Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m im m-Branch, Patch 10 Hot Fix 3 im Standard-Branch sowie Patch 11 oder Patch 12 für die entsprechenden Linien.
• Australia: Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 oder Patch 5 für die jeweilige Linie.

Diese Angaben sind keine aufsteigende Liste austauschbarer Mindestversionen. Bei Zurich Patch 10 unterscheidet das Advisory ausdrücklich zwischen m-Branch und Standard-Branch; auch die übrigen Mehrfachangaben beziehen sich auf verschiedene gepflegte Linien. Release-Name, Patch, Hot Fix und gegebenenfalls Branch müssen deshalb gemeinsam verglichen werden.

Die NHS-Warnung enthält außerdem CVE-2026-6876, einen mit 8,7 bewerteten Sandbox-Escape-Fehler der Now Platform. Er gehört nicht zu den drei CVSS-10,0-Schwachstellen, auf die sich die Überschrift und die Patch-Entscheidung dieses Artikels konzentrieren.

Cloud-Rollout und Self-Hosted-Verantwortung

Bei gehosteten Instanzen hat ServiceNow die Korrektur selbst ausgerollt. Das bedeutet nicht, dass ein Kunde den technischen Status seiner konkreten Instanz ignorieren sollte, wohl aber, dass er den Hot Fix nicht wie bei einer selbst verwalteten Installation eigenständig verteilen muss.

Für Self-Hosted-Systeme belegt die Bereitstellung des Updates noch keine Installation. Erst der aktive Build zeigt, ob eine Instanz den für ihren Zweig genannten Stand erreicht. Wird eine Umgebung durch einen Partner betrieben, muss zusätzlich geklärt sein, wer Installation und Nachweis vertraglich und technisch übernimmt.

Produktionssysteme sind nicht die einzigen relevanten Ziele. Test-, Entwicklungs-, Schulungs- oder Ausweichinstanzen können ebenfalls betroffen sein, wenn sie erreichbar sind, reale Daten enthalten oder mit produktiven Diensten verbunden bleiben. Ihr Patch-Stand ist daher getrennt zu erfassen.

Prüfpfad für selbst verwaltete Instanzen

1. Zuständigkeit festhalten: Für jede Instanz klären, ob das eigene Unternehmen, ein Partner oder ServiceNow die Plattform patcht.
2. Build vollständig erfassen: Release-Familie, Patch, Hot Fix und gegebenenfalls Standard- oder m-Branch auslesen. Die Bezeichnung Xanadu, Yokohama, Zurich oder Australia allein genügt nicht.
3. Patch-Linie zuordnen: Den installierten Build mit dem aktualisierten Stand genau derselben Linie vergleichen. Ein Wert aus einem anderen Branch ist kein belastbarer Nachweis.
4. Aktive Installation bestätigen: Wartungsstatus, Änderungsprotokoll und laufenden Build kontrollieren. Ein heruntergeladener, freigegebener oder geplanter Hot Fix ist noch nicht wirksam.
5. Instanzbestand abgleichen: Neben Produktion auch erreichbare Neben-, Test- und Wiederherstellungssysteme einbeziehen und Abweichungen dokumentieren.

Zum Zeitpunkt der Veröffentlichung war ServiceNow keine böswillige Ausnutzung dieser drei Schwachstellen gegen ServiceNow-Instanzen bekannt. Der belastbare Abschluss für Selbsthoster ist dennoch nicht die Verfügbarkeit eines Updates, sondern der Nachweis, dass auf jeder betroffenen Instanz der zur jeweiligen Patch-Linie gehörende korrigierte Build aktiv ist.