ServiceNow Zero-Auth API Breach: What the Disclosure Delay Reveals About SaaS Security in 2026

A Single Flag Brought Down the Authentication Wall

The root cause fits in one line of configuration: requires_authentication = false. That flag, set on the ServiceNow Scripted REST endpoint /api/now/related_list_edit/create, stripped away the entire access-control hierarchy the platform had built on top of it. Any role check, any ACL, any access policy — all of it is downstream of authentication, so once the authentication gate is removed, the rest becomes irrelevant.

The technical read-out from Deepwatch’s incident advisory CA-26-021 shows that the attack vector did not require credential stuffing or privilege escalation. Unauthenticated HTTP requests executed under the Guest user context, querying the sys_group_has_role table directly to append highly-privileged administrative roles to default group structures — a persistence mechanism, not just data retrieval. The attack swept from IP address 51.159.98[.]241 across enterprise instances on June 2–3, 2026, two days before ServiceNow applied its emergency hotfix.

The affected scope was wider than one endpoint. CSO Online’s reporting confirmed that a June 10 secondary update patched two additional unauthenticated Scripted REST endpoints that shared the same misconfiguration pattern — meaning the June 5 fix was incomplete. Customers on ServiceNow’s Australia platform release (generally available May 5, 2026) were most directly affected, but legacy Xanadu, Yokohama, and Zurich instances with custom API configurations were also in scope. ServiceNow confirmed to customers that a subset of instances were queried successfully, though it stopped short of specifying the data types accessed.

Enterprise ServiceNow instances are not inert data stores. They accumulate IT support tickets, employee records, asset inventories, internal security incident reports, and — critically — credentials. Engineers routinely paste API keys, service account passwords, and database connection strings into ticket descriptions and attachments. Unosecur’s analysis of the KB3067321 incident identifies this as the real long-tail risk: “credentials accumulate indefinitely by default with no rotation schedule and partial auditing,” and because they live in unstructured text, they escape the secret-scanning tools organizations rely on to catch credential sprawl.

The Four-Day Gap That Broke the Regulatory Clock

The technical fix and the disclosure timeline are two separate failures, and the second may carry larger legal consequences than the first.

ServiceNow received a confidential bug-bounty submission describing the vulnerability on April 22, 2026. Internal documentation from Deepwatch’s analysis shows the company noted the issue on approximately April 7 and deferred the fix to its Q4 “Brazil” release — a scheduling decision made before the bounty report arrived. The emergency hotfix was not deployed until June 5, six weeks after the bounty submission. The exploitation window on June 2–3 was therefore not a zero-day in the traditional sense: it was a known vulnerability that had been de-prioritized.

The disclosure mechanics compounded the problem. ServiceNow published support bulletin KB3067321 on June 9 — four days after patching hosted instances — and placed it behind its customer support portal login. BleepingComputer’s coverage documented the notification sequence: customers were informed via individual support cases, but the bulletin itself required an existing support relationship to access. Organizations that had not already opened a case had no vendor-triggered signal to investigate.

This is precisely the structural gap GDPR Article 33 was designed to prevent. A data controller that discovers a breach must notify its supervisory authority “without undue delay and, where feasible, not later than 72 hours.” A gated advisory that a controller only discovers after logging into a vendor portal starts the clock late and unevenly. The GDPR obligation runs from the moment a processor becomes aware of a breach — and the processor, in this case ServiceNow, had been aware of the broader vulnerability for weeks. Regulators in the EU and California are already expected to scrutinize whether the gated advisory satisfies disclosure standards under GDPR and CCPA, particularly where EU citizen data was processed by affected instances.

For organizations subject to SEC cybersecurity disclosure rules, the calculus is similar. The SEC’s 2023 incident disclosure rules require material incidents to be disclosed within four business days of determining materiality — a determination that requires knowing the breach occurred in the first place. A vendor-gated advisory can delay that determination by days or weeks.

What Enterprise Security Teams Should Do

The ServiceNow incident is a specific event, but the governance failures it exposes are generic to any enterprise relying on a major SaaS platform. Three categories of action apply immediately.

1. Verify the patch reached your instance and audit for post-exploitation artifacts

For hosted ServiceNow customers, the June 5 hotfix was deployed automatically. For self-hosted or on-premises installations, KB3067372 required manual application — and many organizations do not run ServiceNow on-prem, but some large enterprises and government deployments do. Confirm with your ServiceNow TAM that your instance received the update, then request the change log entry as written proof.

Patching is not the end of the investigation. SOCRadar’s breach analysis recommends preserving transaction logs covering June 1 onward and filtering specifically for unauthenticated requests where the user field shows guest, anonymous, or null. If such requests appear in your logs targeting the /api/now/related_list_edit/create endpoint or related scripted REST resources, treat this as a confirmed incident, not a near-miss. Rotate all credentials that may have been present in support ticket text and attachments, prioritized by privilege scope.

The secondary update on June 10 patched two additional endpoints with the same misconfiguration. Run a full audit of your ServiceNow instance’s scripted REST resources. Any endpoint with requires_authentication set to false that is not explicitly intended as a public API is a misconfiguration waiting to be weaponized.

2. Rebuild your SaaS vendor notification SLA into contract language

The ServiceNow incident illustrates a gap that is nearly universal in enterprise SaaS contracts: vendors have no contractual obligation to notify customers of security incidents within a specific window, in a specific format, or via a direct channel that does not require the customer to be already engaged with a support portal.

Your next SaaS contract renewal or vendor security review should include explicit notification SLAs: a defined maximum hours between confirmed exploitation and direct customer notification (e.g., 24 hours), a requirement that notification arrive via direct communication (email, webhook, or SIEM integration) and not only through a gated portal, and a right-to-audit clause allowing your team to independently verify fix deployment. Singapore’s Cybersecurity Act and its proposed amendments to vendor liability frameworks are already moving in this direction — similar language is now appearing in enterprise procurement templates across financial services in the Asia-Pacific region.

3. Treat your ticketing platform as a credential store and govern it accordingly

The deeper structural lesson from this incident is that support tickets are ungoverned secret stores. Engineers paste credentials into tickets for legitimate reasons — troubleshooting often requires it — but those credentials then persist indefinitely in ServiceNow’s database with no automatic expiration, rotation trigger, or secret-scanning coverage.

This problem predates the June 2026 breach and will outlast it. Implement a standing policy: any credential pasted into a support ticket must be rotated immediately after the ticket is resolved. Enable ServiceNow’s Sensitive Data Exposure (SDE) plugin if your license tier includes it, and configure it to detect and flag high-entropy strings consistent with API keys, connection strings, and tokens. For critical credentials (database admin accounts, cloud service principals, identity provider secrets), consider prohibiting inline inclusion in ticket text entirely and instead linking to a secrets manager entry that expires at ticket close.

The Bigger Picture: Shared Responsibility Has a Blind Spot

The cloud shared-responsibility model divides security obligations between vendor and customer, but it was designed primarily around infrastructure — compute, storage, network. SaaS sits at the top of the stack and introduces a category of responsibility the classic model does not cleanly allocate: configuration of vendor-controlled application-layer features.

The ServiceNow requires_authentication = false default was a vendor decision. The customer had no visibility into it, no dashboard displaying the authentication posture of every scripted REST endpoint, and no notification when the platform shipped a new release with that flag set incorrectly. But the data at risk — support tickets, employee records, credentials — was entirely customer data. The legal obligations triggered by a breach — GDPR Article 33, SEC four-day rule, HIPAA breach notification — fall on the customer, not the vendor.

This asymmetry is the structural problem the incident exposes. Vendors configure the controls. Customers own the notification obligation. The four-day disclosure delay was not an accident; it was the predictable outcome of a model where a vendor’s internal patch schedule and support-portal UX sit between an exploit and the organization’s ability to start its regulatory clock.

The fix requires more than patching endpoints or adding FAQ entries to support portals. It requires contractual commitments from SaaS vendors that bind them to the same notification timelines their customers face under data protection law — and it requires enterprise procurement teams to start demanding those commitments before the next breach, not after.

Frequently Asked Questions

Sources & Further Reading

• Further Reading
• ServiceNow discloses security incident exposing customer data — BleepingComputer
• CA-26-021: ServiceNow Unauthenticated API Endpoint Exploited in the Wild — Deepwatch
• ServiceNow fixes API issue after reports of suspicious tenant activity — CSO Online
• ServiceNow KB3067321: The NHI Governance Gap It Exposed — Unosecur
• ServiceNow Breach: Customer Data Exposed Through Unauthenticated API Access — SOCRadar