Der Gastzugang öffentlicher Firmenportale reicht aus, um 17 Monate lang mitzulesen. Ein einzelner Server bei einem deutschen Hoster fragte die Salesforce- und ServiceNow-Seiten von Banken, Telekom-Anbietern, Softwareanbietern und Behörden ab; bei einem Ziel zählte der Sicherheitsanbieter Reco über 560.000 Abrufe. Eine Sicherheitslücke nutzte der Angreifer dabei nicht.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Am 12. März 2025 tauchte die Adresse 158.220.87.79 in den Passiv-DNS-Daten auf und fragt seither denselben Gastzugang ab, den jede öffentliche Salesforce-Community standardmäßig mitbringt.[1] Reco nennt die Kampagne City-Forum, nach der Domain hinter der Adresse.
Das Wichtigste in Kürze
- Seit dem 12. März 2025 fragt eine einzige IP-Adresse öffentliche Salesforce- und ServiceNow-Portale von Banken, Behörden und Softwareanbietern ab.
- Der Angreifer nutzt keine Sicherheitslücke, sondern die Rechte, die der Gastzugang ohnehin vergibt.
- Die Protokolle beider Plattformen verraten nicht, welche Datensätze dabei zurückflossen.
- Ein unbefugter Zugang zu personenbezogenen Daten ist eine Datenpanne nach Artikel 4 Nummer 12 DSGVO.
Wie kommt ein Fremder ohne Passwort an Kundendaten?
Jede öffentliche Salesforce-Community bringt einen eigenen Gastbenutzer mit, der ohne Anmeldung genau das liest, was Freigaberegeln und Objektrechte ihm erlauben. Diese Rechte fragt der Betreiber von City-Forum ab, über die ältere Aura-Schnittstelle und über die neuere Lightning Web Runtime. Den Zugriff auf deren UI-API dokumentiert Reco zum ersten Mal aus einer laufenden Kampagne.[1]
Bei ServiceNow läuft dasselbe über die Suche des Service Portals: Fragt eine skriptbasierte Suchquelle dort mit dem klassischen GlideRecord statt mit GlideRecordSecure ab, liefert die Suche Einträge aus Wissensdatenbank und Katalog auch an Besucher ohne Konto. Elf API-Versionen von v56.0 bis v66.0 probierte das Werkzeug bei Salesforce durch, weil viele Organisationen den Gastzugriff nur in der aktuellen Version sperren. ShinyHunters missbrauchte im Juli OAuth-Token statt anonymer Rechte, kam aber ebenfalls ohne einen einzigen Bug aus.
Warum fiel der Abruf 17 Monate lang nicht auf?
Die Abrufe sahen in jedem Logfile wie normaler Besucherverkehr aus, weil sie technisch legitimer Verkehr waren. Salesforce Event Monitoring hält fest, dass eine Anfrage kam, nicht welche Datensätze zurückgingen; im Transaktionsprotokoll von ServiceNow fehlt der Suchbegriff.[1] Für eine Schadensbilanz muss ein betroffenes Unternehmen die Anfragen im eigenen Mandanten nachstellen und die Antworten auswerten.
Ein einziges Merkmal unterschied den Datenverkehr vom echten Besuch: der User-Agent Go-http-client/1.1, die Voreinstellung der Go-Standardbibliothek. Eine Blockliste hätte gereicht. Inzwischen tarnen sich Massenscanner allerdings als KI-Crawler und kämen auch daran vorbei.
Ein unbegrenzter Gastzugang löst keinen einzigen Alarm aus, weil jede Anfrage für sich regelkonform bleibt. Deutsche Mandanten sollten ihre Portalrechte deshalb im Quartalsrhythmus durchsehen, statt auf eine Warnung von Salesforce zu warten.
— Michael Dobler, Herausgeber Dr. Web
Ein Datenabfluss ohne Sicherheitslücke, dokumentiert vom Sicherheitsanbieter Reco am 12. August 2026
Der gesamte Datenverkehr kam von einer einzigen IP-Adresse bei einem deutschen Anbieter, ohne Wechsel und ohne Sperre durch die betroffenen Portale.
Was bedeutet der Fall für deutsche Unternehmen?
Ein unbefugter Zugang zu personenbezogenen Daten gilt nach Artikel 4 Nummer 12 DSGVO als Datenpanne, auch ohne Einbruch und ohne Sicherheitslücke. Zuständig bleibt der Mandant: Salesforce und ServiceNow verarbeiten im Auftrag, die Freigaberegeln setzt das Unternehmen selbst. Für die Meldung an die Aufsichtsbehörde bleiben nach Artikel 33 DSGVO 72 Stunden, für besonders wichtige und wichtige Einrichtungen nach § 32 BSIG in der seit Dezember 2025 geltenden Fassung nur 24.[3] Die Verantwortung dafür liegt bei der Geschäftsführung, nicht bei der IT-Abteilung.
Neu ist der Fehler nicht. AppOmni fand 2024 heraus, dass knapp 45 Prozent der untersuchten ServiceNow-Wissensdatenbanken vertrauliche Inhalte an nicht angemeldete Besucher ausliefern, darunter gültige Zugangsdaten zu produktiven Systemen.[2] Aus demselben Grund lagen zuletzt 181.874 Meeting-Mitschriften eines KI-Notiztools offen. Gegen dieses Muster hilft kein Patch, anders als bei den alten Fortinet-Lücken, die Gunra-Ransomware ausnutzt.
Zwei Prüfungen stehen jetzt an. In Salesforce gehören die Freigaberegeln des Gastbenutzers auf das nötige Minimum, und der Gastzugriff auf die öffentlichen APIs lässt sich in den Workspace-Einstellungen abschalten. In ServiceNow ersetzt GlideRecordSecure den klassischen GlideRecord in jeder skriptbasierten Suchquelle, und jedes Leserecht „Any User“ kommt auf den Prüfstand.
Quellen
[1] Reco: „The ‚City-Forum‘ Campaign“
[2] AppOmni: „Enterprise ServiceNow Knowledge Bases at Risk“
[3] Bundesamt für Justiz: „§ 32 BSIG, Meldepflichten“
Mehr Newshunger?
- Kein einziger Bug: Wie ShinyHunters ein Jahr lang Salesforce-Daten stahl
- Vier Tage nach dem Patch: Angreifer umgehen ServiceNows Sandbox über einen zweiten Weg
- KI-Notiztool tl;dv: 181.874 Meetings in einer ungeschützten Datenbank
- Atlassian Rovo: Eine versteckte Anweisung genügt für den Datenabfluss aus Jira
- Massenhafte Schwachstellen-Scans tarnen sich als KI-Bots wie ClaudeBot
- SAP Commerce Cloud: Eine 10.0-Lücke öffnet den Webshop für Angreifer
