A single misconfigured checkbox quietly exposed enterprise IT data across multiple ServiceNow customer instances for weeks — and if community reports hold up, the company sat on the knowledge for two months before acting.
ServiceNow has confirmed a security incident in which attackers exploited a vulnerability to gain unauthorized access to customer instances. The company applied a patch to hosted instances on June 5, 2026. The public disclosure only surfaced on June 9 — and even then, the advisory was tucked behind a customer support login portal rather than published openly.
What Broke
The root cause was a misconfigured requires_authentication flag on a Scripted REST Resource endpoint — specifically /api/now/related_list_edit/create — which left it accessible without any credentials.
ServiceNow's Scripted REST Resources (custom API endpoints that handle data queries) have two separate security controls: one requiring a valid login, and another enforcing access control lists (ACLs) that govern what data a user can see at the row- and field-level. Some administrators found that even where authentication was enabled, ACL enforcement was not — meaning a logged-in but unauthorized user could still pull data they had no business seeing.
Administrators are advised to check ServiceNow logs for requests to /api/now/related_list_edit, particularly from the IP address 51.159.98.241.
The Timeline Problem
The breach timeline is what's drawing the most anger. A Reddit user named "d3s7iny" claimed their security team reported the flaw to ServiceNow, and that the company had been aware of it internally since April 7, 2026, classifying it as non-urgent and slotting remediation for a future update. Evidence of active exploitation traces back to June 2–3, 2026, roughly two months after that internal awareness date.
The vulnerability specifically affected customers on the Australia platform release or earlier versions who had applied certain configuration changes.
What Was at Stake
ServiceNow instances commonly hold IT support tickets, employee records, internal documentation, asset inventories, security incident reports, and workflow and configuration data for corporate infrastructure. In short: the kind of data that makes a secondary attack — credential stuffing, spear phishing, insider-threat mapping — far easier to execute.
ServiceNow confirmed that for a subset of customers, attackers successfully queried instance tables, but has not disclosed how many organizations were affected or whether data left the platform entirely.
What to Do Now
Affected customers have been notified directly. If you have not received a case from ServiceNow, the company says it did not observe anomalous activity on your instance. Even so, security teams should audit transaction logs for the indicators above, verify both authentication and ACL enforcement are enabled on all Scripted REST endpoints, and rotate any credentials, API tokens, or secrets that may have been stored within records or attachments accessible through the affected instance.
ServiceNow is still evaluating whether it will publish a CVE for the issue. For an incident of this scale — touching enterprise HR, IT ops, and security tooling — that decision is worth watching closely.