ServiceNow's requires_authentication=false: The One Boolean That Exposed Enterprise Data Worldwide

A single configuration value shipped in production exposed an unknown number of enterprise organizations to unauthenticated data access. On June 5, 2026, ServiceNow quietly patched a REST API endpoint that had been deployed with requires_authentication=false, allowing anyone on the internet to query customer instance tables without credentials, tokens, or session cookies.

The endpoint, /api/now/related_list_edit/create, accepted unauthenticated HTTP requests and returned data from customer instances. IT support tickets containing internal URLs and system names. Employee records with personal information. Security incident reports with investigation details and response playbooks. Workflow records, asset inventories, and attachments containing screenshots, logs, and configuration data.

ServiceNow did not publicly disclose the issue until June 9, four days after silently patching. The company later acknowledged it had received a bug bounty submission describing the same flaw on April 22, six weeks before applying a fix. Anomalous activity targeting the endpoint was observed on June 2-3, with successful queries against a subset of customer instances confirmed.

The Authentication That Wasn't

The technical root cause is almost absurdly simple. ServiceNow's Scripted REST Resources framework allows developers to configure whether endpoints require authentication. The vulnerable endpoint shipped with this parameter set to false. Every HTTP request was processed under a permissive guest context with read access to multiple tables.

ServiceNow's access control list (ACL) framework operates separately from the authentication layer. This architectural separation means that even when authentication is absent, ACL rules may still apply. But in practice, the guest context had sufficient permissions to query data from customer instances, and the unauthenticated request bypassed every credential check the platform was designed to enforce.

When building the CIAM platform that scaled to serve over a billion users, we treated authentication as a binary gate: no request reaches application logic until identity is verified. The notion that a production API endpoint serving enterprise data could ship with authentication explicitly disabled represents a fundamental design governance failure, not a bug.

The patch applied on June 5 changed requires_authentication to true. One boolean. That is the entire fix.

The Timeline Problem

ServiceNow's timeline raises serious questions about disclosure responsibility for SaaS providers.

April 22: ServiceNow receives a confidential bug bounty submission describing the vulnerability. June 2-3: Anomalous activity detected on customer instances. June 3-4: Customers submit additional bug bounty reports about the same issue. June 5: ServiceNow applies the security update. June 7: Two security researchers submit a report to the bug bounty program. June 9: First public disclosure via Reddit and security community discussions. June 10: ServiceNow publishes a security advisory attributing activity to security researchers.

The six-week gap between the April 22 bug bounty submission and the June 5 patch is the critical window. ServiceNow has not explained what delayed the fix. Reddit users alleged the company had been aware since April 7 and had targeted the fix for a future platform release rather than an emergency patch. During that entire period, the endpoint remained live and queryable without authentication.

For customers, the four-day gap between the June 5 patch and June 9 disclosure is equally concerning. Organizations cannot audit for an incident they do not know occurred. Security teams that found nothing suspicious between June 5 and June 9 may simply have lacked the log visibility to detect API requests against a single endpoint during a two-day window.

What Organizations Should Do

Review ServiceNow logs immediately. Search transaction and node logs for requests to /api/now/related_list_edit/create, activity from IP address 51.159.98.241, and events attributed to the Guest user account around June 2-3. Forward ServiceNow logs to your SIEM for retention and analysis.

Audit stored credentials in ServiceNow. IT tickets, knowledge articles, and workflow records routinely contain embedded credentials: database passwords pasted into troubleshooting notes, API keys shared in ticket comments, SSH keys attached to change requests. If your instance was queried, treat any credentials stored in ServiceNow records as potentially exposed and rotate them immediately.

Review all custom Scripted REST Resources. Check every custom endpoint in your ServiceNow instance for the requires_authentication setting. Any endpoint set to false is an open door. This review should become part of your standard security governance process for ServiceNow development.

Demand SaaS vendor disclosure SLAs. The six-week patch delay and four-day disclosure gap represent process failures that enterprise customers should not accept. Push for contractual commitments on vulnerability response timelines and breach notification windows in your SaaS agreements.

Key Takeaways

• ServiceNow shipped a REST endpoint with requires_authentication=false, allowing unauthenticated queries to customer instance data
• Attackers queried IT tickets, employee records, security incident reports, and embedded credentials without any authentication
• ServiceNow received a bug bounty report on April 22 but did not patch until June 5, a six-week delay
• The patch was applied four days before public disclosure on June 9, leaving customers unable to assess their exposure
• ServiceNow instances typically contain credentials, internal documentation, and security playbooks that create secondary breach risk
• The fix was a single boolean change from false to true

Deepak Gupta is the co-founder and CEO of GrackerAI. He previously founded a CIAM platform that scaled to serve over 1B+ users globally. He writes about AI, cybersecurity, and digital identity at guptadeepak.com.