Notifications
Clear all
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.
NHIMG editorial — based on content published by Obsidian Security covering the ServiceNow unauthenticated data exposure: Unauthenticated Data Exposure in ServiceNow: What the Mozilla-BugBounty Scan Means for Your Organization
By the numbers:
- On June 4, 2026, Obsidian had already identified the risky access pattern before ServiceNow publicly disclosed the issue on June 9, 2026.
- The Salesloft-Drift breach affected more than 700 downstream organisations through compromised OAuth access.
Questions worth separating out
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 unmanaged SaaS apps create identity governance risk?
A: Unmanaged SaaS apps create risk because they sit outside central visibility, which means IT cannot consistently enforce SSO, review entitlements, or offboard access.
Q: How do security teams know if SaaS identity controls are actually working?
A: Look for evidence that lower-assurance identities are fully segregated from sensitive backend paths, not just authenticated differently.
Practitioner guidance
- Audit every externally reachable ServiceNow endpoint Inventory scripted REST APIs, related-list endpoints, and other non-UI paths.
- Search logs for the published indicators immediately Review instance telemetry for IP 51.159.98.241 and the Mozilla-BugBounty user agent string, then correlate those requests with high-value tables, external exposure, and any anomalous read volume.
- Revalidate ACLs at the endpoint layer Do not assume table-level protections cover every API route.
What's in the full article
Obsidian Security's full post covers the operational detail this post intentionally leaves for the source:
- Exact instance-log searches for IP 51.159.98.241 and the Mozilla-BugBounty user agent
- Step-by-step remediation instructions for the Requires authentication setting on the affected ServiceNow path
- Posture-control logic for detecting publicly accessible scripted REST APIs in SaaS environments
- Environment-specific workflow details for prioritising exposure checks across hosted and on-premise deployments
👉 Read Obsidian Security's analysis of the ServiceNow unauthenticated data exposure →
ServiceNow API exposure: what SaaS teams need to fix now?
Explore further
14/08/2026 6:44 pm
Unauthenticated SaaS API exposure is a governance failure, not just a vulnerability. The core problem is that business-critical data remained reachable through an endpoint that did not require authentication. That breaks the assumption that application-layer controls will enforce the same trust boundary everywhere. For IAM and SaaS governance teams, the lesson is that every externally exposed workflow path needs identity-grade control review, not only user-facing login flows.
A question worth separating out:
Q: Who is accountable when third-party SaaS mishandles company data?
A: The customer remains accountable for how its data is selected, shared, retained, and governed, even when a third party processes it. Vendor contracts may shift operational tasks, but they do not erase the organisation's duty to understand residency, backup handling, subcontractors, and breach obligations. Accountability follows the data owner, not just the service provider.
👉 Read our full editorial: Unauthenticated ServiceNow API exposure shows SaaS access control gaps
