Enterprise security teams spent this week auditing logs and rotating credentials after ServiceNow confirmed that attackers successfully queried sensitive customer instance data through an unauthenticated API endpoint. The platform, relied on by more than 8,000 enterprises including a majority of the Fortune 500, confirmed the breach on June 9, 2026 via support bulletin KB3067321. The patch had already been quietly applied to hosted customer instances four days earlier, on June 5, and ServiceNow placed its advisory behind a customer support portal login, leaving organizations without the signal needed to begin incident response. Confirmed suspicious activity traces to June 2 and 3, 2026.
What Happened
ServiceNow confirmed that attackers reached customer instance data through a Scripted REST Resource that shipped with the authentication flag requires_authentication set to false. That single misconfigured Boolean disabled the identity check that normally gates every inbound API request, allowing anyone on the internet to send queries to the endpoint without a valid session or credential. The specific path identified in community and third-party reporting as /api/now/related_list_edit/create accepted and processed those queries directly against customer instance tables.
The disclosure timeline has drawn immediate criticism. ServiceNow applied the fix to hosted instances on June 5, then waited four days before publishing bulletin KB3067321 on June 9. Because the advisory sat behind a customer support portal login, organizations that were not directly notified via a support case received no indication that a breach had occurred or that their logs needed reviewing.
What Was Taken
ServiceNow instances function as the operational nerve center of the enterprises that run them. The tables exposed through the unauthenticated path hold IT support tickets, employee records, internal knowledge base articles, asset inventories, and security incident reports. Critically, they also hold credentials and API tokens embedded in ticket descriptions and attachments.
Security researchers analyzing transaction logs across affected organizations found a consistent pattern: roughly five API requests per tenant, all originating from IP address 51.159.98.241. ServiceNow has confirmed that for a subset of customers, attackers obtained data through these queries. Because the endpoint bypassed the privilege hierarchy entirely, any data an attacker could enumerate was readable in full, with no need to escalate access.
Why It Matters
An unauthenticated query path does not just bypass a login screen. It bypasses the entire privilege hierarchy that controls what each authenticated user is permitted to read. An attacker who can freely enumerate instance tables does not need to escalate privileges, because they already hold access to data that can enable lateral movement into every system connected to a ServiceNow integration.
That is the strategic danger here. ServiceNow sits at the center of IT service management, HR operations, and security workflows, and it integrates outward into the rest of the enterprise stack. Credentials and API tokens harvested from ticket data are reusable keys to those connected systems. The gated, delayed disclosure compounds the risk: defenders who never saw the advisory have had no reason to hunt for the indicators that would tell them whether their tenant was among those queried.
The Attack Technique
The breach required no exploit chain and no privilege escalation. The Scripted REST Resource was deployed with requires_authentication set to false, which removed the authentication requirement from inbound requests to the /api/now/related_list_edit/create path. Attackers simply sent queries to that endpoint, and the platform processed them directly against customer instance tables.
The observed activity was deliberate and low-volume: approximately five requests per tenant from a single source IP, 51.159.98.241, with confirmed suspicious activity dated to June 2 and 3, 2026. The small request count per tenant is consistent with targeted enumeration rather than a noisy mass scrape, which makes the activity easier to miss in logs without a specific indicator to search for.
What Organizations Should Do
- Search instance transaction and API logs for inbound requests to /api/now/related_list_edit/create and for any traffic from IP address 51.159.98.241, focusing on the June 2 to 5 window.
- Treat any credentials, API tokens, or secrets stored in ticket descriptions, comments, or attachments as compromised, and rotate them immediately along with any downstream credentials they unlock.
- Audit every Scripted REST Resource and inbound integration for the requires_authentication flag, and confirm none are inadvertently set to false.
- Review integrations and service accounts that connect ServiceNow to other internal systems for signs of lateral movement or anomalous use following the exposure window.
- Confirm bulletin KB3067321 has been applied to all hosted and self-managed instances, and verify the patch level directly rather than assuming auto-application.
- Establish a process to monitor gated ServiceNow advisories proactively, since direct notification was not guaranteed and the support portal advisory may not surface without active checking.
Sources: ServiceNow Data Breach: Gated Advisory Left Customers Unaware of Exploited Zero-Auth API