Five ways into another customer's Azure: what Binary Security found in API Connections

On October 30, 2026, a researcher at the security firm Binary Security published part three of their Azure's Weakest Link series, and the summary fits in one line: they found five critical privilege escalation vulnerabilities in Azure API Connections, the piece Logic Apps use to talk to other services. Each one allowed the same thing: taking the connection of another Azure customer, in another tenant, and using their credentials against their backend. That includes reading secrets from someone else's Key Vault or writing to an Azure SQL database that isn't yours. According to the author, all of them have been fixed and the bounties added up to 200,000 dollars. If you have Logic Apps flows connected to anything important, this isn't just gossip: it explains where the risk lives in this kind of integration.

How API Connections work

When a Logic App connects to Key Vault, SQL, Jira or Salesforce, it doesn't store the credential inside the flow. Microsoft documents it like this: there is a credential and metadata store that holds the connection information, the access control lists (ACLs) and the credentials, and an Azure API Management (APIM) instance that is "the entry point for all calls" to the connectors.

The researcher sums it up in four steps:

The Logic App calls the shared APIM.
The APIM checks in the connector's OpenAPI definition that the action is valid.
The caller's token is exchanged for the token or key configured in the connection.
The APIM makes the call to the backend with that credential.

That APIM isn't yours. It's infrastructure shared among customers. If you manage to get it to work on a connection that doesn't belong to you, you use the owner's token on their service. The series is devoted to exactly that: finding ways to trick that intermediary.

Add to this a detail the author flags as a warning: the connection operates with the permissions granted by whoever created it. In OAuth connections, it's the token of the person who set it up. In API key ones, I'd add, almost nobody bothers to limit the scope.

The five vulnerabilities

1. DynamicInvoke with path traversal. This was the one they covered in August 2025. Azure Resource Manager (ARM) has an undocumented endpoint, DynamicInvoke, that calls the APIM with privileges that reach all connections. With a custom connector and a path with encoded ../, the request left your connection and landed on someone else's. They reported it to Microsoft on April 7, 2025, it was confirmed three days later, and a mitigation came within a week. At that time they said they received 40,000 dollars. The fix was a blacklist that blocks ../ and some encoded variants in the path parameter.

2. DynamicList and its hidden siblings. While reviewing the code of a Logic App Standard (which gives you a dedicated host you can SSH into), they found that next to DynamicInvoke there were other undocumented functions on the same route. One of them, DynamicList, didn't have the blacklist. With the same trick, passing the path segments as parameters, they managed to write to an Azure SQL database in another tenant. Microsoft responded by blocking those endpoints. The researcher warns that they don't see another mitigation, so if they are ever reopened, they assume they would be vulnerable again.

3. Logic Apps Consumption and the host.api.RuntimeUrl parameter. Here they switched doors. Logic Apps Standard create version 2 connections and authorize the app with its managed identity. Consumption ones, which share infrastructure with other customers, create version 1 connections and there is no identity to authorize. Their conclusion: every Logic App Consumption had implicit access to any V1 connection, and the only thing holding it back was input validation. From the flow's code view they found the host.api.RuntimeUrl parameter, which lets you change the connection's runtime URL. As long as the host ended in azure-apihub.net, the platform added the authorization header. Pointing it at someone else's connection, the flow returned the victim's secret.

4. Path traversal inside the RuntimeUrl. The fix required the RuntimeUrl to match the connection's. The problem was the timing of the validation: it was checked before normalizing the path. A URL that started the same as the correct one and then went up directories with .. passed the filter, and the APIM ended up at the other person's connection.

5. The regression. When Microsoft fixed the fourth one, the original RuntimeUrl stopped being validated and attack number 3 worked again as is.

Diagram of the API Connections flow in Azure, with the shared APIM and the token exchange, and the list of the five vulnerabilities with their fix

The author closes by saying that all five were fixed in a reasonable time and that, although there were differences with the MSRC (Microsoft's security response center), they're happy with the outcome. They also presented the work at BlueHat Asia 2026 and say they will add the video when it's published.

Are there CVEs?

The post doesn't mention CVE numbers. In Microsoft's Security Update Guide there are several 2026 entries for Azure Logic Apps of the "elevation of privilege" type, for example CVE-2026-21227 (path traversal, critical severity, CVSS 8.2, published January 22) and CVE-2026-42823 (improper access control, CVSS 9.9, published May 12). Neither credits a researcher in its public data, so I can't confirm they correspond to these reports. What they do say: 21227 is already "fully mitigated by Microsoft" and requires no action; for 42823, Microsoft states that it notified affected customers through Azure Service Health with tracking ID 1P8-C0G and remediation instructions. If you manage Logic Apps, it's worth searching for that ID in your portal.

My take

The interesting part isn't the five bugs, it's the pattern. The researcher says it in their own summary: the only thing preventing exploitation was "layers of input validation" added on top of the systems, and it's very hard to cover every weird case. The fixes they describe treat the symptom. They block ../, they block an endpoint, they require a URL to match. The root problem stays the same: there is a shared intermediary with access to everyone's credentials, and the boundary between customers depends on every filter being done right. The regression in vulnerability 5 is exactly what happens when security depends on patches on top of patches.

It also has to be said: Microsoft fixed everything, paid well and the researcher was able to publish. That's how it should work.

What you can do

There's no patch to install: these are service flaws and, according to the author, they're already fixed. What you do control is how much damage a compromised connection would do, because these attacks inherit exactly the permissions you gave it. Based on Microsoft's Logic Apps security guide (I didn't test it; this comes from the documentation and the researcher's article):

Least privilege on every connection. Microsoft insists on the principle of least privilege for users, apps and managed identities. A Key Vault connection that only reads one secret doesn't need to list or write all of them.
Be careful with personal OAuth connections. If the connection uses an administrator's account, the attacker inherits the administrator. Use service accounts or managed identities with limited scope.
Check who is Contributor. Microsoft's guide warns that having Contributor or edit permissions on a flow is equivalent to having the permissions of every managed identity assigned to that flow.
Block connectors you don't use. The same guide explains how to block connections to specific connectors.
Check Azure Service Health for notice 1P8-C0G and for any Logic Apps notification.
Rotate sensitive credentials that live in old connections. The post doesn't say whether anyone exploited these flaws outside the research, and Microsoft marks the Logic Apps CVEs cited above as not exploited. Rotating is cheap hygiene.