ServiceNow Patches Unauthenticated API Flaw After Attackers Query Customer Instance Data

ServiceNow has confirmed that attackers exploited an unauthenticated access flaw in a vulnerable API endpoint, letting them query data directly from customer instances before the company shipped an emergency fix on June 5, 2026. Rather than a public advisory, ServiceNow notified affected organizations through a support bulletin hidden behind its customer login portal and by opening individual support cases after detecting what it described as "anomalous activity."

The wording in the bulletin is careful. "On June 5, 2026, ServiceNow applied a security update to hosted customer instances," it reads. "The update concerned a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended." Translated out of vendor-speak: someone who never logged in could reach data they had no business touching, and the company has now changed the endpoint configuration to limit access to authenticated users only.

What attackers could reach

ServiceNow instances are not a minor system of record for most enterprises. They sit at the center of IT operations, holding support tickets, employee records, internal documentation, asset inventories, security incident reports, workflow data, and configuration details for the corporate systems they manage. ServiceNow confirmed attackers successfully queried customer instance tables but has not said exactly which data was pulled in each case.

The most uncomfortable part is the ticket data. Support cases have become a favorite target precisely because of what people paste into them while troubleshooting. Credentials, API tokens, connection strings, and internal runbooks routinely end up in ticket bodies and attachments because an engineer was trying to get help fast. A single exposed ticket can hand an attacker the exact secret they need to move from one stolen dataset into a live system.

The endpoint in question

ServiceNow has not published technical details, and it is still evaluating whether the issue warrants a CVE. In the meantime, administrators comparing notes on Reddit pointed to a REST endpoint at /api/now/related_list_edit/create. According to those discussions, the endpoint was configured with requires_authentication=false, which would let unauthenticated requests reach instance data. The Friday update allegedly set that value back to true.

If that account holds up, this is a configuration-default problem more than a memory-corruption bug. The endpoint was reachable without a session, and the fix is essentially flipping one authentication flag. That is worth sitting with, because it is a pattern that recurs across SaaS platforms: a feature endpoint ships with authentication relaxed for some internal or legacy reason, and the relaxed setting survives into production where it should never have existed.

The blast radius is also scoped. The bulletin states the issue primarily affects customers running the Australia platform release, or customers on older releases who made certain configuration changes to their instances. "The security issue pertains to customers who are on the Australia platform release or made certain configuration changes to instances on releases prior to Australia," ServiceNow warned. If you never touched those defaults and you are not on Australia, you are likely outside the affected set.

Indicators and what to do now

Administrators sharing notes on the incident published indicators of compromise, including malicious requests originating from the IP address 51.159.98.241. ServiceNow's own guidance, echoed by the community, is concrete:

• Review ServiceNow logs for requests to /api/now/related_list_edit, paying close attention to traffic from 51.159.98.241.
• Audit any tickets and records that may have been exposed for sensitive content.
• Rotate every credential, token, or secret that was shared through support workflows. Assume anything pasted into a ticket is compromised until proven otherwise.
• Confirm API logging is actually enabled, because you cannot hunt for requests you never recorded.

ServiceNow says it has opened support cases with every customer it believes was affected. The flip side of that statement is the company's quiet all-clear: if you have not received a support case, ServiceNow does not currently believe you were impacted. That is a thin assurance to lean on, so running the log review yourself is the prudent move regardless of whether a case landed in your queue.

The broader lesson for SaaS owners

This incident is a reminder that your security perimeter now includes configuration defaults you did not write and cannot see. When a platform vendor changes an authentication flag on your behalf, you inherit both the original exposure and the cleanup. The practical defense is the boring one: enable comprehensive API logging before you need it, treat support tickets as a credential store that must be sanitized and rotated, and keep an inventory of which platform release each of your instances runs so you can quickly answer "are we in scope" when the next bulletin appears behind a login wall.

ServiceNow has not yet said how long the activity was ongoing or confirmed the full scope of stolen data, and it did not respond to questions before this story published. Until those details surface, affected organizations should operate on the assumption that anything reachable through that endpoint was seen, and act accordingly. You can track official updates and security guidance on the ServiceNow Trust and Security center and through the customer support portal where the original bulletin lives.