Bug Bounty Findings Revealing Cross-Tenant IAM Boundary Failures in SaaS

Bug bounty findings in SaaS keep showing the same failures in how identity and access management works across tenants. Missing tenant checks, unscoped object access, and misconfigured tokens let one customer reach another’s data or privileges. These are repeatable architectural mistakes. To fix them, the backend must enforce tenant boundaries on every request, and teams need runtime visibility into the services and AI agents that act across those boundaries.

Why cross-tenant IAM boundary failures keep appearing in bug bounty programs

Multi-tenant SaaS rests on a bargain. Customers share infrastructure, but their data and authority remain separate. That separation depends on authorization decisions made throughout the product. Bug bounty researchers test the distance between the promise and its enforcement. Cross-tenant data access and account takeover earn high severity because a failure can expose an organization that never granted the attacker access.

OWASP Top 10:2025 places Broken Access Control first and describes accessing another account by supplying its unique identifier as a failure mode. That category is broader than multi-tenancy, but it captures the essential mistake. Knowing which record to request is treated as permission to receive it. The recurring SaaS findings extend that confusion across organizational boundaries, where one missing check can turn shared infrastructure into shared access.

The four logic mistakes that account for most cross-tenant boundary breaks

Missing server-side tenant validation is the most direct failure. The backend accepts a client-supplied tenantId or organizationId without checking whether the authenticated user belongs to that tenant. Authentication succeeds. Isolation fails. The identity and API infrastructure cases below show why tenant context must be validated where access is granted, rather than accepted as a helpful suggestion from the caller.

Insecure Direct Object Reference, or IDOR, moves the same mistake into resource retrieval. An invoice, project, or campaign has an internal identifier, but the API does not consistently bind access to the requesting tenant. The identifier becomes a substitute for authorization. OWASP’s account-identifier example describes the underlying failure, while the cross-tenant variant extends it beyond users within one organization. A two-account test exposes the distinction by requesting tenant B’s resource with tenant A’s credentials.

Broken access control also occurs in shared admin and API endpoints. Infrastructure built for internal use can enter a multi-tenant product without acquiring tenant-based authorization. In Azure API Connections, a shared endpoint became a way into other tenants’ connected services. A member performing admin actions, or a removed member retaining access through a stale token, exposes a related gap between recorded authority and enforced authority.

Token misconfiguration completes the pattern. A token without tenant binding may authenticate a user without limiting the request to that user’s organization. OAuth and OIDC flaws, including redirect matching errors, state misuse, and audience confusion, can compound the problem. Small errors can combine into critical access. A misconfigured redirect that leaks an authorization code becomes more serious when that code can exchange for an admin-scoped token without PKCE. The Entra ID case shows the platform-scale version of this failure, with a service token accepted outside its originating tenant.

What the Microsoft CVE-2025-55241 and Azure API Connections cases reveal about how these mistakes scale

Dirk-jan Mollema discovered CVE-2025-55241 under Microsoft’s identity bounty program. The flaw was in the legacy Azure AD Graph API, which did not validate the originating tenant of service-to-service actor tokens issued by the Access Control Service. A token from an attacker’s own non-privileged test environment could impersonate a Global Administrator in another company’s tenant. No foothold in the target was needed. Mollema disclosed the issue on July 14, 2025, Microsoft patched it on July 17, and the CVE was formally issued on September 4.

The potential access extended to user information, group and role details, tenant settings, application permissions, device information, and BitLocker keys. MFA and Conditional Access could be bypassed, while absent API-level logging meant exploitation left no traces there. The repair was not a local adjustment. The repair took a great deal of engineering work across cases where applications had high privileges. Microsoft’s deputy CISO characterized the underlying issue as “service-to-service” architectural debt, with broad permissions that should have been scoped to least privilege. The Graph API’s general shutdown had completed on July 1, 2025, illustrating that retirement schedules do not themselves settle authorization debt.

All API Connections shared a globally shared Azure API Management instance, and an undocumented DynamicInvoke endpoint accepted custom path and method parameters. That flexibility crossed the wrong boundary. An attacker could target connected backend services across tenants, including Key Vaults, Azure SQL databases, Salesforce, and Jira, using credentials held by API Connections. Microsoft confirmed the issue within three days of the April 7 disclosure and patched it within a week.

Azure Automation exposed a third surface through CVE-2025-29827. An attacker with their own Automation account could assume another tenant’s automation identity, modify scripts, and access sensitive configuration data, credentials, and cloud resources. The route used three flaws together: a default configuration that left automation accounts open to the public and two code-level bugs. Different surfaces produced the same authorization failure. Identity tokens, shared API routing, and automation identities all became cross-tenant paths because tenant context was not enforced at the layer granting authority.

How the Stripo and ServiceNow findings show the same pattern at the application layer

No Code (@srcode) disclosed a critical cross-tenant data access flaw in Stripo Inc.’s AI Hub Campaign feature in February 2026. The finding was classified as CWE-284, Improper Access Control, and resolved through HackerOne. Its stated root cause was “a simple authorization flaw.” The feature used the platform’s data without the necessary access check. This illustrates the risk of extending an established product with AI functionality that inherits the data model but not all of its authorization rules.

On April 22, 2026, ServiceNow received a confidential bounty submission that described a similar unauthenticated-access issue. In some cases, unauthenticated users could access more of the instances than they were meant to. A security update followed on June 5, after activity targeting customer instances reportedly began days earlier. Disclosure and remediation were separate events. Because these instances commonly hold support tickets, employee records, internal documentation, asset inventories, and security incident reports, the access path had serious consequences for confidentiality.

Attribution remains contested in the security community. At least one system publicly associated with exploitation also appeared to target other SaaS tenants with similar unauthenticated-access weaknesses. That complicates the assumption that a confidential bounty report alone provides protection. Across Stripo and ServiceNow, the relevant pattern is an access path adjacent to the core authorization model that lacks a check the rest of the product depends on.

Why these bugs escape detection before researchers find them

A query can be perfectly valid and still serve the wrong customer. Standard scanners can spot known vulnerability patterns, but a query’s syntax alone cannot tell them whether it needs a tenant restriction. The missing information is the intended authorization relationship. A token without a tenant claim may also pass every test run within the tenant that issued it. The failure becomes visible only when someone asks whether the same operation works from another organization.

That question is easy to omit on peripheral surfaces. Bulk exports, background jobs, cache keys, admin dashboards, webhooks, and integration connectors receive less review than the main user-facing path, yet each can handle tenant-specific data or authority. Even when a screen is secure, its export can still be at risk. Nor does a correct endpoint establish that the background job it starts preserves the same tenant context.

Researchers need to trace data flows and understand business logic, which takes more than running a larger scan. The two-account test is deceptively modest because its value comes from knowing which boundary the request should not cross. The test must challenge permission. This is a structural detection gap. Automated checks remain useful, but they need an explicit model of tenant isolation to test it.

What backend enforcement actually requires to close these failure modes

The lesson for engineering teams is to make tenant validation unavoidable. Tenant context should be bound to the authenticated session or token at the gateway or middleware layer. The data access layer should then enforce tenant restrictions on every query. Individual endpoint authors should not own that obligation. Properly configured Row-Level Security can make unscoped queries return no cross-tenant data, closing the retrieval path that otherwise depends on each developer remembering a filter.

Token controls must preserve that context across services. JWTs need tenant_id or organization_id claims, and resource servers must validate them on every request. Presence alone is not enforcement. OAuth implementations also need PKCE, exact-match redirect validation, and audience validation to prevent credentials from being reused in unintended contexts. Service-to-service tokens require the same discipline, including validation of their originating tenant, rather than broad trust because the caller is another service.

Tests should then challenge those controls directly. A standard boundary test requests a resource from tenant B using tenant A’s credentials, with explicit coverage for exports, webhooks, admin endpoints, background jobs, and connectors. New features need authorization review before launch. Role-based and attribute-based access decisions must also include tenant membership, with server-side enforcement of Viewer, Member, Admin, and Owner permissions. When a role changes, token invalidation must remove stale authority rather than leaving a tidier interface in front of unchanged access.

Monitoring is needed to detect what prevention alone cannot catch. The Graph API logging gap shows why every API surface needs audit records, including routes where those records are harder to get. Failed attempts belong in those records too. Logs should name both the tenant making the request and the tenant that owns the resource. Real-time visibility and runtime behavioral monitoring can then flag credentials reaching across unfamiliar boundaries, while enforceable policies block access that exceeds their scope.

How AI agents are creating a new generation of cross-tenant boundary failures that existing controls do not address

AI agents complicate the assumption that an arriving credential adequately describes the work being authorized. An agent can acquire credentials at task start, retain them across many operations, and delegate to tools, sub-agents, or external services. Tenant context can drift during that chain. A prompt injection, malicious tool response, or compromised dependency can turn the agent into a confused deputy, using valid authority on behalf of a different tenant. The resource server may see an authorized call even though the task has crossed an intended boundary.

Cloud Security Alliance’s March 2026 research, “Islands of Agents: IAM Failures Across Agent Boundaries,” examines these cross-boundary delegation failures across several agent categories. Salesforce Agentforce and ServiceNow’s agentic automation operate within their vendors’ platform boundaries, but linked external systems extend the delegation chain beyond those platforms’ IAM governance. The boundary moves downstream with the work. Shared retrieval indexes and persistent memory add further places where a correct login at the chat interface does not establish isolation for everything that follows.

Database enforcement still protects the queries it governs. It does not, however, interpret why an agent selected a particular tool or whose instructions caused it to use an OAuth credential. Valid tokens do not establish valid intent. Machine-speed execution also amplifies the consequences of one confused credential across downstream calls before the session ends. The ServiceNow disclosure-to-patch gap illustrates a remediation window, while agentic execution makes the potential scale within such windows harder to contain.

The prevention model therefore needs runtime visibility into the delegation chain. Security teams need to discover which agents and services operate, monitor their tenant context at each step, and detect actions inconsistent with the authority they hold. The system must enforce these rules on tool calls and sub-agent invocations and keep an audit trail of what actually crossed a boundary. A successful login is only the beginning. Tenant isolation has to survive the work that follows.