Immediate action required. A vulnerability in ServiceNow's REST API allowed unauthenticated users to access data through the related list endpoint (/api/now/related_list_edit/create). The bug has since been patched — but not before a scanning campaign, identifiable by the Mozilla-BugBounty user agent and originating from IP 51.159.98.241, successfully queried customer instances across multiple organizations, with confirmed impact in the financial services sector.
If your organization runs ServiceNow and has not yet audited your instance logs, that audit needs to happen today.
The attacker exploited a flaw in ServiceNow's access control layer, bypassing authentication on REST API calls. The endpoint /api/now/related_list_edit/create was reachable without valid session credentials. The attacker sent automated requests across known ServiceNow instance URLs, harvesting whatever data the endpoint returned. The Mozilla-BugBounty user agent string was used to reduce suspicion — mimicking legitimate bug bounty research activity to avoid triggering immediate incident response.
Attribution is unclear. The Mozilla-BugBounty string is a known evasion technique — either a bug bounty researcher who exceeded scope, or a threat actor deliberately mimicking one to fly under the radar. The IP 51.159.98.241 should be treated as malicious and blocked across your environment immediately.
ServiceNow sits at the center of enterprise IT operations — it holds ticket data, HR records, vendor contracts, and, in many organizations, identity and access management workflows. An unauthenticated read on any of these endpoints isn’t a minor misconfiguration. It can expose the operational context attackers need to understand who a company works with, how internal processes run, and where lateral paths may exist across customers, vendors, and service providers.
That’s why this matters beyond a single ServiceNow vulnerability. Threat actors are increasingly targeting SaaS applications that support IT, support, and customer operations because these systems can become launch points for broader SaaS supply chain attacks. The reported Salesloft-Drift and Gainsight incidents showed how access into one trusted SaaS workflow can expose sensitive customer data and create downstream risk across connected environments.
Obsidian’s view: visibility into what your SaaS apps are doing at the API level, even when you’re not looking, is the only reliable defense. SaaS security can’t stop at user logins or vendor trust. It has to continuously monitor access, integrations, tokens, configuration drift, and API activity across the applications where enterprise operations actually happen.
Immediate actions:
51.159.98.241 and user agent Mozilla-BugBountyLong-term:
This is not a hypothetical. Obsidian caught this.
On June 4, 2026 — one day before ServiceNow patched hosted customer instances and five days before public disclosure — Obsidian already had product protections in place for this class of access violation, including the posture control “Publicly accessible scripted REST APIs.” That control detects unauthenticated scripted REST APIs, including configurations where requires_authentication = false on /api/now/related_list_edit/create, the endpoint used in this attack.
Combined with drift detections, activity logs, and workflow-driven remediation, Obsidian helped customers identify and address risky exposure before public disclosure — reinforcing that this wasn’t just a vulnerability-specific finding, but part of a broader access governance use case across SaaS applications.
Obsidian Security was built to close access violations in SaaS
This incident is a clear example of the access violations Obsidian was built to find and help customers close unauthenticated access paths inside business-critical SaaS applications. In ServiceNow, that includes scripted REST APIs that don’t require authentication — a configuration that can expose sensitive data, allow unauthorized record creation or modification, and bypass ACLs even when the underlying tables are protected.
Obsidian continuously monitors for this class of exposure through posture controls like “Publicly accessible scripted REST APIs.” In this case, the control identified the exact endpoint exploited in the incident — not as a one-off response to the breach, but as part of continuous posture monitoring across SaaS environments.
How Obsidian gave customers environment-specific answers
Obsidian helped customers understand how this ServiceNow issue applied to their own environments, not just the broader market. Through continuous posture monitoring, customers could identify whether their configurations matched the risky access pattern associated with this incident. This included scripted REST APIs where requires_authentication = false, and prioritize remediation based on their actual exposure.
Obsidian also supported activity-level validation by checking connected tenant activity against published indicators, including queries such as ip:51.159.98.241 OR ua:"Mozilla-BugBounty". Together, these signals gave customers a clearer answer to the questions that matter in a SaaS incident: whether the risky access path existed, whether known indicators appeared in monitored activity, and what needed attention next.
That’s the difference between receiving a generic vendor advisory and having environment-specific access governance. Obsidian helps customers move from broad incident awareness to specific, actionable decisions across the SaaS applications where critical business operations happen.
Remediation steps, direct from the rule
For any environment where this endpoint was flagged:
sys_ws_operation.list in ServiceNowHosted tenants patched by ServiceNow on June 5 are already covered. On-premise or partially hosted environments should verify independently.
What comes next
The internal team has flagged a product enhancement to add API URL and operation URI as rule definition options — so this posture control becomes even more precise for future incidents targeting specific endpoints. That work is tracked and in progress.
ServiceNow publicly disclosed this incident on June 9. By June 4, Obsidian had already given customers visibility into whether their environments matched the risky access pattern associated with this issue.
That is the value of continuous SaaS governance over reactive advisory response. Vendor disclosures are important, but they often arrive after a risky access path already exists inside the environment. Continuous posture monitoring gives security teams earlier visibility into exposed configurations, the context to understand business impact, and the workflows to prioritize remediation before a SaaS issue becomes a broader operational risk.
The broader pattern here is consistent: Okta's support system breach in 2023, CircleCI's pipeline compromise, every cascading SaaS supply chain failure in the last three years — in each case, the organizations with the fastest and most confident response were the ones who already had eyes on their environment, not the ones starting their investigation from a vendor email.
Two things make that possible at scale: posture controls that run continuously against specific API configurations (not just broad network monitoring), and activity search that can run IOC queries against connected SaaS tenant logs within minutes of an indicator being published.
Obsidian does both. The posture control that caught this is live. The activity search ran the same day the IOCs were released. If you are an Obsidian customer and have ServiceNow connected, your CSM already has your environment-specific findings.
In the wake of the Salesloft breach, we’re offering a free risk assessment of your Salesforce environment to help identify potential exposure. Click here to request yours.
Take a breather! In under 6 minutes, our demo breaks down the risks AI agents bring to your SaaS environment and how you can get ahead of them.
We're offering a free AI agent risk assessment—check it out.
The biggest SaaS breach of 2025 started with a compromised third-party app. Attackers then exploited Salesloft-Drift OAuth tokens, which granted them access to hundreds of downstream environments. Obsidian researchers found the blast radius of this supply chain attack was 10x greater than previous incidents, where attackers infiltrated Salesforce directly.
Start in minutes and secure your critical SaaS applications with continuous monitoring and data-driven insights.
