One Shared API Gateway, Five Tenant Compromises: Inside Binary Security's Azure API Connections Research

According to Norwegian security firm Binary Security, a single architectural decision—routing every Azure API Connection through a globally shared API Management instance—gave any attacker with a foothold in one tenant a path to fully compromise API Connections owned by any other tenant worldwide, gaining complete access to the backends attached to them: Key Vaults, Azure SQL databases, Salesforce, Jira, and other connector-backed services. The finding is not five unrelated bugs. It is one shared gateway design, plus repeated input-validation failures at the Azure Resource Manager layer that Microsoft had to patch five separate times.

Binary Security published the final installment of a three-part research series on October 30, 2026, at binarysecurity.no/posts/2026/10/one-root-case. (An earlier installment in the same series, cataloguing the initial exploitation path, was published October 2.) Five critical elevation-of-privilege vulnerabilities were reported to Microsoft, all arising from the same underlying design. The total bounty paid was $200,000. Microsoft confirmed and patched each vulnerability—but the patch history is itself part of the story: at least once, a fix for one variant directly re-opened a variant that had previously been closed.

The Root Architecture Problem

Azure API Connections are the credential-holding component behind Azure Logic Apps. When a Logic App needs to call an external service—Key Vault, Azure SQL, Salesforce, Slack, Jira, or any of hundreds of other connectors—it does so through an API Connection that stores the OAuth token or API key for that backend.

The critical detail is what happens next. According to Binary Security's published research, all API Connections—across all customer tenants—share a single Azure API Management (APIM) instance per region. When ARM receives a call to an API Connection, it forwards that request to the shared APIM instance using a highly privileged ARM bearer token. The APIM instance then exchanges the inbound token for the backend credential stored in the target connection, and completes the call to the backend service.

The authorization check that is supposed to limit this is an Access Control List (ACL) on each connection. Only resources listed in the connection's ACL—in practice, the Logic App that owns it—should be allowed to trigger the token exchange.

The root problem Binary Security identified: ARM's own token, used in all these forwarded calls, effectively has rights to all connections on the shared APIM instance, regardless of which connection a request nominally references. Boundary enforcement relies entirely on input validation at the ARM layer, not on any cryptographic or identity-bound isolation at the APIM layer itself. As Binary Security states plainly in the October 30 post: "The only thing stopping exploitation is really the layers of input validation bolted onto the various systems, but as you will see, it is really difficult to catch all the edge cases here."

How the First Full Compromise Worked

Binary Security's August 2025 post, which earned a $40,000 bounty and a Black Hat US briefing slot, documented the initial exploitation path using the undocumented DynamicInvoke ARM endpoint.

When a caller sends a DynamicInvoke request, ARM takes the connector type and connection ID from the referenced API Connection, appends the requested action endpoint, and fires the resulting path at the shared APIM instance under its privileged ARM token. The action endpoint is passed as a path parameter.

Binary Security created a Logic App Custom Connector with a trivially simple Swagger definition containing a string path parameter, then issued a DynamicInvoke request in which the path parameter value was a directory traversal string:

POST /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/
connections/{attacker-connection}/DynamicInvoke?api-version=2018-07-01-preview

{ "request": { "method": "get",
"path": "../../../../{victim-connector-type}/{victim-connection-id}/secrets" } }

Because ARM normalizes the path before sending it to APIM, the traversal collapses the full path down to /apim/{victim-connector-type}/{victim-connection-id}/secrets. APIM receives what appears to be a legitimate request to the victim connection, backed by ARM's privileged token, and returns the victim's Key Vault secrets—or any other backend data—to the attacker. The October 30 post includes the HTTP 200 response showing the secret value dontreadme returned verbatim.

The attacker needs two things: Contributor rights to their own API Connection in their own tenant (a standard privilege for anyone deploying Logic Apps), and the connection ID of a victim connection. Binary Security notes that connection IDs are not secret in practice; they appear in CI/CD logs, GitHub issues, and public forums.

The result Binary Security describes as "full cross-tenant compromise": complete read and write access to the backend service connected by the victim's API Connection. For a Key Vault that means every secret the vault holds. For a SQL database, Binary Security demonstrated arbitrary query execution, including writes.

The Fix, the Bypass, and the Regression

Microsoft's first fix after the April 2025 report was a blacklist on the path parameter, blocking ../ and URL-encoded variants. Binary Security's October 30, 2026 post documents what happened next across the subsequent four patches.

Bypass 1 – DynamicList: A second undocumented ARM endpoint, DynamicList, accepted path parameters using a different structure with individually named parameters (one, two, three, …). The same path traversal logic applied. Binary Security demonstrated arbitrary SQL writes against a victim database:

{
"dynamicInvocationDefinition": {
"operationID": "nine",
"parameters": {
"one": { "value": ".." },
"two": { "value": ".." },
"three": { "value": "sql" },
"four": { "value": "88d28f5ff7b642cfb91df184938d074c" },
"query": { "value": { "query": "INSERT INTO MySecrets VALUES ('NewEvilSecrets', 3)" } }
}
}
}

Microsoft's fix for this variant was to block both the DynamicInvoke and DynamicList endpoints entirely.

Bypass 2 – host.api.RuntimeUrl: A third path used a different mechanism entirely: the host.api.RuntimeUrl parameter accepted by Logic App workflow definitions. After a series of connection ownership validations pass on the referenced connection, this parameter can redirect the actual APIM call to a different runtime URL. Binary Security confirmed the parameter still worked even after the earlier fixes, enabling the same cross-tenant access to API Connection backends.

The research explains why Consumption Logic Apps are particularly exposed here: unlike Standard Logic Apps (dedicated host), Consumption apps create Version 1 connections with no managed identity to authorize—meaning every Consumption app implicitly has access to every V1 connection, with only input validation standing in the way.

Microsoft's fix was to validate that the RuntimeUrl exactly matched the expected APIM endpoint for the referenced connection.

Bypass 3 – pre-normalization validation: The path normalization check happened before URL normalization, so submitting a URL like https://logic-apis-norwayeast.azure-apihub.net/apim/keyvault/{victim-id}/../../../{attacker-path} passed validation (it matched the expected prefix) but resolved to the victim's endpoint at the APIM layer.

The regression: When Microsoft patched the pre-normalization check, they stopped validating the original RuntimeUrl path—which meant the earlier, simpler RuntimeUrl bypass worked again. Binary Security's October 30, 2026 post states this plainly: "The original RuntimeUrl path was no longer validated, and as a result, you could perform that attack again."

The dev.to writeup by Frank Chu distills the pattern accurately: each of the five bugs is "a check running at the wrong layer of abstraction: on the raw string instead of the decoded one, on the pre-normalization URI instead of the resolved one, on the referenced connection instead of the executed runtime."

All five vulnerabilities were patched, Binary Security says, within a reasonable time after each submission. The research blog does not claim any remain open.

What "Full Compromise" Means Here

"Full compromise" in this context is defined by what the API Connection's backend credential can do—not by Entra ID Global Administrator access or Azure subscription-level control-plane compromise. The scope is the backends attached to Azure API Connections. If a victim's Key Vault connection used an OAuth token with access to all secrets in that vault, the attacker gets all those secrets. If the SQL connection was provisioned with a db_owner account, the attacker can read, write, and delete.

Binary Security notes explicitly that over-provisioned credentials are the common case: "In the case of OAuth connections, it will surely always be the token of the person who initially made the connection. And for the API key case, well, who cares enough to scope such things minimally? Microsoft doesn't, at least." The scope of compromise is therefore typically as broad as the backend admin who set up the Logic App.

This is distinct from Dirk-jan Mollema's September 2025 Entra ID flaw (reported by The Hacker News), which enabled Global Admin impersonation across any Entra tenant regardless of service. The Binary Security research is scoped to Azure API Connections specifically—an important distinction for organizations that use Logic Apps heavily versus those that don't.

Microsoft's Response

Microsoft's Security Response Center (MSRC) confirmed the initial DynamicInvoke vulnerability three days after Binary Security's April 2025 submission and had mitigations in place within a week, according to the research blog. The $40,000 bounty followed. The subsequent four vulnerabilities were also patched, with a combined total of $200,000 paid across all five.

Binary Security notes "some disagreements with MSRC along the way" but says it is "quite happy with the results overall." No MSRC advisory number or CVE identifier is cited in the published research. Microsoft has not published a standalone security advisory attributable to this research series in the sources reviewed for this article.

The Microsoft Security Blog published an April 2026 post on cross-tenant attacker techniques involving Teams helpdesk impersonation—a separate threat model—but nothing that addresses the API Connections research.

Practical Checklist for Azure Customers

Binary Security's published research does not name any specific victims, and all five vulnerabilities were patched before the October 30, 2026 disclosure. The following steps are grounded in the architecture described in the research:

1. Audit Logic App API Connections for over-privileged credentials. For OAuth connections, identify which user account's token is stored. If it belongs to a Global Admin or a broad contributor, the blast radius of any future exploit in this surface area is maximized. Replace with a dedicated service principal scoped to minimum required permissions.

2. Apply least-privilege to Key Vault and SQL backend accounts used by API Connections. The research demonstrates that a Key Vault connection yields all secrets the stored OAuth token can reach. Use Key Vault access policies or RBAC to restrict the backing identity to only the secrets the Logic App actually needs.

3. Prefer managed identity over stored OAuth tokens where the connector supports it. Standard Logic Apps (dedicated host) support managed identity for API Connections via Version 2 connections, which Binary Security identifies as a materially tighter authorization model. Consumption Logic Apps historically did not support managed identity, which is partly why the vulnerability surface existed.

4. Treat API Connection IDs as semi-sensitive. They appear in CI/CD logs and stack traces. Audit public repositories and build logs for exposed connection IDs and rotate any connections whose IDs have been inadvertently published. While the known exploitation paths are patched, Binary Security warns: "if these endpoints ever become accessible again, I would assume they would be vulnerable."

5. Review Logic App workflow definitions for the host.api.RuntimeUrl parameter. If any workflow definition in your environment contains this parameter, verify it was added intentionally and that its value matches the expected APIM endpoint. Unexplained presence of this parameter in a workflow could indicate tampering.

6. Monitor ARM calls to DynamicInvoke and DynamicList endpoints. Microsoft blocked these endpoints as part of remediation. API calls targeting these endpoints should not appear in normal operations; alert on any such traffic in Azure Monitor or Defender for Cloud.

7. Do not rely on connection ID secrecy as a security control. The research explicitly states these IDs are not secret values and can be found readily on the Internet. Defense must be at the credential and authorization layer, not at obscurity.

The primary source for this article is Binary Security's three-part research series: Part 1 (March 2025), Part 2 (August 2025), and Part 3 (October 30, 2026). No CVE identifiers or standalone MSRC advisory numbers were identified in available sources. Microsoft has not published a public advisory specifically addressing this research; the absence of a vendor statement beyond the bounty payments is noted.