ServiceNow — the workflow platform that sits at the center of IT, HR, and security operations for a large share of the Fortune 500 — has told customers that a flaw in one of its REST API endpoints allowed data inside their instances to be queried without authentication.

The company applied a security update to hosted customer instances on June 5, 2026, and disclosed the issue publicly on June 9 through a support bulletin. In ServiceNow’s own framing, the bug “could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended.” The platform observed “successful queries of instance tables against a subset of customers” before the fix went in.

What it has not done is quantify the blast radius. There is no CVE assigned as of disclosure, no published count of affected instances, and no statement detailing exactly which data was queried or exfiltrated. For a platform that routinely holds IT tickets, employee records, asset inventories, internal documentation, and — ironically — security incident data, that silence is doing a lot of work.

The endpoint at the center of it

According to administrator discussion circulating after disclosure, the culprit is the /api/now/related_list_edit endpoint (specifically the create action), which was reportedly configured with requires_authentication=false. That setting let unauthenticated HTTP requests reach sensitive data inside customer instances; the patch flipped it to require authentication.

A caveat worth stating plainly: that endpoint detail, along with an indicator-of-compromise IP address (51.159.98.241) some defenders are circulating, comes from community and researcher analysis — not from ServiceNow’s official bulletin. Treat the specifics as well-informed reconstruction rather than vendor-confirmed fact until ServiceNow publishes more.

ServiceNow says the exposure was scoped to customers on its Australia platform release, plus customers who made certain configuration changes on earlier releases.

”Researchers, not bad actors” — and a 44-day gap

ServiceNow’s central claim is that the activity it detected was benign. The company attributes the observed queries to security researchers and customer research teams tied to bug-bounty submissions, not to malicious threat actors. Spokesperson Courtney Johnson told TechCrunch the evidence “came from those security researchers and customer research teams, not bad actors,” and that the researchers said their activity “was solely for bug bounty submissions and no data was used or retained.”

That is the reassuring version. The less reassuring version is the timeline. Reporting indicates ServiceNow received a confidential bug-bounty submission describing the issue on April 22, 2026, with some accounts placing internal awareness even earlier — yet the fix did not land on hosted instances until June 5. That is roughly a 44-day window during which a known unauthenticated-access flaw sat in production, a gap several outlets flagged.

Compounding the friction: TechCrunch reported that ServiceNow’s advisory was initially gated behind a customer login, meaning organizations trying to assess their own exposure could not read the disclosure without already being authenticated into the platform.

What ServiceNow customers should do now

Because ServiceNow patched the hosted environment centrally, customers do not need to apply a fix themselves — but they should not treat this as a closed matter. Recommended actions:

  • Review API logs for requests to /api/now/related_list_edit, paying attention to unauthenticated calls and to the community-reported IOC IP.
  • Audit potentially exposed tables — tickets, employee and HR records, asset and configuration data — for sensitive content that may have been queried.
  • Rotate credentials and API tokens that were shared through support or integration workflows.
  • Confirm API logging is enabled so that any future activity is reconstructable.

ServiceNow says its priority was reaching the affected subset of customers directly rather than issuing a broad alarm — “it was not broad,” in the company’s words. For everyone else running the platform, the open questions about instance counts and exposed data mean the prudent posture is to verify, not to assume the “researchers only” explanation covers every query that hit the endpoint.

Sources