ServiceNow's Authentication Problem Is a Pattern, Not an Incident

The Core Failure

On June 2, 2026, someone began sending unauthenticated POST requests to a ServiceNow REST endpoint and extracting structured enterprise data. No credentials. No session token. No exploit kit. When the requires_authentication parameter is set to false, the endpoint accepts any HTTP request without checking for a valid session token, OAuth credential, or user login. This was not subtle—it was a configuration flag shipped in the wrong position.

The specific endpoint was /api/now/related_list_edit/create, configured with requires_authentication=false, allowing unauthenticated HTTP requests to access sensitive data within customer instances. An attacker with network access could send an unauthenticated POST request to this endpoint and receive structured table data in response, exactly as an authenticated administrator would.

ServiceNow patched on June 5. Enterprise security teams are auditing logs and rotating credentials after ServiceNow confirmed that attackers successfully queried sensitive customer instance data — then spent four days patching in silence before placing its advisory behind a customer support portal login. The platform is 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.

What Was Exposed

The tables matter. ServiceNow is not a UI layer—it is the operational record system for enterprise IT. 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 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.

The confirmed exploitation footprint was small: security researchers analyzing transaction logs across affected organizations found a consistent pattern of roughly five API requests per tenant, originating from IP address 51.159.98.241. Low request counts fit reconnaissance patterns—enumeration over bulk exfiltration that would trigger rate-limiting alerts.

The Attribution Problem

ServiceNow said: "Based on our investigation to date, we believe the observed activity is attributable to security researchers or customers conducting their own research. We are in contact with the researchers, and they have advised their activity was solely for bug bounty submissions and no data was used or retained."

The Mozilla-BugBounty user agent string in the requests is a known evasion technique. The Mozilla-BugBounty string could indicate either a bug bounty researcher who exceeded scope or a threat actor deliberately mimicking one to fly under the radar. AppOmni's CISO offered appropriate skepticism: "at least one system publicly associated with exploitation of this vulnerability also appears to have targeted tenants of other SaaS platforms with similar unauthenticated-access weaknesses. While researcher activity clearly occurred, I would be cautious about saying all observed activity was benign research until the investigation is complete."

A Pattern, Not a One-Off

This is the third major authentication failure in ServiceNow in eight months, and the first with confirmed exploitation before patching.

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. The vulnerability carries a CVSS score of 9.3 out of 10.

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.

The structural issue transcends any single CVE. ServiceNow's platform allows operators to configure authentication as a per-endpoint toggle, with off as a valid state. Nobody wrote the test, because the platform treated 'no auth' as valid configuration for a sensitive endpoint. When authentication is something you toggle per endpoint instead of a default the platform enforces, an exposed endpoint is not a bug the system rejects.

The Disclosure Problem Is Separate and Equally Serious

The company updated hosted customer instances to patch a security issue it reportedly had known about since April 7. Exploitation began June 2. The patch went out June 5. The advisory was published June 9—behind a customer portal login only. 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.

That four-day gap between silent patch and gated disclosure breaks detection chains for security teams relying on public signals. Organizations without a direct support case from ServiceNow had no trigger to pull transaction logs. The retroactive audit window is open but narrowing as log retention policies age out the relevant data.

The notification delay spans up to 59 days from alleged discovery on April 7 to patch application on June 5. If accurate, ServiceNow knew about this vulnerability for two months before patching—a window that, if known externally, would have created serious dwell-time risk.

Self-Hosted Customers Carry Additional Exposure

This is a cloud (hosted) incident affecting ServiceNow-managed tenants, so the primary action for hosted customers is to confirm whether they were notified and to review their own transaction logs. Hosted customers received the June 5 patch automatically.

Self-hosted customers should exercise additional caution, as ServiceNow has not publicly confirmed whether self-hosted deployments are affected or released a dedicated patch for those environments. As a precautionary measure, administrators should manually verify that the affected Scripted REST Resource enforces authentication by ensuring the requires_authentication setting is configured to true.

Security teams are also advised to review all Scripted REST API resources within their environment and audit any entries where requires_authentication remains disabled, with particular attention given to older or legacy resources whose security defaults may differ from modern implementations.

What to Watch

1. CVE assignment and formal CVSS score for KB3067321. At the time of writing, ServiceNow had not assigned a CVE for this issue and was still evaluating whether one would be published. Publication will trigger a fresh wave of scanning by threat actors targeting unpatched self-hosted instances.

2. Self-hosted patch confirmation. ServiceNow has not clarified the exposure surface for on-premises deployments. That silence is the most operationally urgent open question for operators running their own infrastructure.

3. Breach notification filings. GDPR Article 33 requires notification within 72 hours of awareness. Watch for EU regulatory filings that will establish a more precise affected-customer count and data classification than ServiceNow has disclosed.

4. Log correlation deadline. Pull transaction logs now, before retention windows close. IoCs to search: requests to /api/now/related_list_edit/create, Guest user account activity, and traffic from IP 51.159.98.241.

5. Whether the same IP targeted other SaaS platforms. If AppOmni's CISO assessment holds and 51.159.98.241 touched other SaaS tenants with similar misconfigurations, this incident extends well beyond ServiceNow's customer base.

6. Platform default policy change. The underlying systemic risk is the opt-in authentication model for Scripted REST Resources. Watch for whether ServiceNow changes the platform default to requires_authentication=true for all new endpoints—and what it does about the long tail of legacy resources already running with it set to false.