A recent security incident involving ServiceNow highlights a significant risk to enterprises relying on cloud workflow and IT service management platforms. ServiceNow disclosed that a software flaw affecting certain customer instances allowed unauthenticated access to data via a vulnerable API endpoint. This condition effectively bypassed authentication controls, enabling external parties to query stored data without valid credentials.
The vulnerability appears to have been tied to an API endpoint (reportedly /api/now/related_list_edit/create) that was improperly configured with authentication disabled. As a result, any party aware of the endpoint could attempt to retrieve data from affected instances. ServiceNow remediated the issue on June 5, 2026, by enforcing authentication requirements on the endpoint. However, the company acknowledged that anomalous activity had already been observed prior to the fix, with some customer instance data successfully queried.
Although ServiceNow stated that the observed activity was associated with security researchers and bug bounty submissions rather than confirmed malicious actors, this distinction does not eliminate the security impact. From a defensive and risk management standpoint, the outcome remains the same: data exposure occurred through an unauthenticated pathway. Furthermore, the company did not publicly specify the full scope of affected customers, nor provide detailed visibility into what data types were accessed in each case.
This vulnerability is particularly concerning due to the nature of data typically stored in ServiceNow environments. Enterprise instances often contain sensitive operational and security-related information, including IT service tickets, employee records, incident response data, internal documentation, and potentially embedded credentials or API tokens shared during troubleshooting workflows. Threat actors frequently target support systems because they serve as aggregation points for high-value contextual information that can be leveraged for follow-on attacks such as privilege escalation, lateral movement, or supply chain compromise.
The timeline of the issue introduces additional concern from a threat intelligence perspective. ServiceNow reportedly received a confidential bug bounty submission describing a similar issue in April 2026 but did not deploy a security update until early June, after activity targeting customer instances had already begun. This gap between discovery and remediation increases the likelihood that knowledge of the flaw may have spread beyond trusted researchers, whether through independent discovery or inadvertent disclosure.
Another notable aspect is the potential variability in exposure. While ServiceNow indicated that the issue primarily affected instances on the “Australia” platform release or those with specific configuration changes, community reports suggest broader impact across other versions. This raises the possibility that misconfigurations or inherited settings across environments could have extended the exposure surface beyond initially understood boundaries.
Indicators of compromise associated with this activity include requests originating from the IP address 51.159.98.241 and access attempts targeting the aforementioned API endpoint. While attribution remains unclear, defenders should treat any evidence of unauthenticated API access as suspicious regardless of source.
From a threat landscape perspective, this incident reinforces several important trends. Cloud SaaS platforms continue to represent high-value centralized targets where a single vulnerability can expose multiple organisations simultaneously. API misconfigurations and access control failures remain a leading cause of data exposure in cloud environments. Additionally, reliance on vendor-managed security does not eliminate the need for customer-side visibility, logging, and validation controls.
Organisations using ServiceNow should immediately perform retrospective log analysis covering at least early April through mid-June 2026, with particular attention to unauthenticated or anomalous API requests. Any access attempts involving the relevant endpoint or originating from known indicators such as 51.159.98.241 should be investigated as potential data exposure events. Even if activity is attributed to researchers, the data accessed must be considered potentially compromised.
You should review all records that may have been exposed through ServiceNow workflows, especially support tickets, incident records, and knowledge base entries. Any instance where credentials, API keys, authentication tokens, or sensitive configuration details were shared should trigger a mandatory rotation process. This includes passwords, service account keys, OAuth tokens, and any embedded secrets within attachments or notes.
Ensure that API access logging is fully enabled and retained for an adequate duration going forward. If logging was previously disabled or insufficient, this incident should be treated as a gap in detection capability that needs remediation. Consider integrating ServiceNow logs into a centralized SIEM or XDR platform to allow for correlation with other security signals.
It is critical to validate that all ServiceNow instances are running the patched configuration and that no customisations or legacy settings override authentication requirements on API endpoints. Configuration drift should be assessed, particularly in older instances or environments with heavy customization.
If you are worried about any of the threats outlined in this bulletin or need help in determining what steps you should take to protect yourself from the most material threats facing your organisation, please contact your account manager, or alternatively get in touch to find out how you can protect your organisation.