Viele Unternehmen behandeln ihre Workflow-Plattformen inzwischen wie neutrale Infrastruktur: Sie verbinden Tickets, Identitäten, Datenmodelle, Integrationen, Automatisierung und zunehmend auch KI-Agenten. Genau darin liegt das praktische Risiko der neuen ServiceNow-Meldung. Wenn eine solche Plattform verwundbar ist, geht es nicht nur um „noch eine Web-App“. Es geht um eine Schicht, die oft quer durch IT, Security Operations, HR, Einkauf, Kundendienst und interne Automatisierung reicht. Eine Schwachstelle dort kann Datenzugriff, Prozessmanipulation und Folgeschäden deutlich breiter machen als bei einem isolierten Tool.
ServiceNow hat am 27. August 2026 vier Schwachstellen in der ServiceNow AI Platform beziehungsweise Now Platform veröffentlicht und nach eigenen Angaben Updates auf gehostete Instanzen ausgerollt. Partner und selbst betriebene Kunden erhielten die entsprechenden Updates. Drei der vier Einträge tragen in den ServiceNow-CVE-Datensätzen eine CVSS-4.0-Bewertung von 10.0. Wichtig ist die Einordnung: ServiceNow meldet laut den CVE-Records keine bekannte bösartige Ausnutzung dieser neuen Lücken. Trotzdem ist das Thema relevant, weil die beschriebenen Angriffsvoraussetzungen niedrig sind und weil selbst gehostete Instanzen aktiv nachgezogen werden müssen.
Was technisch gemeldet wurde
Der erste Eintrag, CVE-2026-18885, betrifft laut ServiceNow-CNA-Record eine Code-Injection-Schwachstelle in der GraphQL Composite Data API der ServiceNow AI Platform. Unter bestimmten Umständen könnte ein nicht authentifizierter Angreifer beliebigen Code in der Plattform ausführen und auf Instanzdaten zugreifen oder sie verändern. Der zweite Eintrag, CVE-2026-18886, beschreibt eine fehlerhafte Zugriffskontrolle im System Configuration Image Upload Processor. Auch hier nennt ServiceNow nicht authentifizierten Zugriff als mögliche Voraussetzung; die Folge wäre das Erstellen oder Verändern von Instanzdaten mit Privilegieneskalation.
Der dritte 10.0-Eintrag ist CVE-2026-74820. Dabei geht es um SQL Injection über eine dynamische Schema-ORDER BY-Klausel. Laut CVE-Record kann ein nicht authentifizierter Nutzer unter bestimmten Umständen beliebige SQL-Statements gegen die zugrunde liegende Datenbank ausführen und dadurch Instanzdaten lesen oder verändern. Zusätzlich wurde CVE-2026-6876 veröffentlicht, eine Sandbox-Escape-Schwachstelle in der Now Platform. Dieser Eintrag ist niedriger bewertet, aber ebenfalls ernst zu nehmen, weil er Codeausführung innerhalb der Plattform ermöglichen kann.
The Hacker News und BleepingComputer haben die ServiceNow-Meldung unabhängig aufgegriffen. Beide bestätigen die Kernpunkte: drei neue maximale Schweregrade, Angriffsvektoren ohne Anmeldung und ohne Nutzerinteraktion für die 10.0-Fälle, sowie die Empfehlung, insbesondere selbst betriebene Umgebungen zeitnah auf die gepatchten Releases zu bringen. BleepingComputer weist zusätzlich darauf hin, dass ServiceNow die Plattform als Enterprise-PaaS für KI-gestützte Workflows positioniert und dass solche Instanzen in großen Organisationen tief in Geschäftsprozesse eingebunden sein können.
Betroffene Release-Stände und operative Realität
Die CVE-Datensätze nennen betroffene ServiceNow-Releases vor bestimmten Hotfix-Ständen in den Linien Xanadu, Yokohama, Zurich und Australia. Zu den genannten Zielständen gehören unter anderem Xanadu Patch 11 Hot Fix 7a, Yokohama Patch 12 Hot Fix 3b beziehungsweise Patch 13 Hot Fix 4, mehrere Zurich-Hotfix-Stände bis hin zu Patch 12 sowie Australia-Patches bis Patch 5. Für Entscheider ist nicht jedes Hotfix-Label auswendig relevant. Entscheidend ist: Gehostete Instanzen sollten ServiceNow-seitig aktualisiert worden sein, aber Partner-, dedizierte oder selbst betriebene Setups dürfen nicht pauschal als erledigt gelten.
Gerade ServiceNow-Umgebungen sind selten „Standardsoftware ohne Daten“. Sie enthalten Workflows, Rollen, Integrationen, Anhänge, Konfigurationsdaten, Incident-Informationen, Change-Prozesse, Asset-Informationen und häufig Schnittstellen zu Identitäts-, Cloud-, Security- und Ticketing-Systemen. Wenn eine Plattform mit KI-Funktionen zusätzlich Daten zusammenführt, Empfehlungen erzeugt oder Aktionen vorbereitet, steigt der Wert eines Angriffs noch einmal. Ein Angreifer muss nicht zwangsläufig die gesamte Umgebung übernehmen, um Schaden zu verursachen; schon manipulierte Instanzdaten, geänderte Berechtigungen oder ausgelesene Prozessinformationen können für Folgeschritte reichen.
Warum das ein AI-Security-Thema ist
Der Begriff „AI Platform“ darf hier nicht zu der falschen Schlussfolgerung führen, es gehe primär um ein Modellproblem. Die gemeldeten Klassen – Code Injection, Zugriffskontrollfehler, SQL Injection und Sandbox Escape – sind klassische Anwendungssicherheitsprobleme. Neu ist der Kontext: KI-Funktionen sitzen auf Plattformen, die Aktionen, Datenflüsse und Integrationen orchestrieren. Damit wird klassische AppSec wieder zur AI-Security-Grundlage.
Das ist ein Muster, das Unternehmen in vielen KI-Projekten unterschätzen. Prompt-Injection, Agentenrechte und Modellverhalten sind wichtig, aber sie sind nur eine Schicht. Darunter liegen APIs, Upload-Prozessoren, Datenbankschichten, Sandboxen, Rollenmodelle, Plugin-Architekturen und Konnektoren. Wenn diese Schichten schwach sind, hilft auch ein vorsichtig formulierter Systemprompt wenig. Die Sicherheitsgrenze muss außerhalb des Modells durchgesetzt werden: durch Authentifizierung, Autorisierung, Eingabevalidierung, Mandantentrennung, geprüfte Tool-Ausführung, Logging und harte Netzwerk- und Datenbankgrenzen.
Konkrete Implikationen für Unternehmen
Erstens sollte das Thema in den normalen Vulnerability- und Change-Prozess, aber mit höherer Priorität als „gewöhnliche SaaS-Notiz“. Verantwortliche sollten klären, welche ServiceNow-Instanzen existieren, ob sie hosted, partner-managed oder self-hosted betrieben werden und welcher Patchstand tatsächlich aktiv ist. Bei selbst betriebenen oder besonders integrierten Umgebungen reicht ein Ticket „Vendor hat gepatcht“ nicht.
Zweitens gehört ein kurzer Exposure-Check dazu. Welche Instanzen sind aus dem Internet erreichbar? Welche Admin-, Integration- und API-Konten existieren? Welche Secrets liegen in Prozessumgebungen, Integrationsprofilen oder angeschlossenen Systemen? Welche Datenklassen wären betroffen, wenn Instanzdaten gelesen oder verändert würden? Solche Fragen sollten nicht erst nach einem bestätigten Exploit gestellt werden.
Drittens sollten Security-Teams nach ungewöhnlichen Vorgängen suchen, auch wenn ServiceNow keine bekannte Ausnutzung meldet. Sinnvoll sind Prüfungen auf unerwartete Rollenänderungen, neue oder geänderte Integrationen, auffällige Uploads, ungewöhnliche GraphQL-/API-Nutzung, verdächtige SQL-Fehler, neue Skripte, neue Administratoren und Veränderungen an Workflows mit hohen Rechten. Bei gehosteten Instanzen wird ein Teil dieser Telemetrie beim Anbieter liegen; trotzdem können Kunden ihre Audit-Logs, SIEM-Anbindungen und Change-Historien auswerten.
Viertens sollten Unternehmen die Gelegenheit nutzen, ihre KI- und Workflow-Governance zu schärfen. Eine Plattform, die Tickets, Daten und Agentenaktionen verbindet, braucht klare Eigentümer, minimale Rechte für Integrationen, getrennte Umgebungen für Entwicklung und Produktion, nachvollziehbare Genehmigungen für riskante Aktionen und getestete Rückrollpfade. Besonders kritisch sind Verbindungen zu Identitätsverwaltung, Cloud-Konten, CI/CD, Security-Tools und Datenbanken.
Risiken und Grenzen der Bewertung
Die öffentliche Informationslage ist noch begrenzt. Die CVE-Records liefern strukturierte Herstellerangaben, aber keine tiefen technischen Exploit-Details. The Hacker News schrieb, dass zum Zeitpunkt der Prüfung kein öffentlicher Exploit-Code für die drei 10.0-Schwachstellen bekannt war und dass die Einträge nicht im CISA-KEV-Katalog standen. Das senkt die Dringlichkeit nicht auf „später“, verhindert aber unnötige Panik. Es gibt aktuell einen Unterschied zwischen hoher technischer Schwere und bestätigter aktiver Ausnutzung.
Gleichzeitig zeigt die ServiceNow-Historie, warum abwartende Patchfenster riskant sind. BleepingComputer verweist auf frühere ServiceNow-Schwachstellen, die in den vergangenen Jahren in Angriffen genutzt wurden, und auf eine im Juli diskutierte kritische AI-Platform-Sandbox-Problematik. Für große Plattformen gilt: Sobald Details und reproduzierbare Tests breiter zirkulieren, werden Scanner und opportunistische Angreifer schnell folgen.
Fazit
Die neuen ServiceNow-CVEs sind kein Beleg dafür, dass „KI“ selbst die Schwachstelle ist. Sie zeigen etwas Praktischeres: Enterprise-KI erbt die Risiken der Plattformen, auf denen sie läuft. Wer KI-Agenten, Workflow-Automatisierung und Unternehmensdaten zusammenführt, muss Patchmanagement, AppSec und Governance als Teil der AI-Security behandeln. Für ServiceNow-Kunden heißt das jetzt: Patchstand verifizieren, selbst betriebene Instanzen priorisieren, Logs prüfen, Integrationsrechte begrenzen und die Plattform nicht nur als SaaS-Komfortschicht, sondern als kritischen Kontrollpunkt betrachten.
Quellen: ServiceNow-CVE-Records zu CVE-2026-18885, CVE-2026-18886, CVE-2026-74820 und CVE-2026-6876 über cveawg.mitre.org; The Hacker News, „Three CVSS 10.0 ServiceNow Flaws Could Let Unauthenticated Attackers Execute Code and SQL“, 28. August 2026; BleepingComputer, „ServiceNow warns of three max severity security vulnerabilities“, 28. August 2026.
