{"id":76,"date":"2026-06-12T08:18:07","date_gmt":"2026-06-12T08:18:07","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/12\/servicenow-datenleck-api-luecke-2026\/"},"modified":"2026-06-12T08:20:15","modified_gmt":"2026-06-12T08:20:15","slug":"servicenow-datenleck-api-luecke-2026","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/12\/servicenow-datenleck-api-luecke-2026\/","title":{"rendered":"ServiceNow Datenleck: 44 Tage offene API-L\u00fccke [2026]"},"content":{"rendered":"\n

Am 10. Juni 2026 best\u00e4tigte ServiceNow einen Sicherheitsvorfall, der Kundendaten in der Cloud-Plattform offengelegt hat. Ein einzelner falsch konfigurierter API-Endpunkt erlaubte es nicht authentifizierten Nutzern, unter bestimmten Umst\u00e4nden weiter reichenden Zugriff auf gehostete ServiceNow-Instanzen zu erhalten, als vorgesehen war. Das ServiceNow Datenleck<\/strong> trifft eine Plattform, die in Konzernen, Beh\u00f6rden und kritischen Infrastrukturen im DACH-Raum als zentrales System f\u00fcr IT-Service-Management, Workflows und Asset-Verwaltung l\u00e4uft. Brisant ist nicht nur die L\u00fccke selbst, sondern die Chronologie: Zwischen der ersten vertraulichen Meldung und dem Patch lagen 44 Tage.<\/p>\n\n\n\n

Dieser Beitrag ordnet den Vorfall faktenbasiert ein. Wir rekonstruieren die Zeitleiste, erkl\u00e4ren die technische Schwachstelle am Endpunkt \/api\/now\/related_list_edit\/create<\/code>, bewerten ServiceNows Kommunikation, vergleichen den Fall mit fr\u00fcheren SaaS-Vorf\u00e4llen und ziehen f\u00fcnf Prognosen f\u00fcr die API-Sicherheit. Alle Zahlen und Zitate stammen aus den offiziellen Stellungnahmen von ServiceNow und der Berichterstattung etablierter Sicherheitsmedien.<\/p>\n\n\n\n

Was beim ServiceNow Datenleck geschah: Der Vorfall im \u00dcberblick<\/h2>\n\n\n\n

ServiceNow spielte am 5. Juni 2026 ein Sicherheitsupdate auf gehostete Kundeninstanzen ein. Anlass war eine Schwachstelle, die laut Unternehmen “einem nicht authentifizierten Nutzer unter bestimmten Umst\u00e4nden erlauben konnte, weiter reichenden Zugriff auf ServiceNow-Instanzen zu erhalten, als beabsichtigt war”. Das Update \u00e4nderte die Konfiguration eines REST-Endpunkts so, dass Anfragen nun zwingend eine Authentifizierung erfordern.<\/p>\n\n\n\n

Die verd\u00e4chtige Aktivit\u00e4t begann nach Rekonstruktion der Sicherheitsmedien um den 2. Juni 2026. Bereits am 3. und 4. Juni reichten Kunden \u00fcber Bug-Bounty-Programme Hinweise auf das Problem ein. ServiceNow best\u00e4tigte, dass Angreifer bei einer Teilmenge der Kunden erfolgreich sogenannte Instanztabellen abfragen konnten. Welche Datens\u00e4tze konkret eingesehen wurden, legte das Unternehmen nicht offen. Eine \u00f6ffentliche Mitteilung folgte am 9. Juni, das aktualisierte Advisory am 10. Juni 2026.<\/p>\n\n\n\n

ServiceNow ist kein Randanbieter. Die Plattform betreibt Service-Desks, Genehmigungs-Workflows, Konfigurationsdatenbanken (CMDB) und HR-Prozesse bei einem Gro\u00dfteil der weltweit gr\u00f6\u00dften Unternehmen sowie bei zahlreichen \u00f6ffentlichen Stellen. Genau deshalb wiegt eine unauthentifizierte L\u00fccke schwer: Eine einzige offene Schnittstelle multipliziert sich \u00fcber tausende Mandanten hinweg. Das ServiceNow Datenleck<\/strong> ist damit weniger ein klassischer Einbruch als ein Konfigurationsfehler mit Plattform-Reichweite.<\/p>\n\n\n\n

Die technische Schwachstelle: Ein API-Endpunkt ohne Authentifizierung<\/h2>\n\n\n\n

Im Kern steht eine API-Fehlkonfiguration, keine ausgefeilte Exploit-Kette. Der betroffene REST-Endpunkt \/api\/now\/related_list_edit\/create<\/code> war so eingestellt, dass das Flag requires_authentication<\/code> auf false<\/code> stand. \u00dcbersetzt hei\u00dft das: Der Endpunkt akzeptierte Anfragen, ohne ein g\u00fcltiges Login, ein Token oder ein Passwort zu verlangen. Wer die richtige URL und die passenden Parameter kannte, konnte Daten abfragen, die eigentlich hinter einer Anmeldung liegen sollten.<\/p>\n\n\n\n

Wie der Endpunkt missbraucht werden konnte<\/h3>\n\n\n\n

Der Endpunkt geh\u00f6rt zum Mechanismus, \u00fcber den ServiceNow verkn\u00fcpfte Listen (related lists) bearbeitet. Steht die Authentifizierung auf false<\/code>, l\u00e4sst sich die zugrundeliegende Logik nutzen, um Datens\u00e4tze aus Instanztabellen zu lesen, ohne die normalen Zugriffskontrolllisten (ACLs) zu durchlaufen. Genau diese ACL-Schicht ist das Sicherheitsfundament jeder ServiceNow-Instanz. Wird sie \u00fcber einen offenen Endpunkt umgangen, greift der Schutz nicht mehr. Das Sicherheitsupdate vom 5. Juni setzte requires_authentication<\/code> auf true<\/code> und schloss die L\u00fccke.<\/p>\n\n\n\n

Die beobachtete IP-Adresse 51.159.98.241<\/h3>\n\n\n\n

Mehrere Sicherheitsanalysen nennen die IP-Adresse 51.159.98.241<\/code> als Quelle der verd\u00e4chtigen Anfragen an den verwundbaren Endpunkt. F\u00fcr betroffene Unternehmen ist dieser Indicator of Compromise (IOC) der erste konkrete Suchwert: Wer in den API-Logs Treffer auf \/api\/now\/related_list_edit\/create<\/code> oder Zugriffe von dieser IP findet, sollte den Zeitraum Anfang Juni 2026 forensisch pr\u00fcfen. Fehlkonfigurationen wie diese fallen im Alltag selten auf, weil sie nicht wie eine klassische Schwachstelle aussehen, sondern wie eine regul\u00e4re Einstellung.<\/p>\n\n\n\n

Zeitleiste: 44 Tage zwischen Meldung und Patch<\/h2>\n\n\n\n

Der heikelste Aspekt der ServiceNow Sicherheitsl\u00fccke ist die Reaktionszeit. Eine vertrauliche Bug-Bounty-Meldung, die ein sehr \u00e4hnliches Problem beschrieb, ging laut Unternehmen bereits am 22. April 2026 ein. Gepatcht wurde erst am 5. Juni, rund 44 Tage sp\u00e4ter. In Foren berichten Kunden zudem, das Unternehmen habe bereits ab dem 7. April von Auff\u00e4lligkeiten gewusst. Die folgende Tabelle fasst die belegten Eckdaten zusammen.<\/p>\n\n\n\n

Datum<\/th>Ereignis<\/th><\/tr><\/thead>
22. April 2026<\/td>Vertrauliche Bug-Bounty-Meldung zu einer sehr \u00e4hnlichen Schwachstelle geht bei ServiceNow ein<\/td><\/tr>
2. Juni 2026<\/td>Beginn der beobachteten Abfrageaktivit\u00e4t gegen Kundeninstanzen<\/td><\/tr>
3. bis 4. Juni 2026<\/td>Kunden melden das Problem \u00fcber Bug-Bounty-Programme<\/td><\/tr>
5. Juni 2026<\/td>ServiceNow spielt Sicherheitsupdate auf gehostete Instanzen ein (requires_authentication = true)<\/td><\/tr>
9. Juni 2026<\/td>Erste \u00f6ffentliche Berichterstattung \u00fcber den Vorfall<\/td><\/tr>
10. Juni 2026<\/td>ServiceNow aktualisiert das offizielle Advisory<\/td><\/tr>
Stand 12. Juni 2026<\/td>Kein CVE vergeben, Umfang der eingesehenen Daten weiterhin nicht beziffert<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Eine Spanne von 44 Tagen wirkt im Kontext aktueller Bedrohungslagen lang. Der Fortinet Global Threat Landscape Report 2026 betont, dass die Zeit bis zur Ausnutzung neuer Schwachstellen inzwischen in Stunden gemessen wird, nicht in Wochen. Jeder Tag mit einem offenen, unauthentifizierten Endpunkt ist in dieser Logik ein Tag zu viel.<\/p>\n\n\n\n

Welche Daten betroffen waren und wer gef\u00e4hrdet ist<\/h2>\n\n\n\n

ServiceNow nannte keine konkreten Datenkategorien, die abgeflossen sein k\u00f6nnten. Klar ist nur: Bei einer Teilmenge der Kunden wurden Instanztabellen erfolgreich abgefragt. Welche Inhalte das umfasst, ergibt sich aus dem typischen Funktionsumfang der Plattform. Genau diese Unbestimmtheit macht die Risikobewertung f\u00fcr betroffene Unternehmen schwierig.<\/p>\n\n\n\n

In ServiceNow-Instanzen liegen \u00fcblicherweise hochsensible Gesch\u00e4ftsdaten. Dazu z\u00e4hlen IT-Support-Tickets, Mitarbeiterdatens\u00e4tze, interne Dokumentation, Asset-Inventare, gemeldete Sicherheitsvorf\u00e4lle, Workflow-Daten sowie Konfigurationsdetails von Unternehmenssystemen. Ein Angreifer, der diese Tabellen abfragt, gewinnt potenziell eine Landkarte der gesamten IT-Landschaft eines Konzerns, von offenen Schwachstellen in Tickets bis zu Zugangsstrukturen in der CMDB.<\/p>\n\n\n\n

Betroffen sind laut ServiceNow Kunden, die sich auf dem Plattform-Release “Australia” befinden, sowie Kunden, die auf fr\u00fcheren Releases bestimmte Konfigurations\u00e4nderungen vorgenommen hatten. Damit ist das Risiko nicht universell, aber auch nicht eng begrenzt. Wer eine selbst gehostete oder stark angepasste Instanz betreibt, sollte die eigene Konfiguration unabh\u00e4ngig vom Release pr\u00fcfen. Mehr Hintergrund zur Mechanik solcher Vorf\u00e4lle bietet unser Grundlagenartikel zu Datenlecks und ihrer Entstehung<\/a>.<\/p>\n\n\n\n

ServiceNows Reaktion: “Sicherheitsforscher, keine Angreifer”<\/h2>\n\n\n\n

ServiceNow ordnet den Vorfall auff\u00e4llig zur\u00fcckhaltend ein. Das Unternehmen erkl\u00e4rt, die beobachtete Aktivit\u00e4t sei nach aktuellem Ermittlungsstand Sicherheitsforschern und kundeneigenen Forschungsteams zuzuschreiben, nicht b\u00f6swilligen Akteuren. Gegen\u00fcber TechCrunch pr\u00e4zisierte ServiceNow-Sprecherin Courtney Johnson diese Einsch\u00e4tzung.<\/p>\n\n\n\n

“Neben unserer eigenen Untersuchung standen wir in Kontakt mit den Sicherheitsforschern, die das Problem urspr\u00fcnglich gemeldet haben, und k\u00f6nnen best\u00e4tigen, dass die Hinweise auf die beobachtete Aktivit\u00e4t von diesen Forschern und Kundenforschungsteams stammen, nicht von b\u00f6swilligen Akteuren.”<\/p>Courtney Johnson, Sprecherin von ServiceNow, gegen\u00fcber TechCrunch<\/cite><\/blockquote>\n\n\n\n

Johnson erg\u00e4nzte: “Die Sicherheitsforscher haben mitgeteilt, dass ihre Aktivit\u00e4t ausschlie\u00dflich der Einreichung von Bug-Bounty-Meldungen diente und keine Daten genutzt oder gespeichert wurden.” Diese Darstellung entlastet das Unternehmen erheblich, denn sie verschiebt den Vorfall von einem aktiven Datenabfluss hin zu kontrollierter Sicherheitsforschung. Sie st\u00fctzt sich allerdings auf die Selbstauskunft der Forscher, nicht auf einen vollst\u00e4ndig forensisch belegten Nachweis gegen\u00fcber der \u00d6ffentlichkeit.<\/p>\n\n\n\n

Kritik an der Transparenz: Warum Kunden im Dunkeln blieben<\/h2>\n\n\n\n

Mehrere Fachmedien kritisieren, dass ServiceNow zu wenig \u00fcber den tats\u00e4chlichen Hergang preisgibt. Das Unternehmen benannte weder die Zahl der betroffenen Kunden noch die Kategorien der eingesehenen Daten. Das Advisory war zudem zun\u00e4chst nur eingeloggt im Kundenportal abrufbar, was die Verbreitung der Warnung verlangsamte. F\u00fcr Sicherheitsverantwortliche, die schnell entscheiden m\u00fcssen, ob sie eine Meldung an Aufsichtsbeh\u00f6rden ausl\u00f6sen, ist diese Informationslage problematisch.<\/p>\n\n\n\n

Die Spannung ist offensichtlich. Einerseits beschreibt ServiceNow den Vorfall als harmlose Forschungsaktivit\u00e4t ohne Datenmissbrauch. Andererseits r\u00e4umt das Unternehmen ein, dass bei einer Teilmenge der Kunden Instanztabellen erfolgreich abgefragt wurden. Beide Aussagen lassen sich vereinbaren, doch ohne Zahlen bleibt f\u00fcr betroffene Organisationen offen, ob sie nach DSGVO Artikel 33 binnen 72 Stunden meldepflichtig sind. Wer im DACH-Raum eine ServiceNow-Instanz betreibt, sollte diese Frage konservativ und im Zweifel mit dem Datenschutzbeauftragten kl\u00e4ren.<\/p>\n\n\n\n

Kein CVE, viel Verwirrung: Das Problem mit der Einordnung<\/h2>\n\n\n\n

Bis zum 12. Juni 2026 hat ServiceNow der Schwachstelle keine CVE-Nummer zugewiesen. Das Unternehmen erkl\u00e4rte, man pr\u00fcfe noch, ob eine CVE vergeben werde. Das klingt nach einer Formalie, hat aber praktische Folgen. CVE-Eintr\u00e4ge sind die gemeinsame Sprache der Sicherheitsbranche. Ohne CVE taucht eine L\u00fccke nicht automatisch in Schwachstellen-Scannern, Threat-Intelligence-Feeds oder den Pflichtkatalogen wie der CISA-KEV-Liste auf.<\/p>\n\n\n\n

F\u00fcr SaaS-Plattformen ist das ein Sonderfall. Klassische CVEs adressieren Software, die Kunden selbst installieren und patchen. Bei einer vom Anbieter gehosteten L\u00fccke patcht der Anbieter zentral, und der Kunde erf\u00e4hrt es im besten Fall \u00fcber ein Advisory. Das verschiebt Verantwortung und Sichtbarkeit. Wenn kein CVE existiert und das Advisory hinter einem Login liegt, wird ein realer Vorfall f\u00fcr externe Beobachter nahezu unsichtbar. Diese strukturelle L\u00fccke in der SaaS-Sicherheit zeigt der ServiceNow-Fall exemplarisch.<\/p>\n\n\n\n

Marktauswirkungen: Was der Vorfall f\u00fcr SaaS-Sicherheit bedeutet<\/h2>\n\n\n\n

Der wirtschaftliche Kern des Vorfalls liegt nicht in einer L\u00f6segeldforderung, sondern im Vertrauensmodell der SaaS-Branche. Unternehmen lagern gesch\u00e4ftskritische Prozesse an Plattformen wie ServiceNow aus, weil sie davon ausgehen, dass der Anbieter Sicherheit und Konfiguration besser beherrscht als die eigene IT. Ein unauthentifizierter Endpunkt, der \u00fcber 44 Tage offen blieb, kratzt genau an dieser Annahme.<\/p>\n\n\n\n

Der Global Cybersecurity Outlook 2026 des World Economic Forum verweist darauf, dass Cyber-Betrug und Phishing 2026 die h\u00f6chste Priorit\u00e4t f\u00fcr Sicherheitsverantwortliche bilden, gefolgt von Risiken durch KI-Schwachstellen. SaaS-Fehlkonfigurationen passen in dieses Bild: Sie sind g\u00fcnstig auszunutzen, schwer zu entdecken und skalieren \u00fcber die Mandantenstruktur der Plattform. Der Markt reagiert mit wachsender Nachfrage nach SaaS Security Posture Management (SSPM), also Werkzeugen, die Konfigurationen von Cloud-Diensten kontinuierlich gegen sichere Vorgaben pr\u00fcfen.<\/p>\n\n\n\n

F\u00fcr ServiceNow selbst ist der Reputationsschaden begrenzt, solange die Forscher-These h\u00e4lt und kein b\u00f6swilliger Datenabfluss nachgewiesen wird. Sollte sich das Bild drehen, etwa durch Belege f\u00fcr eine breitere Ausnutzung, verschiebt sich die Diskussion schnell von einem Konfigurationsfehler zu einem grunds\u00e4tzlichen Governance-Problem. Parallelen zu anderen kritischen Schwachstellen wie der Citrix-NetScaler-L\u00fccke<\/a> liegen nahe, auch wenn die technische Natur eine andere ist.<\/p>\n\n\n\n

ServiceNow im Vergleich: API-L\u00fccken bei anderen SaaS-Plattformen<\/h2>\n\n\n\n

Der Vorfall reiht sich in eine Serie von SaaS- und Datentransfer-Schwachstellen der letzten Jahre ein. Die folgende Tabelle vergleicht das ServiceNow Datenleck mit anderen prominenten F\u00e4llen. Sie zeigt ein wiederkehrendes Muster: Nicht der raffinierte Exploit dominiert, sondern offene Schnittstellen, kompromittierte Zugangsdaten und Fehlkonfigurationen.<\/p>\n\n\n\n

Vorfall \/ Plattform<\/th>Zeitraum<\/th>Schwachstellentyp<\/th>Einordnung<\/th><\/tr><\/thead>
ServiceNow (API-Endpunkt)<\/td>Juni 2026<\/td>Unauthentifizierter REST-Endpunkt<\/td>Patch 5. Juni, kein CVE, Forscher-These<\/td><\/tr>
ServiceNow (ACL-Konfiguration)<\/td>2025<\/td>Fehlkonfigurierte Zugriffskontrolllisten<\/td>Von Forschern als besonders schwerwiegend eingestuft<\/td><\/tr>
Snowflake (Kundeninstanzen)<\/td>2024<\/td>Angriffe \u00fcber gestohlene Zugangsdaten<\/td>Kein Plattform-Bruch, fehlende MFA bei Kunden<\/td><\/tr>
MOVEit Transfer<\/td>2023<\/td>SQL-Injection (CVE-2023-34362)<\/td>Massenhafte Ausnutzung durch Cl0p, tausende Organisationen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Der Vergleich ist lehrreich. Snowflake 2024 war kein Bruch der Plattform selbst, sondern die Folge fehlender Mehr-Faktor-Authentifizierung auf Kundenseite. MOVEit 2023 war eine ausnutzbare Injection-Schwachstelle, die eine Ransomware-Gruppe industriell skalierte. ServiceNow 2026 sitzt dazwischen: ein Anbieterfehler in der Konfiguration, der ohne Zutun des Kunden Daten exponierte. F\u00fcr Sicherheitsteams bedeutet das, dass weder reine Kundenh\u00e4rtung noch reines Patch-Management ausreicht. Beide Seiten der geteilten Verantwortung (Shared Responsibility) m\u00fcssen greifen.<\/p>\n\n\n\n

Historischer Kontext: Vom Plattform-Bruch zur Konfigurationsl\u00fccke<\/h2>\n\n\n\n

Die Angriffsfl\u00e4che der Unternehmens-IT hat sich in den vergangenen Jahren deutlich verschoben. Vor zehn Jahren standen Server, Perimeter-Firewalls und lokale Anwendungen im Zentrum. Heute liegen die Kronjuwelen in SaaS-Mandanten, die \u00fcber APIs miteinander und mit dem Internet sprechen. Mit dieser Verlagerung wandert auch das Risiko: weg von der klassischen Software-Schwachstelle, hin zur Identit\u00e4ts- und Konfigurationsebene.<\/p>\n\n\n\n

Aaron Costello, Leiter der SaaS-Sicherheitsforschung bei AppOmni, hatte eine verwandte ServiceNow-Schwachstelle aus dem Oktober 2025 als “die bislang schwerwiegendste KI-getriebene Sicherheitsl\u00fccke” bezeichnet. Diese Einordnung zeigt, dass ServiceNow nicht zum ersten Mal \u00fcber seine Zugriffs- und Konfigurationsschicht in die Schlagzeilen ger\u00e4t. Das Muster ist konsistent: Eine extrem flexible, stark anpassbare Plattform schafft viele Wege, Sicherheitsgrenzen versehentlich zu \u00f6ffnen.<\/p>\n\n\n\n

Die OWASP API Security Top 10 benennen genau diese Klassen seit Jahren als Kernrisiko: kaputte Objekt- und Funktionsebenen-Autorisierung sowie fehlende Authentifizierung an Schnittstellen. Der ServiceNow-Fall ist insofern kein Ausrei\u00dfer, sondern ein Lehrbuchbeispiel f\u00fcr ein bekanntes, ungel\u00f6stes Strukturproblem. Wer die Grundlagen sicherer \u00dcbertragung vertiefen will, findet sie in unserem Beitrag zu HTTPS und TLS<\/a>.<\/p>\n\n\n\n

Bedeutung f\u00fcr Deutschland und den DACH-Raum<\/h2>\n\n\n\n

ServiceNow ist in der DACH-Region tief in Konzernen, Versicherern, Banken und \u00f6ffentlichen Stellen verankert. Das macht den Vorfall f\u00fcr deutsche, \u00f6sterreichische und schweizerische Sicherheitsverantwortliche unmittelbar relevant. Anders als bei vielen US-zentrierten L\u00fccken betrifft diese eine Plattform, die hier produktiv gesch\u00e4ftskritische Prozesse tr\u00e4gt. Eine offene Schnittstelle ist damit kein abstraktes Risiko, sondern eine konkrete Frage der Meldepflicht.<\/p>\n\n\n\n

Rechtlich greift im DACH-Raum ein dichtes Regelwerk. Die DSGVO verlangt bei einem Datenschutzvorfall mit Risiko f\u00fcr Betroffene eine Meldung an die Aufsichtsbeh\u00f6rde binnen 72 Stunden. F\u00fcr Betreiber kritischer Infrastrukturen kommen die Vorgaben aus der NIS2-Umsetzung hinzu. Das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) sowie die Pendants in \u00d6sterreich und der Schweiz erwarten von Betreibern eine aktive Lage\u00fcberwachung. Wer eine betroffene ServiceNow-Instanz f\u00e4hrt, sollte den Vorfall dokumentieren, die Logs gegen den IOC 51.159.98.241<\/code> pr\u00fcfen und eine Meldeentscheidung sauber begr\u00fcnden.<\/p>\n\n\n\n

Der breitere Trend untermauert die Dringlichkeit. Die Bedrohungslage im DACH-Raum hat sich zuletzt deutlich versch\u00e4rft, wie unsere Analyse zu Cyberangriffen in Deutschland mit plus 124 Prozent<\/a> und der aktuelle BSI-Lagebericht<\/a> zeigen. Eine offene API bei einem Plattformanbieter trifft auf ein Umfeld, in dem Angreifer ohnehin auf Hochtouren laufen.<\/p>\n\n\n\n

Stimmen aus der Sicherheitsbranche<\/h2>\n\n\n\n

Die fachliche Bewertung des Vorfalls f\u00e4llt n\u00fcchtern aus. ServiceNow-Sprecherin Courtney Johnson betont die Forscher-These und das Ausbleiben eines Datenmissbrauchs. Sicherheitsforscher von Grip Security ordnen den eigentlichen Kern dagegen als Konfigurationsproblem ein und fassen es in einem Satz zusammen, der die ganze Schwierigkeit beschreibt.<\/p>\n\n\n\n

“Fehlkonfigurationen sind oft schwer zu erkennen, weil sie nicht wie eine klassische Schwachstelle aussehen.”<\/p>Analyse von Grip Security zum ServiceNow-Vorfall<\/cite><\/blockquote>\n\n\n\n

Diese Sicht deckt sich mit der historischen Einordnung von Aaron Costello (AppOmni), der ServiceNows Zugriffsschicht bereits 2025 als wiederkehrenden Schwachpunkt markiert hatte. Die Branche zieht daraus eine klare Konsequenz: API-Endpunkte und ihre Authentifizierungseinstellungen geh\u00f6ren kontinuierlich \u00fcberwacht, nicht nur bei Releases gepr\u00fcft. Statische Audits einmal im Quartal reichen nicht, wenn ein einziges Flag den Unterschied zwischen gesch\u00fctzt und offen ausmacht.<\/p>\n\n\n\n

Auff\u00e4llig ist auch, was nicht gesagt wird. Keine der bislang ver\u00f6ffentlichten Stellungnahmen nennt eine konkrete Zahl betroffener Mandanten. Diese Zur\u00fcckhaltung ist branchentypisch, erschwert aber die unabh\u00e4ngige Risikobewertung. Solange ServiceNow keine belastbaren Zahlen liefert, bleibt die externe Einsch\u00e4tzung notgedrungen vorsichtig und st\u00fctzt sich auf die bekannten technischen Eckdaten.<\/p>\n\n\n\n

F\u00fcnf Prognosen: Wie es mit SaaS- und API-Sicherheit weitergeht<\/h2>\n\n\n\n

Aus dem Vorfall und der aktuellen Marktlage lassen sich f\u00fcnf belastbare Erwartungen f\u00fcr die kommenden Monate ableiten.<\/p>\n\n\n\n