Unauthenticated ServiceNow API exposure shows SaaS access control gaps

At a glance

What this is: A ServiceNow REST API flaw exposed data through an unauthenticated endpoint, demonstrating how SaaS access control failures can create immediate risk across customer instances.

Why it matters: It matters because IAM, SaaS security, and identity teams need visibility into API-level access paths, unauthenticated exposure, and the operational workflows that often sit behind business-critical platforms.

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.

👉 Read Obsidian Security's analysis of the ServiceNow unauthenticated data exposure

Context

ServiceNow exposure becomes a governance problem when an API endpoint can return data without authentication. In this case, the issue was not a password reset failure or a user account compromise, but a control break at the application layer that bypassed normal access checks and widened the attack surface inside SaaS operations.

For IAM and SaaS security teams, the identity question is whether privileged workflows, integrations, and service-facing endpoints are being governed with the same discipline as human sign-in flows. This type of exposure is especially important where ServiceNow supports IT, HR, vendor, and access workflows, because the data reveals operating context that attackers can use to plan broader abuse.

The starting position here is unfortunately typical of modern SaaS risk: a single externally reachable API path can expose far more than the application owner expects.

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 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. The longer an app remains invisible, the more likely it is to accumulate stale permissions, duplicate functions, and unmanaged data exposure.

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. A control is working when a breach at one trust tier cannot reach another tenant's data, administrative functions, or session context. If lateral reach remains possible, the control is cosmetic.

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.

Technical breakdown

Unauthenticated REST API exposure in SaaS platforms

SaaS applications often expose REST endpoints for scripted operations, workflow integration, and data retrieval. If an endpoint does not enforce authentication, the application may still honour the request and return records even when the caller has no valid session. That is an access control failure, not merely a configuration nuisance, because it can bypass ACL design higher in the stack. In this case, the risky path was a related list endpoint that responded to automated requests against known ServiceNow instance URLs. Practical implication: security teams must inventory externally reachable API paths and verify authentication enforcement at the endpoint level, not just at the UI or tenant boundary.

Practical implication: validate authentication on every externally reachable API path, including scripted and related-list endpoints.

Why user-agent spoofing matters in SaaS incident detection

Attackers often use plausible user-agent strings to blend into routine scanning or bug bounty traffic. A user-agent does not prove legitimacy, but it can delay triage when defenders treat it as a trust signal rather than just one telemetry field. In this incident, the Mozilla-BugBounty string appears to have been used to reduce suspicion while requests were sent across multiple instances. That tactic works because many detection programmes still over-weight source reputation and under-weight request behaviour. Practical implication: detections should combine user-agent context with request volume, target diversity, authentication state, and endpoint sensitivity.

Practical implication: correlate user-agent with volume, endpoint sensitivity, and authentication state before discounting suspicious activity.

SaaS API governance is an identity problem as much as a cloud problem

When SaaS platforms expose internal workflows through APIs, identity governance extends beyond users to service accounts, integrations, tokens, and delegated permissions. The control gap is not only who can sign in, but which machine-facing paths can read, write, or modify records without meaningful verification. That is why SaaS API governance belongs alongside IAM and NHI oversight. If the platform permits unauthenticated access or over-broad API exposure, the rest of the identity stack cannot compensate. Practical implication: treat SaaS API permissions and authentication rules as part of the identity control plane, not as a separate app-owner concern.

Practical implication: bring SaaS API permissions and authentication rules into IAM and NHI governance reviews.

Threat narrative

Attacker objective: The attacker’s objective was to quietly collect operational and contextual data from ServiceNow instances without authenticating, likely to support broader reconnaissance or downstream abuse.

1. Entry occurred when the attacker sent automated requests to publicly reachable ServiceNow instance URLs and targeted the exposed related-list REST API endpoint without valid authentication.
2. Credential access was unnecessary because the flaw bypassed session validation, allowing unauthenticated data retrieval through a path that should have been protected by access controls.
3. Impact came from harvesting whatever records the endpoint returned, including data from customer instances across multiple organisations, which could support follow-on SaaS supply chain reconnaissance.

NHI Mgmt Group analysis

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.

API-level access control is now part of the identity perimeter. ServiceNow often sits inside IT, HR, vendor, and access workflows, which means exposed API paths can reveal operating context even when no credentials are stolen. That makes the boundary between application security and identity governance increasingly artificial. Teams that still treat service APIs as an app-owner detail will miss the real risk, which is unauthenticated reach into operational records and workflow metadata.

User-agent mimicry creates a detection trust gap. The use of a Mozilla-BugBounty string shows how easy it is to make malicious traffic look like legitimate research. That matters because many SOCs still triage based on reputation first and behaviour second. The control gap is not lack of logs, but lack of behavioural confidence in telemetry that appears familiar. Security teams should assume trust-markers are cheap to fake and design detection around request patterns instead.

SaaS supply chain exposure now starts with the management plane. ServiceNow, like other high-trust enterprise SaaS systems, can become an entry point for broader downstream risk when API access is weakly governed. This is the same structural pattern seen in recent SaaS compromise cases: trusted workflow access becomes a reconnaissance source, then a staging point for lateral abuse. The practical conclusion is that SaaS governance must cover integrated workflows, not only direct user sessions.

Continuous access monitoring is the named concept this incident reinforces. The relevant failure mode is not static misconfiguration alone, but exposure that persists until someone actively checks the environment. Continuous monitoring of externally reachable endpoints, authentication state, and request behaviour is what closes that gap. In identity terms, this is the difference between a control that exists on paper and a control that actually governs runtime access.

What this signals

SaaS API exposure is becoming an identity operations problem. Teams that separate application hardening from IAM governance will miss the control gap exposed here, because unauthenticated workflow endpoints function like unmanaged access paths. That means access reviews, logging, and endpoint inventory need to cover machine-facing routes as well as human sign-ins.

The trust boundary has moved from the login page to the API layer. In practice, that means runtime checks for authentication state, request behaviour, and sensitive endpoint exposure matter more than broad policy statements. Where SaaS platforms support access, HR, and IT workflows, API governance should be reviewed alongside OWASP NHI Top 10 style controls for non-human access paths.

Continuous exposure detection is the control that changes outcomes. The difference between a contained advisory and an operational incident is often whether teams can see risky configuration drift before public disclosure. If your programme cannot answer which SaaS endpoints are externally reachable today, then you do not yet have enough governance over the identity surfaces that matter most.

For practitioners

• Audit every externally reachable ServiceNow endpoint Inventory scripted REST APIs, related-list endpoints, and other non-UI paths. Confirm which endpoints require authentication, which can be reached anonymously, and which return sensitive records even when the caller has no valid session.
• 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. Test the exact endpoint path used in production and confirm authentication, role checks, and response filtering behave as expected under direct request.
• Bring SaaS API governance into IAM reviews Treat service-facing APIs, integrations, and delegated workflow access as identity-controlled surfaces. Include them in access recertification, exception handling, and monitoring for unauthenticated or over-broad exposure.

Key takeaways

• Unauthenticated SaaS APIs turn ordinary configuration drift into immediate data exposure risk.
• The ServiceNow case shows that user-facing IAM controls do not compensate for weak endpoint-level authentication.
• Security teams need continuous API inventory, behavioural detection, and identity governance across SaaS workflows.

Key terms

• Unauthenticated Api Path: A public endpoint that accepts requests without verifying the caller first. In identity security terms, this is not just a missing login check. It is a broken trust boundary that can invalidate downstream roles, ACLs, and session controls because the system never establishes who is asking.
• Layer 7 access control: Access control that operates at the application layer by inspecting request attributes such as host, path, headers, and context. In Kubernetes, it allows security teams to express policy in terms closer to application risk than network reachability.
• User-Agent Spoofing: The practice of sending a misleading browser or client identifier to make automated traffic appear legitimate. Defenders should treat user-agent strings as weak context, because they can support but never prove benign intent.
• API Coverage: API coverage describes how much of an application’s user, entitlement, and activity data is available through programmable interfaces. In SaaS management, limited API coverage constrains automation and forces teams to use manual or hybrid controls for parts of the application estate.

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

👉 The full Obsidian Security post covers the attack path, endpoint validation steps, and remediation workflow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps security practitioners connect identity control to the broader operational surfaces their programmes depend on.