ServiceNow has disclosed a security incident in which a misconfigured API endpoint was exploited, granting unauthenticated access to customer instance data. The anomalous activity began around June 2 and went unaddressed until ServiceNow applied a security update on June 5. Public disclosure emerged on June 9–10, raising questions about the company’s incident response timeline.
The vulnerability centered on the /api/now/related_list_edit/create endpoint, where authentication requirements were inadvertently set to false. This meant anyone could send HTTP requests and access sensitive data including IT support tickets, employee records, internal documentation, asset inventories, and security incident reports. ServiceNow says a “subset of customers” were impacted and have been notified directly, primarily those on the Australia platform release or with specific configuration changes on older releases.
Adding to the controversy, reports from Reddit and security community forums suggest ServiceNow may have been aware of a similar vulnerability through bug bounty submissions as early as April 2026 — over a month before exploitation was detected. ServiceNow has not publicly addressed those claims.
Sources
- The Hacker News — ServiceNow Flaw Exploited to Gain Unauthorized Access
- BleepingComputer — ServiceNow discloses security incident
- SecurityWeek — ServiceNow patches vulnerability
Commentary
An authentication flag set to false on a production API endpoint is about as basic a misconfiguration as it gets — and for a platform that manages IT operations for some of the world’s largest enterprises, it’s inexcusable. The types of data exposed (support tickets, security incident reports, employee records) represent the kind of information attackers dream about for reconnaissance and privilege escalation in follow-on attacks.
The timeline is the real concern here. If bug bounty reports flagged a similar issue in April and the vulnerability was exploited starting June 2, that’s a two-month window of inaction. ServiceNow’s suggestion that the activity might be “security researchers or customers conducting their own security research” reads like damage control. When your API endpoint is wide open to the internet with no authentication, the distinction between researcher and attacker is academic.