Am 10. Juni 2026 bestätigte 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änden weiter reichenden Zugriff auf gehostete ServiceNow-Instanzen zu erhalten, als vorgesehen war. Das ServiceNow Datenleck trifft eine Plattform, die in Konzernen, Behörden und kritischen Infrastrukturen im DACH-Raum als zentrales System für IT-Service-Management, Workflows und Asset-Verwaltung läuft. Brisant ist nicht nur die Lücke selbst, sondern die Chronologie: Zwischen der ersten vertraulichen Meldung und dem Patch lagen 44 Tage.

Dieser Beitrag ordnet den Vorfall faktenbasiert ein. Wir rekonstruieren die Zeitleiste, erklären die technische Schwachstelle am Endpunkt /api/now/related_list_edit/create, bewerten ServiceNows Kommunikation, vergleichen den Fall mit früheren SaaS-Vorfällen und ziehen fünf Prognosen für die API-Sicherheit. Alle Zahlen und Zitate stammen aus den offiziellen Stellungnahmen von ServiceNow und der Berichterstattung etablierter Sicherheitsmedien.

Was beim ServiceNow Datenleck geschah: Der Vorfall im Überblick

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änden erlauben konnte, weiter reichenden Zugriff auf ServiceNow-Instanzen zu erhalten, als beabsichtigt war”. Das Update änderte die Konfiguration eines REST-Endpunkts so, dass Anfragen nun zwingend eine Authentifizierung erfordern.

Die verdächtige Aktivität begann nach Rekonstruktion der Sicherheitsmedien um den 2. Juni 2026. Bereits am 3. und 4. Juni reichten Kunden über Bug-Bounty-Programme Hinweise auf das Problem ein. ServiceNow bestätigte, dass Angreifer bei einer Teilmenge der Kunden erfolgreich sogenannte Instanztabellen abfragen konnten. Welche Datensätze konkret eingesehen wurden, legte das Unternehmen nicht offen. Eine öffentliche Mitteilung folgte am 9. Juni, das aktualisierte Advisory am 10. Juni 2026.

ServiceNow ist kein Randanbieter. Die Plattform betreibt Service-Desks, Genehmigungs-Workflows, Konfigurationsdatenbanken (CMDB) und HR-Prozesse bei einem Großteil der weltweit größten Unternehmen sowie bei zahlreichen öffentlichen Stellen. Genau deshalb wiegt eine unauthentifizierte Lücke schwer: Eine einzige offene Schnittstelle multipliziert sich über tausende Mandanten hinweg. Das ServiceNow Datenleck ist damit weniger ein klassischer Einbruch als ein Konfigurationsfehler mit Plattform-Reichweite.

Die technische Schwachstelle: Ein API-Endpunkt ohne Authentifizierung

Im Kern steht eine API-Fehlkonfiguration, keine ausgefeilte Exploit-Kette. Der betroffene REST-Endpunkt /api/now/related_list_edit/create war so eingestellt, dass das Flag requires_authentication auf false stand. Übersetzt heißt das: Der Endpunkt akzeptierte Anfragen, ohne ein gültiges 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.

Wie der Endpunkt missbraucht werden konnte

Der Endpunkt gehört zum Mechanismus, über den ServiceNow verknüpfte Listen (related lists) bearbeitet. Steht die Authentifizierung auf false, lässt sich die zugrundeliegende Logik nutzen, um Datensätze aus Instanztabellen zu lesen, ohne die normalen Zugriffskontrolllisten (ACLs) zu durchlaufen. Genau diese ACL-Schicht ist das Sicherheitsfundament jeder ServiceNow-Instanz. Wird sie über einen offenen Endpunkt umgangen, greift der Schutz nicht mehr. Das Sicherheitsupdate vom 5. Juni setzte requires_authentication auf true und schloss die Lücke.

Die beobachtete IP-Adresse 51.159.98.241

Mehrere Sicherheitsanalysen nennen die IP-Adresse 51.159.98.241 als Quelle der verdächtigen Anfragen an den verwundbaren Endpunkt. Für 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 oder Zugriffe von dieser IP findet, sollte den Zeitraum Anfang Juni 2026 forensisch prüfen. Fehlkonfigurationen wie diese fallen im Alltag selten auf, weil sie nicht wie eine klassische Schwachstelle aussehen, sondern wie eine reguläre Einstellung.

Zeitleiste: 44 Tage zwischen Meldung und Patch

Der heikelste Aspekt der ServiceNow Sicherheitslücke ist die Reaktionszeit. Eine vertrauliche Bug-Bounty-Meldung, die ein sehr ähnliches Problem beschrieb, ging laut Unternehmen bereits am 22. April 2026 ein. Gepatcht wurde erst am 5. Juni, rund 44 Tage später. In Foren berichten Kunden zudem, das Unternehmen habe bereits ab dem 7. April von Auffälligkeiten gewusst. Die folgende Tabelle fasst die belegten Eckdaten zusammen.

DatumEreignis
22. April 2026Vertrauliche Bug-Bounty-Meldung zu einer sehr ähnlichen Schwachstelle geht bei ServiceNow ein
2. Juni 2026Beginn der beobachteten Abfrageaktivität gegen Kundeninstanzen
3. bis 4. Juni 2026Kunden melden das Problem über Bug-Bounty-Programme
5. Juni 2026ServiceNow spielt Sicherheitsupdate auf gehostete Instanzen ein (requires_authentication = true)
9. Juni 2026Erste öffentliche Berichterstattung über den Vorfall
10. Juni 2026ServiceNow aktualisiert das offizielle Advisory
Stand 12. Juni 2026Kein CVE vergeben, Umfang der eingesehenen Daten weiterhin nicht beziffert

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.

Welche Daten betroffen waren und wer gefährdet ist

ServiceNow nannte keine konkreten Datenkategorien, die abgeflossen sein könnten. 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ür betroffene Unternehmen schwierig.

In ServiceNow-Instanzen liegen üblicherweise hochsensible Geschäftsdaten. Dazu zählen IT-Support-Tickets, Mitarbeiterdatensätze, interne Dokumentation, Asset-Inventare, gemeldete Sicherheitsvorfälle, 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.

Betroffen sind laut ServiceNow Kunden, die sich auf dem Plattform-Release “Australia” befinden, sowie Kunden, die auf früheren Releases bestimmte Konfigurationsänderungen 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ängig vom Release prüfen. Mehr Hintergrund zur Mechanik solcher Vorfälle bietet unser Grundlagenartikel zu Datenlecks und ihrer Entstehung.

ServiceNows Reaktion: “Sicherheitsforscher, keine Angreifer”

ServiceNow ordnet den Vorfall auffällig zurückhaltend ein. Das Unternehmen erklärt, die beobachtete Aktivität sei nach aktuellem Ermittlungsstand Sicherheitsforschern und kundeneigenen Forschungsteams zuzuschreiben, nicht böswilligen Akteuren. Gegenüber TechCrunch präzisierte ServiceNow-Sprecherin Courtney Johnson diese Einschätzung.

“Neben unserer eigenen Untersuchung standen wir in Kontakt mit den Sicherheitsforschern, die das Problem ursprünglich gemeldet haben, und können bestätigen, dass die Hinweise auf die beobachtete Aktivität von diesen Forschern und Kundenforschungsteams stammen, nicht von böswilligen Akteuren.”

Courtney Johnson, Sprecherin von ServiceNow, gegenüber TechCrunch

Johnson ergänzte: “Die Sicherheitsforscher haben mitgeteilt, dass ihre Aktivität ausschließlich 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ützt sich allerdings auf die Selbstauskunft der Forscher, nicht auf einen vollständig forensisch belegten Nachweis gegenüber der Öffentlichkeit.

Kritik an der Transparenz: Warum Kunden im Dunkeln blieben

Mehrere Fachmedien kritisieren, dass ServiceNow zu wenig über den tatsächlichen Hergang preisgibt. Das Unternehmen benannte weder die Zahl der betroffenen Kunden noch die Kategorien der eingesehenen Daten. Das Advisory war zudem zunächst nur eingeloggt im Kundenportal abrufbar, was die Verbreitung der Warnung verlangsamte. Für Sicherheitsverantwortliche, die schnell entscheiden müssen, ob sie eine Meldung an Aufsichtsbehörden auslösen, ist diese Informationslage problematisch.

Die Spannung ist offensichtlich. Einerseits beschreibt ServiceNow den Vorfall als harmlose Forschungsaktivität ohne Datenmissbrauch. Andererseits räumt das Unternehmen ein, dass bei einer Teilmenge der Kunden Instanztabellen erfolgreich abgefragt wurden. Beide Aussagen lassen sich vereinbaren, doch ohne Zahlen bleibt für 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ären.

Kein CVE, viel Verwirrung: Das Problem mit der Einordnung

Bis zum 12. Juni 2026 hat ServiceNow der Schwachstelle keine CVE-Nummer zugewiesen. Das Unternehmen erklärte, man prüfe noch, ob eine CVE vergeben werde. Das klingt nach einer Formalie, hat aber praktische Folgen. CVE-Einträge sind die gemeinsame Sprache der Sicherheitsbranche. Ohne CVE taucht eine Lücke nicht automatisch in Schwachstellen-Scannern, Threat-Intelligence-Feeds oder den Pflichtkatalogen wie der CISA-KEV-Liste auf.

Für SaaS-Plattformen ist das ein Sonderfall. Klassische CVEs adressieren Software, die Kunden selbst installieren und patchen. Bei einer vom Anbieter gehosteten Lücke patcht der Anbieter zentral, und der Kunde erfährt es im besten Fall über ein Advisory. Das verschiebt Verantwortung und Sichtbarkeit. Wenn kein CVE existiert und das Advisory hinter einem Login liegt, wird ein realer Vorfall für externe Beobachter nahezu unsichtbar. Diese strukturelle Lücke in der SaaS-Sicherheit zeigt der ServiceNow-Fall exemplarisch.

Marktauswirkungen: Was der Vorfall für SaaS-Sicherheit bedeutet

Der wirtschaftliche Kern des Vorfalls liegt nicht in einer Lösegeldforderung, sondern im Vertrauensmodell der SaaS-Branche. Unternehmen lagern geschäftskritische 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 über 44 Tage offen blieb, kratzt genau an dieser Annahme.

Der Global Cybersecurity Outlook 2026 des World Economic Forum verweist darauf, dass Cyber-Betrug und Phishing 2026 die höchste Priorität für Sicherheitsverantwortliche bilden, gefolgt von Risiken durch KI-Schwachstellen. SaaS-Fehlkonfigurationen passen in dieses Bild: Sie sind günstig auszunutzen, schwer zu entdecken und skalieren über 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üfen.

Für ServiceNow selbst ist der Reputationsschaden begrenzt, solange die Forscher-These hält und kein böswilliger Datenabfluss nachgewiesen wird. Sollte sich das Bild drehen, etwa durch Belege für eine breitere Ausnutzung, verschiebt sich die Diskussion schnell von einem Konfigurationsfehler zu einem grundsätzlichen Governance-Problem. Parallelen zu anderen kritischen Schwachstellen wie der Citrix-NetScaler-Lücke liegen nahe, auch wenn die technische Natur eine andere ist.

ServiceNow im Vergleich: API-Lücken bei anderen SaaS-Plattformen

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ällen. Sie zeigt ein wiederkehrendes Muster: Nicht der raffinierte Exploit dominiert, sondern offene Schnittstellen, kompromittierte Zugangsdaten und Fehlkonfigurationen.

Vorfall / PlattformZeitraumSchwachstellentypEinordnung
ServiceNow (API-Endpunkt)Juni 2026Unauthentifizierter REST-EndpunktPatch 5. Juni, kein CVE, Forscher-These
ServiceNow (ACL-Konfiguration)2025Fehlkonfigurierte ZugriffskontrolllistenVon Forschern als besonders schwerwiegend eingestuft
Snowflake (Kundeninstanzen)2024Angriffe über gestohlene ZugangsdatenKein Plattform-Bruch, fehlende MFA bei Kunden
MOVEit Transfer2023SQL-Injection (CVE-2023-34362)Massenhafte Ausnutzung durch Cl0p, tausende Organisationen

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ür Sicherheitsteams bedeutet das, dass weder reine Kundenhärtung noch reines Patch-Management ausreicht. Beide Seiten der geteilten Verantwortung (Shared Responsibility) müssen greifen.

Historischer Kontext: Vom Plattform-Bruch zur Konfigurationslücke

Die Angriffsfläche 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 über APIs miteinander und mit dem Internet sprechen. Mit dieser Verlagerung wandert auch das Risiko: weg von der klassischen Software-Schwachstelle, hin zur Identitäts- und Konfigurationsebene.

Aaron Costello, Leiter der SaaS-Sicherheitsforschung bei AppOmni, hatte eine verwandte ServiceNow-Schwachstelle aus dem Oktober 2025 als “die bislang schwerwiegendste KI-getriebene Sicherheitslücke” bezeichnet. Diese Einordnung zeigt, dass ServiceNow nicht zum ersten Mal über seine Zugriffs- und Konfigurationsschicht in die Schlagzeilen gerät. Das Muster ist konsistent: Eine extrem flexible, stark anpassbare Plattform schafft viele Wege, Sicherheitsgrenzen versehentlich zu öffnen.

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ßer, sondern ein Lehrbuchbeispiel für ein bekanntes, ungelöstes Strukturproblem. Wer die Grundlagen sicherer Übertragung vertiefen will, findet sie in unserem Beitrag zu HTTPS und TLS.

Bedeutung für Deutschland und den DACH-Raum

ServiceNow ist in der DACH-Region tief in Konzernen, Versicherern, Banken und öffentlichen Stellen verankert. Das macht den Vorfall für deutsche, österreichische und schweizerische Sicherheitsverantwortliche unmittelbar relevant. Anders als bei vielen US-zentrierten Lücken betrifft diese eine Plattform, die hier produktiv geschäftskritische Prozesse trägt. Eine offene Schnittstelle ist damit kein abstraktes Risiko, sondern eine konkrete Frage der Meldepflicht.

Rechtlich greift im DACH-Raum ein dichtes Regelwerk. Die DSGVO verlangt bei einem Datenschutzvorfall mit Risiko für Betroffene eine Meldung an die Aufsichtsbehörde binnen 72 Stunden. Für Betreiber kritischer Infrastrukturen kommen die Vorgaben aus der NIS2-Umsetzung hinzu. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) sowie die Pendants in Österreich und der Schweiz erwarten von Betreibern eine aktive Lageüberwachung. Wer eine betroffene ServiceNow-Instanz fährt, sollte den Vorfall dokumentieren, die Logs gegen den IOC 51.159.98.241 prüfen und eine Meldeentscheidung sauber begründen.

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

Stimmen aus der Sicherheitsbranche

Die fachliche Bewertung des Vorfalls fällt nüchtern 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.

“Fehlkonfigurationen sind oft schwer zu erkennen, weil sie nicht wie eine klassische Schwachstelle aussehen.”

Analyse von Grip Security zum ServiceNow-Vorfall

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ören kontinuierlich überwacht, nicht nur bei Releases geprüft. Statische Audits einmal im Quartal reichen nicht, wenn ein einziges Flag den Unterschied zwischen geschützt und offen ausmacht.

Auffällig ist auch, was nicht gesagt wird. Keine der bislang veröffentlichten Stellungnahmen nennt eine konkrete Zahl betroffener Mandanten. Diese Zurückhaltung ist branchentypisch, erschwert aber die unabhängige Risikobewertung. Solange ServiceNow keine belastbaren Zahlen liefert, bleibt die externe Einschätzung notgedrungen vorsichtig und stützt sich auf die bekannten technischen Eckdaten.

Fünf Prognosen: Wie es mit SaaS- und API-Sicherheit weitergeht

Aus dem Vorfall und der aktuellen Marktlage lassen sich fünf belastbare Erwartungen für die kommenden Monate ableiten.

  • CVE-Pflicht für SaaS rückt näher. Der Streit um die fehlende CVE wird den Druck erhöhen, auch anbietergehostete Lücken konsequent zu katalogisieren. Initiativen für SaaS-spezifische Schwachstellenkennungen gewinnen an Zugkraft.
  • SSPM wird zum Standard. SaaS Security Posture Management wandert von der Kür zur Pflicht. Unternehmen werden Konfigurations-Monitoring für ihre kritischen Plattformen als Grundausstattung budgetieren.
  • Transparenzdruck steigt. Eingeloggte Advisories ohne Zahlen werden zunehmend kritisiert. Regulatoren im DACH-Raum dürften klarere Offenlegungsfristen für SaaS-Anbieter einfordern.
  • API-Authentifizierung wird zur Audit-Priorität. Das Flag requires_authentication steht stellvertretend für tausende Einstellungen. Automatisierte Prüfungen gegen offene Endpunkte werden Pflichtbestandteil von Pentests.
  • Geteilte Verantwortung wird neu verhandelt. Kunden werden vertraglich schärfere Zusagen zu Konfigurationssicherheit und Meldefristen verlangen, statt sich allein auf das Vertrauensmodell zu verlassen.

Was betroffene Unternehmen jetzt tun sollten

Für Organisationen mit ServiceNow-Instanz ist die Lage handhabbar, wenn sie strukturiert vorgehen. Die folgenden Schritte fassen die Empfehlungen aus den vorliegenden Sicherheitsanalysen zusammen und lassen sich kurzfristig umsetzen.

  • Sicherstellen, dass das Sicherheitsupdate vom 5. Juni 2026 aktiv ist und requires_authentication für den betroffenen Endpunkt auf true steht.
  • API-Logs auf Anfragen an /api/now/related_list_edit/create durchsuchen, insbesondere für den Zeitraum ab dem 2. Juni 2026.
  • Die Logs gezielt nach Aktivität von der IP-Adresse 51.159.98.241 filtern.
  • Prüfen, ob in der Vergangenheit unautorisierte Datenabfragen stattgefunden haben, und Funde forensisch sichern.
  • Eine Meldeentscheidung nach DSGVO Artikel 33 dokumentiert treffen und im Zweifel den Datenschutzbeauftragten einbinden.
  • SaaS Security Posture Management einführen oder erweitern, um Konfigurationen künftig kontinuierlich zu überwachen.

Wer die Authentifizierungsgrundlagen für eigene Dienste härten will, findet praxisnahe Hinweise in unserem Beitrag zur Passwortsicherheit mit Hashing und Zwei-Faktor-Authentifizierung.

Häufig gestellte Fragen zum ServiceNow Datenleck

Was genau ist beim ServiceNow Datenleck passiert?

Ein REST-API-Endpunkt (/api/now/related_list_edit/create) war so konfiguriert, dass er keine Authentifizierung verlangte. Dadurch konnten nicht angemeldete Nutzer unter bestimmten Umständen Daten aus Kundeninstanzen abfragen. ServiceNow schloss die Lücke am 5. Juni 2026 mit einem Konfigurations-Update.

Wurden tatsächlich Kundendaten gestohlen?

ServiceNow bestätigt, dass bei einer Teilmenge der Kunden Instanztabellen erfolgreich abgefragt wurden. Das Unternehmen schreibt die Aktivität jedoch Sicherheitsforschern zu und erklärt, es seien keine Daten genutzt oder gespeichert worden. Konkrete Zahlen zu betroffenen Kunden oder Datensätzen nannte ServiceNow nicht.

Gibt es eine CVE-Nummer für die Schwachstelle?

Bis zum 12. Juni 2026 wurde keine CVE-Nummer vergeben. ServiceNow erklärte, man prüfe noch, ob eine CVE zugewiesen werde. Das erschwert die automatisierte Erfassung der Lücke in Schwachstellen-Scannern und Threat-Feeds.

Welche ServiceNow-Kunden sind betroffen?

Laut ServiceNow betrifft das Problem Kunden auf dem Plattform-Release “Australia” sowie Kunden, die auf früheren Releases bestimmte Konfigurationsänderungen vorgenommen hatten. Wer eine stark angepasste Instanz betreibt, sollte die eigene Konfiguration unabhängig vom Release prüfen.

Was sollten betroffene Unternehmen im DACH-Raum jetzt tun?

Den Patch-Status prüfen, die API-Logs gegen den Endpunkt und die IP 51.159.98.241 durchsuchen, mögliche Datenabfragen forensisch sichern und eine dokumentierte Meldeentscheidung nach DSGVO Artikel 33 treffen. Bei Unsicherheit sollte der Datenschutzbeauftragte eingebunden werden.

Wie unterscheidet sich dieser Vorfall von einem klassischen Hack?

Es handelt sich nicht um einen ausgefeilten Einbruch mit Malware, sondern um eine Fehlkonfiguration. Ein einzelnes Flag stand auf “keine Authentifizierung erforderlich”. Solche Konfigurationsfehler sind besonders tückisch, weil sie wie reguläre Einstellungen aussehen und von herkömmlichen Schwachstellen-Scannern oft nicht erkannt werden.

Kann sich ein solcher Vorfall wiederholen?

Ja. Die OWASP API Security Top 10 listen fehlende Authentifizierung und kaputte Autorisierung seit Jahren als Kernrisiken. Solange komplexe SaaS-Plattformen viele Konfigurationsoptionen bieten, bleibt das Risiko bestehen. Kontinuierliches Konfigurations-Monitoring (SSPM) ist die wirksamste Gegenmaßnahme.

Fazit: Ein Konfigurationsfehler mit Plattform-Reichweite

Das ServiceNow Datenleck vom Juni 2026 ist kein spektakulärer Hack, sondern eine nüchterne Lehrstunde in API-Sicherheit. Ein einziges falsch gesetztes Flag öffnete einen Endpunkt für 44 Tage, und die fehlende CVE sowie das eingeloggte Advisory erschwerten die Sichtbarkeit zusätzlich. Die Forscher-These von ServiceNow entlastet das Unternehmen, ersetzt aber keine belastbaren Zahlen. Für Sicherheitsverantwortliche im DACH-Raum bleibt die Botschaft eindeutig: Konfigurationssicherheit auf SaaS-Plattformen ist kein Anhängsel, sondern Kernaufgabe. Wer Logs prüft, Patches verifiziert und Meldepflichten sauber bewertet, übersteht diesen Vorfall ohne Schaden. Wer wegsieht, verlässt sich auf die Selbstauskunft anonymer Forscher.