ServiceNow has confirmed a security incident in which attackers exploited an unauthenticated API endpoint to query data from customer instances — and the company quietly notified affected customers behind a login wall rather than making a public announcement.
The issue, which ServiceNow disclosed through a support bulletin accessible only behind its customer login portal and through direct support cases, allowed unauthenticated users to access certain instance data they shouldn’t have been able to reach. The company applied a fix to hosted customer instances on June 5, 2026, but not before attackers got through.
What happened
According to the bulletin, the vulnerability allowed an unauthenticated user to, in certain circumstances, gain broader access to ServiceNow instances than intended. ServiceNow says it has confirmed that attackers exploited the flaw to query customer instance tables.
While the company hasn’t disclosed specifically which data was accessed, ServiceNow instances typically house a goldmine of sensitive enterprise information: IT support tickets, employee records, internal documentation, asset inventories, security incident reports, workflow data, and configuration details for corporate systems. And as multiple previous breaches have shown, support tickets in particular often contain credentials, API tokens, and authentication secrets shared during troubleshooting sessions.
Administrators discussing the incident on Reddit pointed to a REST endpoint at /api/now/related_list_edit/create as the likely entry point. One commenter claimed the endpoint was configured with requires_authentication=false, which would allow unauthenticated requests to access instance data. The June 5 fix reportedly changed that setting to true.
Several admins have shared indicators of compromise for fellow administrators to check against, including API requests originating from IP address 51.159.98.241.
Who’s affected
ServiceNow says the issue primarily impacts customers running the Australia platform release, as well as customers on older releases who made specific configuration changes. The company is contacting affected customers through direct support cases — if you haven’t received one, ServiceNow says you’re likely not impacted.
BleepingComputer reached out to ServiceNow asking how long the activity had been ongoing, what caused the issue, and whether customer data was stolen. The company didn’t respond before publication. It’s also still evaluating whether to publish a CVE.
What you should do right now
If you run ServiceNow, there are three things to check today. First, review your logs for any requests to the /api/now/related_list_edit endpoint, particularly from IP address 51.159.98.241. Second, audit any exposed tickets and records for sensitive information — and assume anything in those tickets could be compromised. Third, rotate any credentials, tokens, or secrets that were shared through support workflows on your instances. This is especially critical for any authentication material stored in ticket descriptions or attachments.
The bigger problem
This incident fits a pattern that should be deeply familiar by now: a configuration error on an API endpoint exposing data without authentication, exploited by attackers who found it first. What’s notable here is the quiet disclosure. ServiceNow chose to communicate through logged-in support bulletins and individual cases rather than a public advisory — a approach that limits visibility even for customers who might want to check whether they were affected.
It’s also a reminder that support platforms themselves are high-value targets. Ticketing systems concentrate exactly the kind of sensitive operational data that attackers want — credentials shared during debugging sessions, architecture discussions, internal process documentation. If you’re running a platform like ServiceNow, the security of those instances deserves the same scrutiny as your production infrastructure.
What’s next
Watch for whether ServiceNow publishes a CVE and more detailed technical findings. In the meantime, administrators should ensure API logging is fully enabled across all ServiceNow instances and treat any historical data in ticketing systems as potentially exposed until proven otherwise.
