Binary Security: Azure Logic Apps cross-tenant compromises (One Root Case)

What it is

A write-up by the Binary Security author (third in a series, 2026) of five critical cross-tenant elevation-of-privilege bugs in Azure Logic Apps API Connections, reported to Microsoft, which fixed all of them. The author reports $200,000 in bounties. The page gives no CVE ids.

How it works

API Connections route calls through a shared Azure API Management (APIM) instance. APIM exchanges the caller's key for the stored backend token. If a caller can make APIM act on another tenant's connection, the victim's configured token is used against their backend.

1. DynamicInvoke path traversal. ARM's DynamicInvoke (or /extensions/proxy/) endpoint forwards to APIM with rights to all connections. A request path such as path/%2e%2e/%2e%2e/%2e%2e/%2e%2e/apim/keyvault/<victim connection id>/secrets/<name>/value read a secret from another tenant's Key Vault. Microsoft's first fix blocked certain paths rather than fixing the token scoping.
2. Undocumented DynamicList. The author extracted resource-provider code from a Standard Logic App host and found four undocumented functions beside DynamicInvoke. Only DynamicInvoke had the path blacklist. Changing dynamicInvoke to DynamicList in the URI worked, with each path segment passed as its own parameter (.., .., sql, victim connection id, and so on). This gave an arbitrary SQL query, including an INSERT, on a victim's Azure SQL database. Microsoft fixed it by blocking all those endpoints. The author says no other mitigation is in place, so the endpoints would presumably be exploitable again if reopened. The other two functions were not reported.
3. host.api.runtimeUrl in Consumption Logic Apps. Consumption apps create Version 1 connections, with no managed identity authorized per connection. Standard apps create Version 2 connections with that authorization. The runtime validates ownership of the connection in host.connection, but the host.api.runtimeUrl input (set via code view or the API) can point elsewhere. If the host ends in azure-apihub.net, the Authorization header is added. This reached any Version 1 connection.
4. Validation before normalization. Microsoft's fix required the runtime URL to match the expected endpoint exactly. The check ran before path normalization, so a traversal in the URL passed validation while APIM resolved it to the victim's connection.
5. Regression. The next fix for that traversal stopped validating the original runtimeUrl path, so the first runtimeUrl attack worked again.

flowchart LR
  A[Attacker's own connection] --> B{Entry point}
  B -->|ARM DynamicInvoke / DynamicList| C[Path traversal to APIM]
  B -->|Consumption app host.api.runtimeUrl| D[Runtime URL override]
  C --> E[APIM uses victim connection token]
  D --> E
  E --> F[Victim backend: Key Vault, SQL, Jira, Salesforce]

Preconditions / Affected

• Attacker needs only their own API connection or Consumption Logic App, plus the victim's connection id.
• Impact depends on the backend token's privileges. The author guesses scoping is rarely minimal, and OAuth connections use the creating user's token.
• The page names Key Vault, Azure SQL, Jira and Salesforce as reachable backends.

What to do

The page gives no customer action. Microsoft fixed all five server-side, so nothing is stated to need patching. Least-privilege scoping of connection tokens and keys is the author's implied mitigation, and it is a guess about the cause, not a documented control.

Caveats

• The author reports disagreements with MSRC during the process, without detail.
• The page offers no detection guidance and no way to tell if a connection was abused.
• The Blue Hat Asia 2026 talk recording was not yet linked.