ServiceNow Data Breach: Unauthenticated API Exposes Customer Instance Tables

The ServiceNow data breach exploits the platform's Scripted REST API feature, which lets platform administrators define custom HTTP endpoints within their ServiceNow instance. Each Scripted REST Resource carries an authentication configuration field, requires_authentication, that controls whether the endpoint enforces session validation before processing the request.

When set to false, the endpoint accepts any HTTP request without checking for a valid session token, OAuth credential, or user login. The vulnerable endpoint at /api/now/related_list_edit/create shipped on the Australia platform release with requires_authentication=false. An attacker with network access to the instance could send an unauthenticated POST request to this endpoint and receive structured table data in response, exactly as an authenticated administrator would.

The query executes within the context of the ServiceNow application server, bypassing the login layer entirely. ServiceNow's underlying access control list (ACL) framework is a separate layer from authentication. Disabling authentication does not automatically trigger ACL enforcement. In many configurations the request is processed under a guest or service account context that inherits permissive default access to platform tables.

ServiceNow's ITIL-based architecture stores operational data in a flat table model. A successful query against /api/now/related_list_edit/create can return related list entries from incident records, change requests, knowledge articles, and configuration item data depending on the relationship definitions in the target instance. Security researchers reporting on the incident observed approximately five API hits per affected tenant, indicating attackers ran targeted queries rather than bulk table dumps.

The attack requires no user interaction, no credentials, no prior access, and generates no authentication failure events in the platform's standard security log. Detection depends entirely on API request logging and anomaly detection.

The ServiceNow data breach primarily affects organizations running the ServiceNow Australia platform release. The Australia release is a regionally designated distribution channel, not a geographic restriction. It delivers a specific software version to customers assigned to that track, which may include organizations outside Australia depending on contract and provisioning terms.

A secondary category of affected customers includes organizations on older releases who made specific configuration changes that reproduce the vulnerable state. ServiceNow has not disclosed the full list of affected releases or the total number of impacted customers as of June 10, 2026.

ServiceNow's 2026 customer base includes 3,066-plus enterprise accounts at the $1M+ annual contract value threshold and a broader platform footprint spanning every major industry. Healthcare organizations use ServiceNow for patient scheduling, clinical support workflows, and HR management. Financial services firms use it for vendor risk management and audit processes. Defense and government agencies use it for cleared facility operations and IT asset tracking. Critical infrastructure operators use it for operational technology change control. A successful query against an unpatched instance between June 2 and June 5 may have returned data from any of these operational domains.

Self-hosted and private cloud ServiceNow deployments that manage their own update schedules may not have received the June 5 patch. ServiceNow's security notice confirmed the fix was applied to hosted (NOW Platform cloud) instances. Organizations with self-managed deployments should verify their patch status directly with ServiceNow support and confirm the Scripted REST Resource authentication setting in their own configuration.

The ServiceNow data breach is dangerous specifically because of what ServiceNow instances contain. IT service management platforms are operational hubs where employees report broken things, request access, and document sensitive configurations. Support tickets routinely include embedded credentials shared during troubleshooting, API keys submitted in help requests, multi-factor authentication recovery codes provided by support staff, network diagrams and asset inventories, and internal documentation about security controls.

An attacker with read access to an organization's ServiceNow incident table holds a credential map assembled by the victim organization's own employees over months or years of normal operations. A 2024 help desk ticket asking IT to reset a VPN password may contain the replacement password in the response thread. A change request for a firewall modification may contain the device credentials used to execute the change. A software access request may contain a service account token submitted for approval.

This is the same pattern documented in SaaS platform credential theft campaigns targeting enterprise help desk tools: attackers who compromise a platform's API do not need to defeat encryption or endpoint security. They query the operational history the employees themselves created.

Data retrieved June 2-3 can fuel follow-on attacks against the same organizations weeks or months later, after the original exposure fades from incident response priority. Organizations that rotate credentials immediately after detection are protected. Organizations that audit only their ServiceNow security logs without rotating the embedded secrets in accessible tickets remain exposed even after applying the June 5 patch.

The ServiceNow data breach has one confirmed network-level IOC as of June 10, 2026. Organizations should check their transaction logs for any requests to the vulnerable endpoint during the active exploitation window.

The ServiceNow Transaction Log is available under System Diagnostics in the Admin UI. Any entry showing a Guest user account performing queries against /api/now/related_list_edit/create should be treated as confirmed unauthorized access. The Guest user activity is the clearest platform-level indicator that authentication enforcement failed.

API logging must be enabled to perform this audit. If your instance does not have API request logging configured, you cannot determine whether you were targeted. Enable it immediately via System Properties: set com.glide.sys.log_caller_info to true.

After auditing ServiceNow logs, pivot the attacker IP across all other enterprise systems, WAF logs, proxy logs, and cloud access logs. A source that successfully queried ServiceNow tables may have also probed other exposed APIs, SaaS platforms, or public-facing services during the same window. The credential leak patterns documented in large-scale dark web exposure events show that attackers who gain SaaS platform access routinely expand to adjacent targets using credentials found inside.

Follow these seven steps to confirm patch status, detect exploitation, and close the exposure window. Work through them in order.

The ServiceNow data breach is a template for a category of risk that most enterprise security programs underestimate: the SaaS platform that sits inside the perimeter and is trusted precisely because it requires authentication to access, but which becomes a browsable archive of operational secrets the moment that authentication check fails.

Most enterprise security programs focus on protecting data at the source: encrypting databases, hardening servers, monitoring for exfiltration events. ServiceNow bypasses that model because employees voluntarily write credentials, network details, and access instructions into support tickets and change requests as part of normal IT operations. The platform is designed to be searched and shared. When an unauthenticated API endpoint bypasses the login layer, an attacker does not need to defeat endpoint detection, pivot through multiple systems, or crack encrypted storage. They query the help desk.

ServiceNow is not the only enterprise SaaS platform with this risk profile. Any platform that employees use to document operational information, request access, or share troubleshooting details holds the same type of credential inventory. Salesforce instances, Jira projects, Confluence spaces, and Zendesk ticket queues all accumulate credentials over time when employees treat them as secure-by-default internal tools.

The four-day gap between ServiceNow's quiet June 5 patch and the June 9 public disclosure is a process problem that compounds the technical risk. Organizations cannot audit for an incident they do not know occurred. Security teams that detected nothing unusual between June 5 and June 9 are not necessarily unaffected. They may simply have lacked the log visibility to see five API hits against one endpoint during a two-day window.