Enterprise security teams are auditing logs and rotating credentials this week after ServiceNow confirmed that attackers successfully queried sensitive customer instance data through an unauthenticated API endpoint, then spent four days patching in silence before placing its advisory behind a customer support portal login — a disclosure approach that has drawn immediate criticism for leaving organizations without the signal needed to start incident response.
The platform, used by more than 8,000 enterprises — including a majority of the Fortune 500 — to centralize IT service management, human resources operations, and security workflows, confirmed the breach on June 9 via support bulletin KB3067321. The patch had been applied to hosted customer instances four days earlier, on June 5. Customers who were not notified directly via a support case received no indication from ServiceNow that a breach had occurred or that logs needed reviewing.
How Unauthenticated API Access Opened Enterprise Data
The root of the breach is a Scripted REST Resource that shipped with the authentication flag requires_authentication set to false. That single Boolean disables 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.
ServiceNow instances function as the operational nerve center of enterprises that rely on them. IT support tickets, employee records, internal knowledge-base articles, asset inventories, security incident reports, and — critically — credentials and API tokens embedded in ticket descriptions and attachments are all stored in these tables. An unauthenticated query path bypasses not just a login screen but the entire privilege hierarchy that controls what each authenticated user is allowed to read. An attacker who can enumerate instance tables freely does not need to escalate privileges — they already have access to data that can enable lateral movement into every system connected to a ServiceNow integration.
Security researchers analyzing transaction logs across affected organizations found a consistent pattern: roughly five API requests per tenant, originating from IP address 51.159.98.241. Confirmed suspicious activity traces to June 2–3, 2026. ServiceNow has confirmed that for a subset of customers, attackers obtained evidence of successful table queries.
Third Unauthenticated Exploit in Eight Months
The June 2026 confirmed breach is the third significant authentication-related vulnerability in ServiceNow within eight months, and the first in which attackers reached customer data before a patch was applied.
In October 2025, ServiceNow patched CVE-2025-12420 — dubbed BodySnatcher by Aaron Costello, chief of SaaS security research at AppOmni — which allowed an unauthenticated attacker to impersonate any ServiceNow user using only an email address, bypassing multi-factor authentication and single sign-on entirely. Costello described it at the time as "the most severe AI-driven security vulnerability uncovered to date," noting that ServiceNow's Now Assist and Virtual Agent applications are used by nearly half of AppOmni's Fortune 100 customers. That vulnerability was patched before confirmed exploitation occurred.
In January and February 2026, ServiceNow addressed CVE-2026-0542, a critical sandbox bypass that allowed remote code execution without authentication in the platform's AI components. Again, no confirmed exploitation before the patch.
The June 2026 incident breaks that pattern. Attackers got there first.
ServiceNow Gated Advisory Breaks With Coordinated Disclosure Norms
The four-day window between remediation and public notice is generating its own wave of concern, separate from the breach itself. ServiceNow applied the patch on June 5. It did not post the bulletin until June 9 — and even then, KB3067321 requires a customer support portal login to access.
Coordinated vulnerability disclosure frameworks endorsed by the U.S. Cybersecurity and Infrastructure Security Agency, and implemented by organizations including Google Project Zero, call for timely public notification of the defensive community following vendor remediation. A gated advisory accessible only to customers already in a support relationship does not satisfy that standard. It creates a structural gap: organizations that are not directly notified via a support case — whether because they were not targeted or because the targeting went undetected — receive no vendor-triggered signal to investigate.
That gap matters for incident timelines. Organizations subject to GDPR's 72-hour breach notification requirement, SEC cybersecurity disclosure rules requiring public-company 8-K filings within four business days of determining materiality, or HIPAA's breach notification obligations under Business Associate Agreements cannot begin the clock on those obligations without a signal that a potential breach occurred. A silent patch provides no such signal.
Adding to the accountability questions, a Reddit post attributed to a user identifying themselves as a security professional claimed that a security team reported the vulnerability to ServiceNow, and that the company had been internally aware of the flaw since approximately April 7, 2026 — roughly two months before the June 5 patch. The claim alleges that ServiceNow initially classified the issue as non-urgent, with remediation planned for a future platform update. ServiceNow has not confirmed or denied that timeline, and BleepingComputer reported the company did not respond to questions before publication. The allegation has been reported by The Hacker News and Cybernews and remains unconfirmed.
What Data Was at Risk
ServiceNow has not publicly named which data categories were accessed in the affected instances. What it has confirmed is that for a subset of customers, attackers executed successful queries against instance tables. The platform's architecture means the range of potentially exposed data is determined by what each customer stores — which can include IT incident tickets, employee personal information, salary and HR records, asset inventory data, integration credentials, security incident reports, and workflow configuration details.
The credential-exposure risk is distinct and compounding. ServiceNow is a hub for enterprise integrations; tickets frequently contain API keys, service account passwords, database connection strings, and authentication secrets that IT staff paste into records during troubleshooting. An attacker with read access to those tables does not need to execute additional exploits — the credentials are already there, and they open doors into every connected system.
What Should I Do If My Organization Uses ServiceNow?
Whether or not a support case has been opened, security teams running ServiceNow should take the following steps immediately.
Confirm your notification status by checking whether ServiceNow opened a support case against your instance. If no case exists, ServiceNow says it did not observe targeting — but that assessment is only as good as the detection coverage it was based on.
Audit all Scripted REST API resources for instances where requires_authentication is set to false. This configuration pattern is not exclusive to the exploited endpoint — other custom Scripted REST Resources in any instance may carry the same posture, according to security researchers who analyzed the incident.
Pull transaction logs for the /api/now/related_list_edit/create path and filter for IP address 51.159.98.241. Flag any requests from that address in the June 2–5 window. Note that if REST message logging was not enabled on the instance, confirming or ruling out data exfiltration becomes significantly harder.
Rotate all credentials stored in IT tickets, including API keys, passwords, service account tokens, and integration secrets. Do not wait for formal confirmation that those records were accessed — treat exposure as the working assumption.
Enable verbose API logging across all REST resources if it is not already active. Without request body and response payload logging, assessing the scope of any future access is not possible.
When Queried and Exfiltrated Are Not the Same Word
ServiceNow has confirmed that attackers queried customer instance tables. It has not confirmed that data was exfiltrated — that is, copied and transmitted outside the platform — as distinct from read.
The distinction carries regulatory weight. Data that was read but not copied may trigger different notification obligations than data that was removed and stored elsewhere. Enterprises with HIPAA Business Associate Agreements, GDPR data processing obligations, or SEC disclosure requirements should not treat the vendor's unresolved distinction as a safe harbor. Legal counsel should be engaged while the investigation is active, and incident response documentation should reflect both scenarios until ServiceNow provides a more definitive characterization.
No CVE has been assigned as of publication. ServiceNow has said it is evaluating whether to issue one.
Frequently Asked Questions
Was my ServiceNow instance affected by this breach?
ServiceNow has opened direct support cases with customers it confirmed were targeted. If your organization has not received a support case, the company says it did not detect targeting activity on your instance — but you should still review transaction logs for the /api/now/related_list_edit/create path and look for requests from IP address 51.159.98.241 in the June 2–5 window, particularly if REST message logging was not fully enabled when the activity occurred.
What data was exposed in the ServiceNow breach?
ServiceNow has confirmed successful queries of customer instance tables for a subset of affected customers but has not specified which data types were accessed. Enterprise ServiceNow instances typically store IT support tickets, employee records, asset inventories, security incident reports, and API keys and credentials embedded in ticket descriptions — all of which would have been accessible through an unauthenticated query path.
How did attackers access ServiceNow customer data without a password?
A Scripted REST Resource in the platform was configured with requires_authentication set to false, disabling the identity check that normally gates every API request. That single misconfigured parameter allowed any external actor to send queries to the endpoint and receive data from customer instance tables without presenting any credential. ServiceNow applied a patch on June 5, 2026, resetting the endpoint to require authentication.
Does this breach trigger GDPR or HIPAA notification requirements?
Whether this incident triggers mandatory notification depends on each organization's specific data configuration and applicable legal obligations. GDPR requires breach notification to supervisory authorities within 72 hours of becoming aware of a personal data breach. HIPAA requires notification under Business Associate Agreements. The fact that ServiceNow held its advisory behind a gated portal for four days means some organizations lacked a vendor-triggered signal to start that clock — legal counsel should be consulted immediately to assess each organization's notification obligations under applicable law.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
