Unauthenticated ServiceNow API exposure shows SaaS access control gaps

At a glance

What this is: A ServiceNow REST API weakness allowed unauthenticated access through a related-list endpoint, and Obsidian Security says the issue was actively scanned before disclosure.

Why it matters: SaaS teams need to treat exposed APIs as an access-control problem, not just a patching issue, because unauthenticated endpoints can reveal operational data and widen downstream risk across connected systems.

Context

A service application can be secure at the login layer and still expose data through an API path that bypasses normal authentication checks. That is the core governance gap in this incident: access control that assumes protected user sessions also protects machine-reachable endpoints.

For identity and SaaS security teams, the issue matters because ServiceNow often holds operational records, vendor relationships, and workflow context that attackers can use to map trust relationships and possible lateral paths. When API access is left outside the same control model as interactive access, the identity boundary becomes inconsistent.

The article’s breach pattern is not unusual for SaaS environments that grow around integrations, scripted endpoints, and privileged workflows. The starting position is common enough that the control failure deserves routine audit attention, not one-off incident response.

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. The failure is not only data exposure but also loss of confidence in the platform’s trust boundary, because hidden workflow endpoints can leak operational context and support further abuse.

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. In SaaS platforms, that information often shows who works with whom, which services are connected, and which paths are most valuable to target next. A weak endpoint can therefore become intelligence for broader compromise.

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. If reviewers cannot see current activity and business context, they may approve access that is technically valid but operationally obsolete. The better test is whether the governance model can explain why access still exists.

Q: How should security teams respond when a SaaS vendor exposes an unauthenticated API endpoint to customer data?

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.

Technical breakdown

How unauthenticated REST API exposure bypasses SaaS access controls

REST APIs often sit beside the application’s normal user interface but follow different enforcement paths. In this case, the related list endpoint was reachable without valid session credentials, which means the access decision happened at the API layer rather than at the login layer. That distinction matters because many SaaS teams assume that if the tenant is protected, every route into the platform is protected. When an endpoint accepts requests without authentication, it can return data regardless of table-level protections or user-centric session assumptions.

Practical implication: audit externally reachable SaaS API paths separately from interactive login controls and treat unauthenticated exposure as a distinct access-control failure.

Why ACLs and endpoint configuration must align

Access control lists and endpoint authentication are complementary, not interchangeable. An ACL can restrict record access after a request reaches the application, but it cannot compensate for an endpoint that is published with requires_authentication set to false. That is why the article frames this as an access-control layer issue rather than a table-permission issue. The control plane has to enforce identity before data retrieval begins, especially where scripted REST APIs or custom operations exist. Otherwise, the endpoint itself becomes the vulnerability, even if downstream authorization looks sound.

Practical implication: review ACLs together with endpoint authentication settings, because record-level restrictions do not fix publicly reachable API operations.

How scanning campaigns turn weak API paths into operational intelligence

Automated scanning against known instance URLs can quickly identify which tenants expose the vulnerable path and which return data. The Mozilla-BugBounty user agent suggests an attempt to blend in with legitimate research traffic, which can delay detection if teams rely on superficial indicators. Once a scanner can query the endpoint, even partial responses may reveal process names, support data, vendor relationships, and integration context. That information is useful for broader SaaS intrusion planning, because it helps an attacker understand which workflows matter and which connected systems are worth targeting next.

Practical implication: monitor API activity patterns and user-agent anomalies together, then correlate them with tenant-specific exposure to separate harmless noise from active reconnaissance.

Threat narrative

Attacker objective: The likely objective was to collect exposed tenant data and operational intelligence from ServiceNow instances without authenticating.

1. Entry occurred through an unauthenticated ServiceNow REST API endpoint that was reachable without valid session credentials.
2. Credential checks were bypassed at the API layer, allowing automated requests to query customer instances through the related list endpoint.
3. The scanner used a Mozilla-BugBounty user agent and known instance URLs to reduce suspicion while harvesting returned data across multiple organisations.
4. The impact was exposure of customer data and operational context that could inform broader SaaS attack planning.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Unauthenticated endpoint exposure creates hidden blast radius across identity-adjacent workflows. ServiceNow often supports HR, IT, vendor, and access workflows, so exposed data can reveal how identity and operational processes connect. That makes the issue relevant to IAM, PAM, and SaaS governance teams even when no password or token is stolen. The lesson is that workflow metadata can be as operationally valuable as payload data, especially when it maps who can influence what.

API authentication drift is the named failure mode this incident exposes. The control assumption that “the tenant is protected, therefore the API is protected” breaks as soon as scripted endpoints or custom operations diverge from standard access patterns. This is the kind of drift that continuous posture monitoring is meant to surface, because static review often misses endpoint-specific exposure. Practitioners should focus on where access rules and runtime exposure no longer match.

Continuous SaaS monitoring is now a core control, not an optional detection layer. The article’s timeline shows why vendor disclosure cannot be the first signal you rely on. When a public scan can hit an exposed API before broad disclosure, the relevant control is ongoing verification of tenant configuration, not periodic trust in vendor-managed boundaries. Security teams should fold exposed API checks into their SaaS governance baseline.

From our research library:

• 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.
• Read next: Agentic AI Security Guide

What this signals

API authentication drift: SaaS teams need a name for the control gap where externally reachable operations bypass the authentication posture that leaders think is already in place. The practical issue is not just exposure, but configuration drift between the intended access model and the runtime endpoint surface. That gap belongs in continuous SaaS governance, not periodic exception handling.

A scanner that can hit a public endpoint before broad disclosure proves why tenant logs and posture data must be reviewed together. Without that correlation, teams see either harmless noise or isolated exposure, but not the operational pattern that shows the control has already failed.

Obsidian Security’s analysis shows that in SaaS environments, the deciding factor is often whether API activity is monitored at the same level as user access. When API paths can be queried anonymously, identity governance has to extend to machine-reachable operations as well as human logins.

For practitioners

• 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.
• Separate endpoint exposure reviews from record-permission reviews Review access on the API layer and the object layer as two distinct controls so an exposed route cannot hide behind otherwise correct table ACLs.
• Add continuous SaaS posture checks for unauthenticated access Build recurring validation for publicly accessible scripted REST APIs and other externally reachable SaaS operations so exposure is found before disclosure.

Key takeaways

• The incident exposes a common SaaS control gap: an API path can remain reachable even when the application’s normal login flow is protected.
• The scanning campaign shows that attackers or researchers can quickly turn exposed endpoints into usable intelligence about tenant data and workflow structure.
• Continuous checks for API authentication drift are the control that matters most, because the exposure exists at the endpoint boundary rather than in the user interface.

Key terms

• API Authorization Drift: API authorization drift is the gap between the permission model a team believes is deployed and the permissions the live API actually enforces. It usually appears after releases, gateway changes, or integration updates, when access decisions have not been retested against current behavior.
• Scripted REST API: An application endpoint that executes server-side logic over REST rather than serving only static data. In SaaS platforms, these endpoints often carry workflow or record-access functions, so misconfigured authentication can create direct data exposure.
• Access Control Layer: An access control layer is the policy and enforcement plane that determines who or what can perform an action and under what conditions. In crypto systems, it governs signing, delegation, and transaction approval, and it becomes most valuable when paired with monitoring, revocation, and governance rules.
• SaaS posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.