Was passiert ist
Am 20. Juli 2026 wurde eine kritische Schwachstelle in der ServiceNow AI Platform öffentlich breit diskutiert: CVE-2026-6875. Nach der aktuellen Berichterstattung von BleepingComputer haben Angreifer begonnen, die Lücke in echten Angriffen auszunutzen. Besonders relevant ist dabei nicht nur der Schweregrad, sondern die Art des Fehlers: Es handelt sich um eine vor-authentifizierte Remote-Code-Execution-Schwachstelle, die einen Sandbox-Ausbruch ermöglichen kann.
ServiceNow ist für viele Organisationen kein Randprodukt, sondern ein zentraler Teil der operativen Kette. In der Plattform laufen Tickets, Änderungen, Freigaben, Integrationen und oft auch Automatisierungen zusammen. Wenn dort Code ausgeführt werden kann, ist das nicht einfach ein technischer Bug, sondern potenziell ein Weg in den Kern der betrieblichen Abläufe.
Nach den öffentlich verfügbaren Informationen hatte Searchlight Cyber die Schwachstelle bereits am 1. April 2026 gemeldet. ServiceNow hat für gehostete Instanzen nach eigenen Angaben bereits im April Gegenmaßnahmen ausgerollt. Für selbst gehostete Instanzen wurden Patches beziehungsweise Updates am 13. Juli nachgereicht. Entscheidend für Betreiber ist daher nicht nur die Frage, ob die Schwachstelle existiert, sondern welche Betriebsform betroffen ist und ob die eigenen Systeme den Stand vom 13. Juli erreicht haben.
Warum die Meldung operativ ernst ist
Der eigentliche Risikofaktor ist die Kombination aus drei Dingen: erstens keine Anmeldung vor dem Angriff, zweitens Codeausführung mit hoher Wirkung und drittens eine Plattform, die typischerweise eng mit Identitäten, Workflows und internen Integrationen verbunden ist. Ein Angreifer, der in einer solchen Umgebung Fuß fasst, kann nicht nur Daten abziehen, sondern auch Automatisierungen manipulieren, Regeln verändern, Integrationskonten missbrauchen oder Folgezugriffe vorbereiten.
Für Sicherheits- und Betriebsteams ist das deshalb ein anderer Typ Vorfall als ein isolierter Client-Bug. ServiceNow hängt oft an SSO, an API-Zugängen zu Drittsystemen, an Benachrichtigungen, an CMDB-Daten und an Workflows, die auf Incident-, Change- oder Problem-Daten reagieren. Wer dort Kontrolle gewinnt, berührt nicht nur eine Anwendung, sondern die Verbindungsstellen zwischen Teams und Systemen.
Der kritische Punkt ist nicht die Schwachstelle allein, sondern der mögliche Zugriff auf eine Plattform, die in vielen Unternehmen selbst ein Steuerungszentrum des Betriebs ist.
Die aktuelle Lage zeigt auch, wie kurz das Zeitfenster zwischen Disclosure und Aktivität im Feld sein kann. Am Anfang steht eine Sicherheitsmeldung, kurz danach folgen reale Exploit-Versuche. Für Betreiber ist das ein gutes Beispiel dafür, warum Patch-Programme heute nicht mehr nur auf monatliche Routinen setzen dürfen, wenn eine Plattform bereits vorab als kritisch eingestuft wurde.
Was ServiceNow-Betreiber jetzt konkret prüfen sollten
Zuerst muss sauber geklärt sein, ob eine Organisation überhaupt selbst gehostete Instanzen betreibt oder ausschließlich ServiceNow-Hosting nutzt. Diese Unterscheidung ist wichtig, weil sie die Verantwortung für das Patchen und die Geschwindigkeit der Reaktion verschiebt. Wer selbst hostet, sollte den Stand der Juli-Fixes sofort verifizieren und nicht nur auf eine generelle Freigabe oder eine vage Änderungsmitteilung vertrauen.
In der Praxis sollten Betreiber einen schnellen, aber geordneten Prüfpfad abarbeiten: Patch-Stand bestätigen, Änderungsfenster dokumentieren, relevante Logquellen sichern und ein kurzes Lagebild an Security, Betrieb und Fachbereiche verteilen. Gerade bei Plattformen mit vielen Integrationen ist es sinnvoll, den technischen Check nicht isoliert zu betrachten. Oft hängt an einem einzigen ServiceNow-Konto mehr als nur ein Benutzerlogin, etwa Freigabeautomaten, Ticket-Routing, Webhooks oder Schnittstellen zu Identitäts-, Monitoring- und Messaging-Systemen.
- Prüfen, welche ServiceNow-Instanzen intern betrieben werden und welche extern gehostet sind.
- Den Patch-Stand vom 13. Juli 2026 eindeutig nachweisen.
- Logdaten auf ungewöhnliche Anfragen, Fehlermuster und verdächtige Zugriffe rund um die betroffene Angriffskette untersuchen.
- Service- und Integrationskonten auf untypische Aktivitäten prüfen, insbesondere dort, wo ServiceNow mit anderen Plattformen verbunden ist.
- Verifizieren, ob Tokens, API-Schlüssel oder Automatisierungsaccounts von einem möglichen Vorfall berührt wurden.
- Bei Verdacht Incident-Response-Prozesse sofort aktivieren, statt auf eine zweite Bestätigung zu warten.
Besonders wichtig ist die Jagd nach Seiteneffekten. Selbst wenn der Primärzugriff noch nicht eindeutig belegt ist, können bereits fehlgeschlagene Exploit-Versuche Spuren in Logs, Fehlermeldungen oder ungewöhnlichen Systemzuständen hinterlassen. In einer ServiceNow-Umgebung sollte man deshalb nicht nur nach klassischer Malware suchen, sondern auch nach unplausiblen Änderungen an Workflows, Rollen, Webhooks und Integrationen.
Warum das für FreshCore-Leser relevant ist
Für ein Publikum aus IT, DevOps, Monitoring und Automatisierung ist diese Meldung deshalb interessant, weil sie den Kern vieler moderner Betriebsmodelle trifft. Plattformen wie ServiceNow sitzen zwischen Mensch und Maschine. Sie nehmen Meldungen auf, stoßen Prozesse an, koppeln Tools miteinander und sind oft die Stelle, an der aus einem Incident ein automatisierter Ablauf wird. Genau dort wird jede Schwachstelle besonders teuer.
Das ist auch ein guter Reminder für die eigene Architektur: Je mehr ein System zum zentralen Orchestrator wird, desto höher ist sein Wert für Angreifer und desto konsequenter müssen Härtung, Segmentierung, Protokollierung und Notfallpläne sein. Wer nur auf Uptime schaut, übersieht leicht den eigentlichen Zweck solcher Plattformen: Sie steuern Prozesse. Wenn sie kompromittiert werden, ist der Schaden nicht nur technisch, sondern organisatorisch.
Praktisch heißt das für Teams: Kritische SaaS- und Self-Hosted-Plattformen sollten wie produktive Infrastruktur behandelt werden, nicht wie reine Verwaltungssoftware. Dazu gehören klare Patch-Fenster, Asset-Transparenz, kontinuierliche Überwachung, gesonderte Administrationszugänge und eine belastbare Antwort auf die Frage, was im Fall eines Plattformvorfalls priorisiert abgeschaltet oder entkoppelt werden muss. Gerade im Umfeld von Automatisierungen lohnt sich außerdem ein Blick auf die Reichweite einzelner API-Schlüssel: Ein kompromittierter Workflow-Account kann deutlich mehr Schaden anrichten als ein einzelnes Benutzerkonto.
Einordnung statt Alarmismus
Wichtig ist allerdings auch eine saubere Einordnung. Nicht jede veröffentlichte Schwachstelle bedeutet automatisch einen großflächigen Ausbruch. ServiceNow hat nach den öffentlich verfügbaren Aussagen betont, dass die beobachtete Aktivität nicht zwangsläufig die von ihr gehosteten Instanzen betrifft. Das ist für viele Kunden eine Entlastung, aber kein Freifahrtschein. Wer selbst betreibt oder wer stark integrierte Abläufe auf ServiceNow aufsetzt, muss die Lage trotzdem als akut betrachten.
Die richtige Reaktion ist deshalb nicht Hype, sondern Disziplin: Systemstand bestätigen, Logs prüfen, Integrationen absichern, Incident-Prozess bereithalten und betroffene Teams informieren. Genau so werden aus kritischen Lücken keine größeren Vorfälle. Wer solche Plattformen sauber betreibt, kann den Druck aus einem solchen Ereignis nehmen, bevor er zum echten Betriebsproblem wird.
Bildquelle: BleepingComputer / ServiceNow.
Quellen
- BleepingComputer: Critical ServiceNow code execution flaw now exploited in attacks, 20. Juli 2026.
- ServiceNow Support Advisory zu CVE-2026-6875.
- Tenable CVE-2026-6875 Referenz mit Verweisen auf die betroffene Plattform und die Sicherheitsmeldungen.
