ServiceNow API Flaw
ServiceNow Confirms Unauthenticated API Access Flaw, Attributes Activity to Security Researchers
Key Points
ServiceNow’s investigation traced the issue to a specific Scripted REST Resource: the endpoint /api/now/related_list_edit/create was deployed with requires_authentication = false, allowing unauthenticated access in some configurations.
ServiceNow said the flaw was limited to certain deployments—specifically customers “on the Australia platform release” or those that made particular configuration changes on releases prior to Australia.
ServiceNow later disclosed that “two security researchers” submitted a report on June 7 and that, per ServiceNow, the researchers told the company their activity was “solely for bug bounty submissions and no data was used or retained.”
Reporting on the initial incident response said ServiceNow observed “successful table queries” in logs for a limited group of clients, and community discussion pointed to probing activity from an IP address (51.159.98.241).
ServiceNow said security researchers — not hackers — were behind a wave of unauthenticated access to customer data through an exposed API endpoint, according to Dark Reading. The company patched the issue on June 5 by requiring authentication for the affected endpoint, then issued a public update on June 10 after community chatter and customer alerts spread faster than its official communications.
The exposed endpoint, `/api/now/related_list_edit/create`, was configured with `requires_authentication = false` in certain deployments — meaning anyone on the internet could query it with no password or token, Security Boulevard reported. ServiceNow said two researchers came forward on June 7 and told the company their activity was "solely for bug bounty submissions and no data was used or retained."
A Two-Month Gap Before the Silent Patch
The timeline raises hard questions. SC World reported that a confidential bug bounty submission describing the flaw arrived at ServiceNow on April 22. A Reddit user using the handle d3s7iny alleged ServiceNow had logged the issue internally as early as April 7, according to Dark Reading. Yet the patch did not ship until June 5 — roughly six weeks after that first report.
Anomalous probing of the endpoint began around June 2, three days before the fix. ServiceNow issued a gated advisory — visible only to logged-in customers — on June 9. That four-day gap between the patch and any customer notice drew criticism from security analysts, who argued enterprises could not respond to exposure they did not yet know about.
What the Endpoint Exposed and Who Was Hit
The flaw was not universal. ServiceNow said it affected customers "on the Australia platform release" or those who made specific configuration changes on earlier releases, per WebProNews. Transaction logs for affected instances showed roughly five hits per tenant during the scan window, with some tenants logging around 8,000 failed script errors — signs of messy, wide-net probing rather than targeted intrusion.
The stakes were real regardless of who was probing. ServiceNow instances store IT support tickets, which often contain passwords, API keys, and database connection strings pasted by staff during troubleshooting, Security Boulevard noted. Analysts advised affected organizations to rotate all credentials that may have appeared in those tickets, even if researchers claim no data was retained.
Researchers or Hackers? The Logs Tell a Murky Story
ServiceNow's official framing is clear: bug bounty researchers, not attackers. But community defenders are not fully convinced. The primary IP flagged in logs — 51.159.98.241 — was also observed probing for HP printer admin panels and phpMyAdmin interfaces, behavior more consistent with an indiscriminate scanner than careful ethical research, according to community analysis cited by Dark Reading.
Jacob Krell, Senior Director of Secure AI Solutions at Suzu Labs, argued the attribution question misses a larger point. Whether the actor was a researcher or an attacker, he told SC World, the technical exposure and its consequences are identical. Logs recorded all access as a "Guest" user — not because a guest account was compromised, but because the endpoint had no authentication context to log against at all.
What Comes Next for Enterprise Customers
ServiceNow serves more than 8,000 enterprises globally, including a majority of the Fortune 500, according to American Bazaar Online. For regulated industries like finance and healthcare, "successful table queries" — ServiceNow's own phrase from its gated advisory — may trigger mandatory breach-reporting requirements, regardless of whether the actor claimed ethical intent.
ServiceNow has not yet assigned a CVE — the standard identifier that lets automated scanners track a known vulnerability. Without one, organizations running on-premises or custom deployments have no automated way to confirm whether they are affected. The company said it is still "evaluating" whether to publish a formal CVE, leaving defenders to rely on manual checks for now.
Sentiment
Mostly NegativePublishers
23
Articles
4
Reach
27
