Topic starter
14/08/2026 6:37 pm
TL;DR: A ServiceNow REST API flaw allowed unauthenticated access through the related list endpoint, and a scanning campaign using the Mozilla-BugBounty user agent successfully queried customer instances before patching, according to Obsidian Security. The incident shows that SaaS security failures often begin with exposed API paths and weak authentication assumptions, not user logins.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “Unauthenticated Data Exposure in ServiceNow: What the Mozilla-BugBounty Scan Means for Your Organization”.
Key questions
Q: What breaks when SaaS APIs are exposed without authentication?
A: When SaaS APIs are exposed without authentication, attackers can query or manipulate data without a valid session, bypassing the normal controls that protect user logins.
Q: Why do exposed REST endpoints create more risk than a normal configuration error?
A: Because they can reveal operational data, workflow context, and integration details that attackers use to map later attacks.
Q: What do security teams get wrong about access reviews?
A: Teams often treat access reviews as proof of control, when they are really only a point-in-time check.
Practitioner guidance
- Audit externally reachable ServiceNow API paths Inventory every REST endpoint that can be reached from outside the tenant and verify whether each one requires authentication before it can return data.
- Verify authentication settings on scripted operations Check resource paths such as related-list or scripted operations for requires_authentication settings and reconcile them with ACL expectations.
- Correlate tenant logs with suspicious scan indicators Search for the Mozilla-BugBounty user agent, the source IP 51.159.98.241, and repeated instance-url queries across connected SaaS logs.
Bottom line: The incident exposes a common SaaS control gap: an API path can remain reachable even when the application’s normal login flow is protected.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/08/2026 6:44 pm
SaaS API exposure is an access-governance problem, not just a vulnerability class. The failure here was not that ServiceNow existed in an enterprise stack, but that a reachable API path was allowed to sit outside the authentication boundary. That is a governance error because it creates a second, weaker identity plane inside the same platform. Practitioners should treat every externally accessible API operation as part of the access model, not as a technical afterthought.
A few things that frame the scale:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
A: Start by identifying every request path that can reach the affected instance data, then review logs for external access, unusual query patterns, and unfamiliar source IPs. Rotate any secrets that may have passed through the platform, confirm API logging is enabled, and validate which records were exposed. The key control is visibility into what sensitive data the system actually holds.
👉 Read our full editorial: Unauthenticated ServiceNow API exposure shows SaaS access control gaps