ServiceNow Security Incident: Unauthenticated API Access Exposing Customer Instance Data

ServiceNow has disclosed a high-severity vulnerability affecting an exposed API endpoint, caused by missing authentication controls. Although no official CVE has been assigned at the time of writing, the issue has reportedly been exploited in the wild, with the vendor confirming anomalous activity and successful unauthorised queries against a subset of customer instances. The vulnerability could allow unauthenticated attackers to query customer instance tables, potentially exposing sensitive data.

ServiceNow confirmed that remediation was applied to hosted customer instances on 5 June 2026, and no additional customer action is required to deploy the fix. Organisations are nevertheless advised to review instance logs and monitor for any suspicious or unexpected API activity that may indicate prior exploitation attempts.

Community reporting indicates the issue may be associated with the REST endpoint '/api/now/related_list_edit/create', although this has not yet been formally confirmed by ServiceNow. Researchers and administrators discussing the incident have suggested the root cause relates to a Scripted REST Resource that was reportedly deployed with the 'requires_authentication=false'. Allowing requests to be processed without a valid session, authentication token, or credential check. Reports indicate that the update applied on 5th June 2026 changed this setting to true, thereby enforcing authentication requirements. Due to the unauthenticated nature of the requests, related activity may appear within transaction logs as originating from the Guest user account, which has reportedly caused confusion during incident reviews and log analysis. ServiceNow has framed the affected scope as limited to customers operating on the Australia platform release, as well as customers on older releases who implemented certain configuration changes. 

Organisations should first confirm whether they received a ServiceNow support case relating to this incident, as the vendor has advised that affected customers were notified directly. ServiceNow has already applied the remediation to hosted customer instances, meaning no additional patching activity is required for customers using the vendor-hosted platform. However, self-hosted customers should exercise additional caution, as ServiceNow has not publicly confirmed whether self-hosted deployments are affected or released a dedicated patch for those environments. As a precautionary measure, administrators should manually verify that the affected Scripted REST Resource enforces authentication by ensuring the requires_authentication setting is configured to true, rather than assuming protections have been automatically applied.

Security teams are also advised to review all Scripted REST API resources within their environment and audit any entries where requires_authentication remains disabled, with particular attention given to older or legacy resources whose security defaults may differ from modern implementations. Community reporting has suggested the exploited endpoint may have been a long-standing resource that had not undergone significant recent modification, although this has not been formally confirmed by ServiceNow. Administrators should additionally verify that Access Control List (ACL) enforcement is correctly configured, as authentication requirements and ACL enforcement operate independently within Scripted REST Resources. An endpoint may therefore require valid authentication while still bypassing row-level or field-level access controls if ACL enforcement is not enabled. Where exposure or unauthorised access is suspected, organisations should rotate any credentials, API tokens, or secrets that may have been stored within records, tickets, or attachments accessible through the affected instance.

Organisations should review ServiceNow transaction and node logs for indicators associated with this incident, including requests to the vulnerable endpoint /api/now/related_list_edit/create, activity originating from the IP address 51.159.98.241, and events occurring around 2-3 June 2026. Particular attention should be given to any related_list_edit operations attributed to the Guest user account, as these may represent unauthorised activity rather than legitimate guest access. ServiceNow logs should be forwarded to and actively monitored within a SIEM platform to support timely detection and investigation. Where suspicious activity is identified, organisations should escalate through established incident response processes and preserve all relevant logs and artefacts for forensic analysis.

It should be noted that while transaction and node logs can confirm that requests reached the affected endpoint, including associated timestamps and source IP addresses, most environments are unlikely to retain the request body or response payload data unless REST message logging had been enabled prior to the incident. Where such logging was not configured, this limitation should be formally documented to ensure investigators clearly understand the extent of available evidence and any resulting visibility gaps.