ServiceNow has confirmed a security incident after a misconfigured API endpoint exposed enterprise customer data to unauthorized access. The ServiceNow data breach became public on June 9, 2026, when the company began notifying affected customers through a gated support bulletin and direct support cases. ServiceNow had already pushed a patch to hosted instances on June 5. But questions about how long the company knew about the flaw are now generating serious scrutiny.
What Went Wrong With the API
A single misconfigured parameter caused the incident. ServiceNow had configured a REST API endpoint at /api/now/related_list_edit/create with requires_authentication=false. That setting allowed anyone to send requests to the endpoint without logging in. No username, password or verification of any kind.
The June 5 security update flipped that parameter to requires_authentication=true. ServiceNow confirmed that unauthorized parties successfully queried a subset of customer instances before the fix went out. Administrators discussing the incident online quickly identified the vulnerable endpoint. They also shared a key indicator of compromise: API requests originating from the IP address 51.159.98.241.
What Data Was at Risk
ServiceNow has not disclosed exactly what data the unauthorized queries returned. However, a typical ServiceNow instance holds a significant volume of sensitive enterprise information. That includes IT support tickets, employee records, internal documentation, asset inventories, security incident reports, and system configuration data.
Support ticket data is especially valuable to anyone with bad intentions. Tickets frequently contain credentials, API tokens, and authentication secrets that employees share during troubleshooting. Accessing that material can open doors to systems far beyond the ticketing platform. Customers who have not received a direct support case from ServiceNow are not believed to be among those affected.
The Disclosure Timeline Raises Questions
The disclosure timeline is where this ServiceNow data breach gets complicated. ServiceNow received a confidential bug bounty submission describing this exact vulnerability on April 22, 2026. The company did not deploy a fix until June 5. That is more than six weeks after the initial report, and only after activity on customer instances had already begun.
Between June 3 and June 4, additional reports arrived through customer bug bounty programs. Those submissions closely matched the April report. ServiceNow investigated, confirmed unauthorized queries on a subset of instances, and pushed the patch on June 5. Two more researchers filed a bug bounty report on June 7.
ServiceNow now believes the observed activity came from security researchers and customers running their own tests. The researchers stated they did not retain, screenshot, or misuse any queried data. Their queries, they said, served only to validate findings for bug bounty submissions. The company has not yet publicly explained why it took six weeks to act on the April report.
Who Is Affected and What the Patch Covers
The incident primarily affects customers on the Australia platform release. It also affects those on older releases who made specific configuration changes to their instances. Hosted customers received the patch on June 5 and do not need to deploy anything manually.
Administrators should still review instance logs for requests to /api/now/related_list_edit. Any requests from 51.159.98.241 are a red flag. Teams should rotate any credentials, API tokens, or authentication details that passed through support workflows. Enabling API logging across the environment is also a worthwhile precaution. ServiceNow is still deciding whether to assign a CVE to the vulnerability.
Final Thoughts
The ServiceNow data breach shows how a single misconfigured parameter can expose sensitive enterprise data at scale. Authentication controls are not a secondary concern. They are foundational. When a platform skips them — even unintentionally — the consequences reach far into the organizations that depend on it.
The researcher attribution offers some relief. But the six-week gap between the first bug report and the patch is a legitimate concern. Enterprises deserve a clear explanation of that delay. In the meantime, any ServiceNow customer not yet contacted should review their logs, rotate relevant credentials, and confirm their instances did not fall in the affected scope.
