A cloud integration is only as secure as every authorization decision behind it. Research published by Binary Security describes five Azure cross-tenant vulnerabilities in Microsoft Azure API Connections that reportedly allowed an authenticated customer to cross tenant boundaries and reach resources connected by another customer. The proof-of-concept cases involved sensitive connector capabilities, including access associated with Azure Key Vault, Azure SQL, and external business applications.
The findings are significant because API Connections often sit between workflows and valuable data. They may hold OAuth grants, connection strings, access tokens, managed-identity associations, or runtime URLs that function like bearer credentials. According to the researcher, authorization weaknesses in Azure’s managed connector infrastructure made those capabilities accessible across customer boundaries. That does not establish widespread exploitation or a mass breach: the public evidence concerns controlled proof-of-concept testing, and Microsoft reportedly corrected the vulnerable server-side behavior.
What Azure API Connections do
Azure API Connections are managed Azure resources used to connect services such as Azure Logic Apps to other systems. Instead of building authentication and protocol handling into every workflow, an administrator creates a connection for a supported connector. Logic Apps can then call that connector to read a secret, query a database, send a message, or interact with a software-as-a-service platform.
A connection has a control-plane representation in Azure Resource Manager and a runtime path through Microsoft’s connector infrastructure. Depending on the connector, authentication may rely on a managed identity, OAuth consent, an API key, a database credential, or another secret. Microsoft documents the broader connector model in its Azure connectors overview.
This architecture creates an important security distinction. A user can be authenticated to Azure—meaning Microsoft knows which identity is making a request—without being authorized to access a particular connection. Authorization must confirm that the caller has permission for the subscription, resource group, tenant, connection, and requested operation. A missing ownership check at any layer can become an API authorization vulnerability.
What the researcher reported
The central source is Binary Security’s investigation, “Azure’s Weakest Link – Five Full Cross-Tenant Compromises”. The report presents five cases in which requests originating from one Azure customer context were reportedly accepted against connection-related resources belonging to another context.
The headings below are explanatory descriptions of the reported impact, not newly assigned vulnerability names. Readers should consult the original disclosure for the precise request formats, response evidence, affected endpoints, and Microsoft correspondence. Reproducing operational exploit payloads is unnecessary for understanding the security failure.
1. Crossing the API Connection ownership boundary
The foundational finding was that possession of a valid Azure identity did not always lead to a correct ownership decision for the referenced API Connection. The proof of concept reportedly used an attacker-controlled Azure context while supplying identifiers associated with another customer’s connection. The service accepted a cross-tenant combination that should have been rejected.
The prerequisite was not anonymous internet access: the attacker needed an authenticated Azure principal and the ability to interact with the affected connection API. The researcher also needed sufficient information to reference a target connection. The report should not be interpreted as proof that every connection identifier was publicly discoverable or that arbitrary tenants could be searched without constraints.
2. Obtaining connection runtime capability
A second demonstrated path concerned material used to invoke a connection at runtime. Runtime URLs, keys, or equivalent connector artifacts can act as capabilities: anyone able to use them may be treated as the connection, subject to the connector’s permissions. The reported Azure API Connections vulnerability allowed the proof of concept to move beyond reading harmless metadata and obtain a usable connection capability across the tenant boundary.
This distinction matters. An API response does not have to reveal a human-readable password to expose authentication material. A signed URL or token-bearing endpoint can provide equivalent access. The demonstrated impact was access through the connection; it should not automatically be described as extraction of every underlying password, OAuth refresh token, or managed-identity credential.
3. Reaching resources through an Azure Key Vault connection
The Key Vault scenario showed why connector authorization inherits the sensitivity of the connected service. According to the research, the cross-tenant weakness could be used against an API Connection linked to Azure Key Vault. The resulting access was limited by whatever data-plane permissions the connection’s identity or credential already possessed.
The attacker did not need independent Key Vault permission if the vulnerable connector path successfully acted with the connection’s authority. However, the scenario required a target connection configured for Key Vault and usable authorization to the relevant vault. A connection with no secret-reading rights would not magically gain them. The demonstrated case supports unauthorized access within the connector’s existing scope, while later compromise using exposed application secrets is a plausible downstream consequence rather than proof that every linked system was breached.
4. Accessing data through an Azure SQL connection
The SQL proof of concept applied the same isolation problem to a database connection. An Azure SQL connector can contain or represent the authority required to execute database operations. If a cross-tenant caller can invoke it, the effective impact depends on the SQL login, Microsoft Entra identity, allowed operations, firewall configuration, and database permissions associated with that connection.
The demonstrated issue was therefore not a universal bypass of Azure SQL security. It was unauthorized use of a connection that already had database access. A read-only identity would constrain the result; a highly privileged identity could create much greater exposure. This is why Azure SQL security reviews must include middleware identities and connectors, not only direct database users.
5. Using connections to external business applications
The fifth reported compromise extended the concern beyond Microsoft-hosted data stores. API Connections can maintain OAuth grants or other authorization for third-party business applications. The research demonstrated that the tenant-isolation failure could expose the capability represented by such a connection, allowing actions accepted by the external service under the connected account’s permissions.
The prerequisite was an existing external-service connection with valid authorization. The proof of concept did not establish that all third-party connectors, all OAuth applications, or all customer accounts were affected. Nor does it mean Microsoft necessarily returned a reusable OAuth refresh token. The defensible conclusion is narrower: the affected path could let another tenant use a connected application’s delegated capability in the demonstrated configuration.
- An attacker authenticates with a principal in a tenant they control.
- The attacker submits a request through an affected API Connection management or runtime path while referencing another tenant’s connection.
- The vulnerable service authenticates the caller but fails to enforce the required tenant or resource-ownership relationship.
- The service returns or accepts a connector capability that should be restricted to the owning customer.
- The attacker invokes the connected service with the connection’s existing authority.
Only the steps demonstrated in the controlled research should be treated as confirmed proof-of-concept impact. Secret theft from downstream systems, lateral movement, persistence, and compromise of additional applications are credible risks when a powerful connector is exposed, but they depend on the permissions and data available in each environment.
Disclosure, Microsoft response, and remediation status
Researcher finding: Binary Security reported five cross-tenant cases to Microsoft and published the technical investigation in October 2026. The disclosure describes them as related failures in authorization and tenant isolation within Azure API Connections.
Microsoft response: The research reports that Microsoft addressed the vulnerable behavior through service-side changes. No customer-deployed software patch is involved in a managed Azure control plane. At publication, the report did not identify public CVE assignments for the five cases. The absence of CVEs is not unusual for cloud-service flaws corrected directly by the provider.
Confirmed scope: The evidence applies to the endpoints, regions, connector types, and configurations tested by the researcher before remediation. It does not prove that every Azure region, Logic App, API Connection, Key Vault, SQL database, or external application was exposed. Administrators should use the source’s affected-scope details and any current Microsoft tenant communications when evaluating their own environment.
Unresolved questions: Public proof-of-concept evidence does not establish how often the vulnerable operations were attempted against real customers, whether exploitation occurred outside testing, or whether every potentially affected tenant can reconstruct historical access from retained logs. There was no confirmed public evidence of mass exploitation in the cited material. Organizations receiving a direct Microsoft notice should follow that notice over generalized guidance.
Defensive checklist for Azure administrators
- Inventory API Connections: Enumerate Microsoft.Web/connections resources across subscriptions and map each one to its Logic Apps workflows and connected service.
- Remove abandoned connections: Delete unused connectors, stale OAuth grants, obsolete test workflows, and connections belonging to retired applications.
- Review effective permissions: Check managed identities, service principals, SQL users, Key Vault roles, access policies, and third-party delegated scopes. Reduce them to the minimum required operations.
- Audit Key Vault activity: Examine data-plane logs for unusual secret, key, or certificate access, including unexpected identities, addresses, times, and operation patterns.
- Review Azure SQL logs: Investigate unfamiliar sessions, queries, authentication events, data exports, schema changes, and activity associated with connector identities.
- Inspect Logic Apps history: Review workflow runs and connector calls for executions that do not correspond to approved triggers or business processes.
- Monitor cross-tenant indicators: Alert on unexpected tenant IDs, service principals, consent events, connection changes, and resource-management operations.
- Rotate conditionally: Rotate API keys, SQL passwords, OAuth grants, and other credentials when logs or Microsoft guidance indicate possible exposure. Rotation without investigation can destroy useful evidence.
- Preserve evidence: Retain relevant Azure Activity Logs, diagnostic logs, Key Vault logs, SQL audit records, Logic Apps histories, and identity sign-in data.
- Follow current Microsoft guidance: Check Azure Service Health, direct tenant notifications, and official security communications for scope or remediation instructions specific to the subscription.
The broader cloud-security lesson
Cloud tenant isolation cannot stop at a subscription’s front door. It must be enforced when a caller supplies a connection ID, when a control-plane request produces a runtime capability, and when a connector invokes a downstream service. Every transition must bind the caller, tenant, resource owner, credential, and requested operation together.
The findings also illustrate why least privilege remains essential even when the provider fixes the underlying Azure security flaws. A connector with permission to read every vault secret or administer an entire database creates a much larger blast radius than one restricted to a specific secret or read-only schema. Strong cloud tenant isolation and constrained connector identities are complementary controls.
Frequently asked questions
Were all Azure API Connections vulnerable?
No. The research demonstrated specific cross-tenant failures under tested conditions. It does not support claiming that every connector, region, tenant, or Logic Apps deployment was exploitable. Scope should be assessed against the original report and Microsoft’s current communications.
Did the researcher prove that customer secrets were stolen?
The proof of concept reportedly demonstrated unauthorized cross-tenant connector access, including sensitive connected-service scenarios. That establishes potential access in the tested environment, not widespread theft from production customers or a mass data breach.
Authentication establishes who made the request. Authorization determines whether that identity may perform the requested action on that specific tenant’s resource. The reported weakness involved authenticated requests that were not adequately restricted by ownership and tenant checks.
Should administrators rotate every connector credential?
Not automatically. First inventory connections, review available logs, preserve evidence, and follow any Microsoft notification. Rotate credentials when exposure is confirmed, reasonably suspected, or explicitly advised, prioritizing highly privileged Key Vault, SQL, and third-party connections.
Do server-side fixes eliminate all risk?
They should close the vulnerable provider behavior described by the researcher, but they cannot reverse access that may already have occurred. Customers remain responsible for investigating suspicious activity, limiting connector permissions, removing unused connections, and responding to provider guidance.
