Ein aktueller Hinweis mit einer konkreten Versionsliste

Am 25. September 2026 veröffentlichte das Canadian Centre for Cyber Security den Hinweis AV26-963 zu Schwachstellen in ServiceNow AI Platform. Der praktische Umfang ist klar: Administratoren und Sicherheitsteams sollten die Version ihrer Instanz ermitteln und mit den vom Anbieter genannten behobenen Ständen vergleichen. Der kanadische Hinweis bezieht sich auf Informationen mit Stand vom 24. September. Für sich genommen bestätigt er weder, dass eine bestimmte Instanz verwundbar ist, noch dass sie kompromittiert wurde.

Der Hinweis ist gerade deshalb hilfreich, weil er den Produktnamen von den betroffenen Versionszweigen unterscheidet. Es reicht nicht, zu wissen, dass ein Unternehmen ServiceNow nutzt oder seine Umgebung zu einer neueren Produktfamilie gehört: Der Zweig und der installierte Patch müssen geprüft werden. Die betriebliche Entscheidung hängt von diesem Vergleich ab. Unternehmen mit gehosteten, selbstverwalteten oder durch Dritte betreuten Umgebungen sollten außerdem klären, wer das Update einspielt und wie die Durchführung nachgewiesen wird. Ähnlich aussehende Versionsbezeichnungen können unterschiedliche Wartungspfade bedeuten; der Vergleich muss daher den genauen Zweig und Hotfix der Instanz berücksichtigen. Auch das Datum des Hinweises ist wichtig: Er beschreibt den damaligen Kenntnisstand und nicht zwangsläufig spätere Entwicklungen.

Welche Zweige mit den Patches zu vergleichen sind

Der Hinweis führt Versionen vor drei Australia-Ständen auf: Patch 2 Hot Fix 4b W32, Patch 4 Hot Fix 3 und Patch 5. Für Yokohama gilt Yokohama Patch 13 Hot Fix 5a als Schwelle. Für Zurich nennt der Hinweis drei unterschiedliche Referenzen: Patch 10 Hot Fix 3b, Patch 10 Hot Fix 4a W32 und Patch 11 Hot Fix 3. Die Formulierung „früher als“ bedeutet, dass Administratoren ihre genaue Version mit der jeweiligen Schwelle vergleichen müssen. Sie sollten nicht annehmen, jede Installation derselben Familie sei bereits behoben.

Wichtig ist die Einschränkung, dass der Hinweis keine einzelne Patchnummer für alle Zweige nennt. Für Zurich sind zudem mehrere Updatepfade aufgeführt. Die Liste sollte daher nicht zu einer vereinfachten Regel wie „den höchsten Patch installieren“ verkürzt werden. Ausgangsversion, Wartungsplan und Servicemodell können bestimmen, welcher Weg geeignet ist. Lässt sich der Zweig samt Hotfix anhand des internen Inventars nicht sicher feststellen, sollte der zuständige Administrator oder der Anbietersupport um Bestätigung gebeten werden. Halten Sie fest, welche Schwelle für jede Umgebung gilt und worauf diese Einschätzung beruht; eine allgemeine Produktfamilienbezeichnung ersetzt die Prüfung nicht.

Fünf CVE-Kennungen, aber keine fünf vollständigen technischen Beschreibungen

Der Hinweis des italienischen CSIRT der Toskana, der auf das ServiceNow-Bulletin verweist, führt fünf Kennungen auf: CVE-2026-86857, CVE-2026-86858, CVE-2026-86859, CVE-2026-86860 und CVE-2026-13016. Außerdem stuft er die Gruppe als zwei kritische und drei schwerwiegende Schwachstellen ein. Das macht deutlich, dass die Versionsliste mehrere Schwachstellen betrifft. Es ersetzt jedoch nicht die technische Beschreibung zu jeder CVE und belegt für sich genommen nicht, ob eine bestimmte Konfiguration betroffen ist.

In den bei dieser Prüfung zugänglichen Einträgen wird CVE-2026-86857 als Autorisierungsproblem beschrieben, das einer authentifizierten Person Zugriff auf AI-Platform-Daten ermöglichen könnte, für die sie keine Berechtigung hat. CVE-2026-86859 wird als Autorisierungsproblem beschrieben, das möglicherweise nicht authentifizierten Zugriff auf Daten ermöglicht. Diese Beispiele zeigen, weshalb Zugriffskontrolle und Offenlegung von Informationen relevant sind; sie rechtfertigen jedoch nicht, dieselben Einzelheiten den übrigen drei Kennungen zuzuschreiben. Leiten Sie keine konkreten Techniken, Bedingungen oder Folgen für jede CVE allein aus der zusammengefassten Liste ab. Schweregrade und Kennungen bieten eine Orientierung, ersetzen aber weder die technische Beschreibung noch die Angaben zur Anwendbarkeit der einzelnen Schwachstelle.

Was über Ausnutzung und Umfang bekannt ist

In der Beschreibung des Eintrags zu CVE-2026-86857 erklärt ServiceNow, ein Update für gehostete Instanzen bereitgestellt und es Partnern sowie selbstverwaltenden Kunden zur Verfügung gestellt zu haben. Laut demselben Text waren dem Unternehmen zum Zeitpunkt der Veröffentlichung des Eintrags keine böswilligen Angriffe auf ServiceNow-Instanzen bekannt. Diese Aussage muss zeitlich eingeordnet bleiben: Sie beschreibt den damaligen Kenntnisstand des Anbieters, beweist nicht, dass es nie eine Ausnutzung gegeben hat, und garantiert nicht, dass später keine weiteren Informationen bekannt werden.

Der kanadische Hinweis nennt Produkt und Versionen, berichtet jedoch nicht über konkrete Vorfälle bei Anwenderorganisationen und lässt keine Aussage darüber zu, wie viele Instanzen betroffen sein könnten. „Schwachstelle veröffentlicht“ darf nicht mit „Einbruch bestätigt“ gleichgesetzt werden. Zur Bewertung eines konkreten Falls sind Informationen aus der Instanz selbst, Protokolle und eine Bestätigung des Anbieters erforderlich. Die geprüften Quellen rechtfertigen keine Behauptung, dass diese Schwachstellen aktiv ausgenutzt werden. Unternehmen sollten daher weder das Fehlen gemeldeter Vorfälle noch einen allgemeinen Produkthinweis als abschließende Bewertung der eigenen Umgebung auffassen.

Prüfliste für Betrieb und Sicherheit

Ermitteln Sie zunächst das Servicemodell und die zuständige Stelle für die Wartung. Wird die Instanz von ServiceNow gehostet, bitten Sie um Bestätigung, dass das betreffende Update auf diese Umgebung angewendet wurde, und dokumentieren Sie Antwort und Datum. Bei selbstverwalteten Installationen oder einer Wartung durch einen Partner vergleichen Sie den genauen Zweig und Patchstand mit der Liste im Hinweis und stimmen das Update gemäß den Anweisungen von ServiceNow ab. Der öffentliche Hinweis empfiehlt, die angegebenen Links zu prüfen und erforderliche Updates anzuwenden; er nennt keine universelle Konsolenprozedur, die für alle Bereitstellungen als gültig vorausgesetzt werden kann.

Dokumentieren Sie anschließend den Abschlussnachweis: Zweig, Patch oder Hotfix, Anwendungsdatum und die für die Validierung verantwortliche Person. Betreibt das Unternehmen mehrere Umgebungen – etwa Produktion, Test oder getrennte Instanzen für Geschäftsbereiche –, prüfen Sie jede einzeln, statt den Status einer Installation auf die übrigen zu übertragen. Behandeln Sie jede Version, die unter den maßgeblichen Schwellen zu liegen scheint, als noch offen, bis der Support den Behebungspfad bestätigt. Erreicht die Version bereits den genannten Stand, bewahren Sie den Nachweis des Vergleichs auf; betrachten Sie ihn nicht automatisch als vollständige Bewertung anderer Risiken oder Konfigurationen. Eine datierte Dokumentation erleichtert spätere Prüfungen, falls sich Wartungsverantwortung oder Hostingmodell ändern.

Entscheidend ist die genaue Version, nicht eine Annahme

Die zum 26. September 2026 überprüfbare Schlussfolgerung ist begrenzt: Das Canadian Centre for Cyber Security veröffentlichte eine Warnung zu ServiceNow AI Platform mit konkreten Zweigen und Patchständen; eine CSIRT-Zusammenfassung führt fünf CVEs auf; und die geprüften Einträge beschreiben zwei davon als Probleme mit Autorisierung und Datenzugriff. Für Administratoren ist es sinnvoll, den genauen Stand jeder Instanz mit der Liste zu vergleichen, den Abdeckungsumfang gegebenenfalls bei ServiceNow bestätigen zu lassen und die relevanten Updates gemäß dem Anbieterbulletin anzuwenden.

Es bestehen Informationsgrenzen. Der Hinweis beschreibt für sich genommen weder die technischen Bestandteile aller fünf CVEs noch die jeweilige Einzelwirkung oder den Ausnutzungsstatus sämtlicher Instanzen. Dass diese Details im öffentlichen Hinweis fehlen, beweist nicht, dass sie nicht existieren; es verhindert lediglich, sie hier zu behaupten. Bis der Anbieter oder technische Einträge weitere Informationen liefern, sollte die Priorität nicht darin bestehen, über Vorfälle zu spekulieren, sondern den Patchstand jeder Bereitstellung zu prüfen und die Bestätigung zu dokumentieren. Trennen Sie spätere Klarstellungen des Anbieters von den durch diesen Hinweis belegten Tatsachen und überprüfen Sie betroffene Umgebungen erneut, wenn sich Schwellen oder Wartungshinweise ändern.