ServiceNow disclosed on 10 June 2026 that attackers exploited an unauthenticated access flaw in one of its REST API endpoints, allowing unauthorised queries to customer instance tables between 2 and 5 June 2026. The company applied a patch to hosted customer instances on 5 June and stated it believes the observed activity was likely tied to security researchers conducting bug bounty work rather than malicious threat actors. A CVE has not yet been published.
The Vulnerability
The flaw resided in a REST endpoint at /api/now/related_list_edit/create. The endpoint had been deployed with requires_authentication=false, a configuration flag that disables credential checks for incoming requests. An attacker who discovered the endpoint could send unauthenticated queries to access data within the customer’s ServiceNow instance without providing valid credentials.
ServiceNow received a confidential bug bounty submission describing the issue on 22 April 2026. The gap between that report and the exploitation window raises questions about patch prioritisation timelines. Exploitation began on 2 June – more than five weeks after the initial report – and was active for three days before a patch was deployed.
ServiceNow’s advisory notes that the company believes the exploitation was conducted by researchers rather than criminal actors. That assessment may be accurate for the observed activity, but it does not address the exposure that existed during the window, nor the possibility that other parties independently identified the endpoint before the patch was applied.
Indicator of Compromise
Administrators are advised to audit their ServiceNow instance logs for requests to /api/now/related_list_edit, particularly from IP address 51.159.98.241. Requests from this address during the window of 2 to 5 June should be treated as potential indicators of unauthorised access and reviewed for what data was queried.
The IP falls within a well-known cloud hosting range. This is consistent with automated security research tooling but also consistent with threat actors using cloud infrastructure to anonymise their activity.
The Wider Problem: Authentication Flags in Enterprise SaaS
The ServiceNow case is a useful illustration of a category of vulnerability that appears repeatedly in large enterprise SaaS platforms and internal API ecosystems: authentication controls that are correct by default but can be disabled through configuration, with no mechanism to detect or prevent that configuration reaching production.
The combination of API endpoint proliferation, feature flags that exist for legitimate development use cases, and the complexity of managing configuration across a large SaaS platform creates persistent risk. A security assessment that evaluates API surface at a point in time does not catch configuration changes made after the assessment. Continuous API security testing and runtime controls that flag endpoints where authentication is explicitly disabled are increasingly necessary as enterprise platforms grow their API footprints.
This is particularly relevant for organisations that have built integrations and workflows on top of ServiceNow, since customisation often involves creating new endpoints or modifying the behaviour of existing ones. Custom development that inherits insecure defaults – or that disables authentication for convenience during development and is never hardened before deployment – is one of the more common paths to this class of vulnerability.
What ServiceNow Users Should Do
Organisations running ServiceNow should take the following steps.
Review instance logs for requests to /api/now/related_list_edit from 2 to 5 June 2026, and specifically for requests from 51.159.98.241. If those requests returned data, identify what was accessed and assess whether it falls within any notification obligation under GDPR or sector-specific regulation.
Verify that the 5 June patch has been applied to your instance. Customers on ServiceNow’s managed cloud should have received the update automatically, but confirming applied patch versions in the instance upgrade history is a routine step worth completing.
Conduct an audit of all custom or third-party API endpoints in your ServiceNow instance to identify any configured with requires_authentication=false. This flag should not exist on any endpoint in a production environment except where there is a documented and reviewed justification.
Review your API security testing practice more broadly. Static configuration review and periodic penetration testing are not sufficient for platforms where configuration changes continuously. Continuous monitoring of API authentication posture, using tooling that alerts when an endpoint’s authentication requirement changes, provides ongoing assurance that point-in-time assessments cannot.
European organisations covered by NIS2 should consider whether the unauthenticated access window constitutes a security incident for reporting purposes under their applicable national implementing legislation, particularly if the accessed data includes personal data subject to GDPR or operationally sensitive information about critical systems.
If you need help assessing your exposure from the ServiceNow incident, conducting an API security audit across your enterprise SaaS stack, or building a continuous monitoring capability for API authentication posture, contact Excello Digital. We help European organisations identify and close the authentication and access control gaps that enterprise SaaS platforms consistently leave open.