ServiceNow API Flaw Exposed Customer Data Before Patch

ServiceNow disclosed a security incident this week after attackers exploited an unauthenticated API endpoint to access customer instance data. The vulnerability allowed anyone on the internet to query sensitive information without logging in.

The company patched hosted instances on June 5, 2026—but the timeline raises questions about how long the exposure existed and why a fix took six weeks after the initial bug report. Similar API security failures have plagued enterprise software recently, including the LiteLLM RCE chain added to CISA's KEV catalog.

What Happened

The vulnerable endpoint, /api/now/related_list_edit/create, was configured with requires_authentication=false. This meant unauthenticated HTTP requests could access data within customer instances directly.

ServiceNow customer instances commonly contain:

• IT support tickets
• Employee records
• Credentials and API tokens
• Internal documentation
• Asset inventories
• Security incident reports
• Configuration details for corporate systems

The company declined to specify what data attackers actually accessed, stating only that exploitation involved querying "customer instance tables."

Timeline Problems

The disclosure timeline doesn't reflect well on ServiceNow's response process:

• April 22, 2026: ServiceNow received a confidential bug bounty submission describing the issue
• June 2-3, 2026: Attackers began exploiting the vulnerability
• June 5, 2026: ServiceNow applied a security update to hosted instances
• June 9, 2026: Public disclosure

That's a 44-day gap between the bug bounty report and the patch. Attackers appear to have found the same issue independently and began exploitation before ServiceNow shipped a fix.

The company opened support cases only with customers it determined were affected, rather than issuing a broad notification. Organizations running the Australia platform release or "certain configuration changes" on older releases were impacted.

The Fix

ServiceNow's patch changed the API endpoint configuration to require authentication, setting requires_authentication to true. A straightforward fix for a flaw that should never have existed—APIs handling sensitive data should require authentication by default.

Lessons for Enterprise Security Teams

This incident illustrates several recurring problems with SaaS security:

Default configurations matter. An endpoint configured to allow unauthenticated access probably started as a development convenience that made it to production. Enterprise software vendors need security-by-default configurations, not opt-in security.

Bug bounty-to-patch timelines are a risk window. When researchers find vulnerabilities, so do attackers. Six weeks between report and patch is enough time for independent rediscovery and exploitation—which is exactly what happened here.

SaaS visibility is limited. ServiceNow customers had no way to know this vulnerability existed or whether they were affected until the company chose to tell them. Organizations depending on SaaS platforms inherit their vendors' security posture without much ability to audit it.

What to Do

If you're a ServiceNow customer:

1. Check for communication from ServiceNow. The company opened support cases with affected customers.

2. Review access logs for the /api/now/related_list_edit/create endpoint, looking for anomalous requests during the June 2-5 window.

3. Assume exposure if you were running affected releases. Treat any sensitive data in your ServiceNow instance as potentially compromised.

4. Rotate credentials and API tokens stored in ServiceNow, particularly if your instance was on an affected platform release.

For broader context on securing enterprise platforms against data breaches, assume that SaaS applications are targets. Monitor vendor security advisories, maintain incident response playbooks that account for third-party compromises, and limit the sensitivity of data stored in platforms you don't control.