ServiceNow Patches Auth Bypass Four Days Before Disclosure
Key insights
- ServiceNow fixed the vulnerable `/api/now/related_list_edit/create` endpoint on June 5, four days before publicly disclosing the incident on June 9.
- The misconfigured endpoint required no authentication, potentially exposing IT tickets, employee records, and security incident reports stored in customer instances.
- Customers on the Australia platform release or certain older releases are primarily affected; organizations without an open ServiceNow support case are considered unaffected.
Why this matters
ServiceNow is used by enterprises worldwide for IT service management, meaning an authentication bypass directly touches the systems organizations rely on to manage vulnerabilities, incidents, and personnel data. The four-day gap between patching on June 5 and public disclosure on June 9 raises urgent questions about enterprise customers' ability to respond to exposure they were not yet informed about. As more enterprise platforms consolidate sensitive operational data, silent patching practices will face increasing scrutiny from regulators and customers who need to assess their own breach notification obligations.
Summary
ServiceNow patched a misconfigured REST endpoint on June 5, four days before publicly disclosing the security incident on June 9, 2026.
The endpoint `/api/now/related_list_edit/create` was set with `requires_authentication=false`, letting unauthenticated users query customer instance tables. Suspicious requests were traced to IP address `51.159.98.241`. The incident primarily affected customers on the Australia platform release or those who made specific configuration changes to older releases.
Essentially: (ServiceNow) silently fixed an auth bypass before customers knew it had been exploited.
- Affected organizations were notified via support cases; no open case means unaffected.
- ServiceNow has not yet decided whether to publish a CVE.
ServiceNow instances hold IT tickets, employee records, and internal security incident reports, making any unauthenticated access a material risk for enterprise clients.
Potential risks and opportunities
Risks
- Enterprises on the Australia platform release that stored credentials or sensitive personnel data in IT tickets face secondary breach risk if that data was exfiltrated before the June 5 patch.
- Affected organizations may face data protection regulatory obligations triggered by the incident, with compliance exposure compounded by the four-day gap between patching and public disclosure.
- ServiceNow customers without active API log monitoring may be unable to determine whether their instances were accessed, prolonging uncertainty and limiting remediation scope.
Opportunities
- API security vendors focused on authenticated endpoint auditing can use this incident to unlock budget conversations at affected ServiceNow enterprise customers.
- Incident response and forensic firms are positioned to capture advisory work from affected enterprises trying to reconstruct whether data was accessed before the June 5 patch.
- Competing ITSM platform vendors gain a credibility window to highlight their authentication controls to ServiceNow customers on the Australia platform release currently evaluating alternatives.
What we don't know yet
- Full data scope undisclosed: ServiceNow did not specify what data was actually retrieved from affected customer instances before the June 5 patch.
- CVE status unresolved: ServiceNow stated it is still evaluating whether to publish a CVE, leaving the vulnerability without a public identifier for affected organizations to track.
- Attribution behind IP 51.159.98.241: no threat actor or campaign has been publicly linked to the suspicious requests identified in the incident.
Originally reported by bleepingcomputer.com
Read the original article →Original headline: ServiceNow Confirms Security Incident — Unauthenticated REST Endpoint Exposed Customer Instance Data Including IT Tickets, Employee Records, and Security Incident Reports