🛡️ SecOps

ServiceNow Zero-Auth API Exploitation: Customer Instance Data Exposed Through Unauthenticated Endpoint

ServiceNow disclosed an active security incident beginning 2 June in which an unauthenticated API endpoint allowed attackers to query customer instance data including IT ticket contents, asset inventories, and stored credentials. Exploitation began 2 June; ServiceNow patched the endpoint by 5 June. No CVE was assigned at time of disclosure. Organisations should review ServiceNow access logs for the incident window.

3 min read
#servicenow#api-security#itsm#data-breach#zero-auth#saas-security#incident-response

ServiceNow disclosed an active security incident on 2 June in which an unauthenticated API endpoint within its “Australia” platform release allowed external parties to query customer instance data without authentication. The affected endpoint — /api/now/related_list_edit/create — was reachable without a valid ServiceNow session token and could be used to query IT service management ticket contents, asset inventory tables, and in some configurations, stored credential fields.

ServiceNow identified and patched the endpoint by 5 June. The exploitation window ran approximately from 2 June through the patch date.

What Was Accessible

The related_list_edit API endpoint is used by the ServiceNow UI to render related record lists in form views. An unauthenticated version of this endpoint — introduced in the “Australia” platform release that some tenants had applied — returned query results without verifying the requesting user’s session.

Data accessible via the unauthenticated endpoint depended on the ServiceNow instance configuration, but commonly included:

IT Service Management ticket data: Incident, change request, and problem records — which often contain technical troubleshooting notes, configuration details, IP addresses, and in some cases, credentials shared in ticket comments.

Asset and CMDB records: Configuration item data including server names, IP addresses, software versions, and network topology information stored in the CMDB.

Stored credential fields: Some ServiceNow implementations use Credential Stores for integrations with third-party systems (monitoring tools, cloud providers, network devices). Credential field values may have been accessible in plaintext depending on field-level access configuration.

User records: Basic user profile data in the sys_user table was accessible via related list queries in some configurations.

Scope and Affected Instances

The vulnerability affected ServiceNow instances that had applied the “Australia” platform release before the patch. ServiceNow’s release naming convention uses city names for each platform update; “Australia” is a specific point release. Instances on earlier platform releases were not affected.

ServiceNow notified affected customers by email within 48 hours of the patch. Organisations running ServiceNow should check their notification inbox and verify whether their instance was on the “Australia” release during the 2–5 June window.

For organisations notified as affected:

  1. Review ServiceNow API access logs (available via System Logs → REST Messages or the API Transactions Log) for the 2–5 June window. Look for requests to /api/now/related_list_edit/create from unexpected IP addresses, particularly external IPs.

  2. Audit credential stores: If your ServiceNow instance uses Credential Management (/now/credential_record.do), review all stored credentials and rotate any that may have been accessible during the incident window.

  3. Review CMDB data sensitivity: Assess whether your CMDB contained data that would be material to an attacker (internal IP addresses, server names, software versions, network topology). The ServiceNow CMDB often holds infrastructure information that aids lateral movement planning.

  4. Ticket content review: For IT tickets created or modified in the vulnerability window, assess whether they contained credentials, sensitive configuration data, or other information shared in ticket comments.

For all ServiceNow customers:

  1. Apply the ServiceNow patch: If your instance was on the “Australia” release, confirm the patch has been applied. The patched version is available through the standard ServiceNow upgrade process.

  2. Review API endpoint permissions: Periodically audit ServiceNow REST API endpoint access controls, particularly for endpoints added in recent platform updates. Custom application scope access policies and ACL configurations should be reviewed after each major platform upgrade.

Share this article