- A researcher reports five elevation-of-privilege flaws in Azure API Connections, each letting one customer's request use another tenant's connection. He says Microsoft fixed all five.
- He argues the fixes were repeated input checks over a shared design, and that his bypasses show how hard that approach is to get right.
- Inventory your Logic App connections and limit the backend credentials behind them to the minimum each workflow needs.
Patching a vulnerability and fixing a design are different jobs. One researcher's account of Azure Logic Apps shows what happens when only the first gets done.
On October 2, 2026, the researcher behind binsec.no published the third post in a series on Azure API Connections. The service is part of Azure Logic Apps, Microsoft's workflow automation tool. He reports five elevation-of-privilege flaws. Each had the same result: one customer could make Azure use another customer's connection. He rates all five as critical. He says the vulnerabilities in this post netted him $200,000 in rewards.
What a connection is, and why it matters
A Logic App often needs to reach other systems, such as a database, a Key Vault or a tool like Jira or Salesforce. An API Connection holds the credential for that link.
The researcher describes Microsoft's own diagram in four steps. The Logic App calls a shared Azure API Management instance. That instance checks the request against the connector's OpenAPI definition. It then swaps the caller's token for the stored token of the backend service. Finally, it calls the backend.
His point is that this middle layer is shared. If an attacker can make it act on a victim's connection, it uses the victim's stored credential. He says the backend can be almost any service, including Key Vaults and Azure SQL databases.
Five routes to the same result
The first flaw came from his earlier post. It used the DynamicInvoke endpoint in Azure Resource Manager. A path traversal let him read a Key Vault in a different tenant. That means using special path characters to step outside the intended location.
Microsoft marked it fixed a couple of weeks after his report. He judged that the fix limited allowed paths. In his view, it did not address the token problem underneath.
For the second flaw, he extracted code from a Standard Logic App host. Searching it for DynamicInvoke, he found four functions on the same path in total. Three were undocumented, and he found no reference to them anywhere.
He reached one of them, DynamicList, by changing one word in the request address. His example payload wrote to a victim's SQL server across tenants. Microsoft's fix blocked these endpoints. He says no other protection seemed to be in place.
The third, fourth and fifth: a gap between two versions
He then compared how connections are created. Consumption Logic Apps share infrastructure and create Version 1 connections. Standard Logic Apps have a dedicated host and create Version 2 connections.
In the Standard flow, the app's managed identity is explicitly allowed to use the connection. A Consumption app has no such identity to allow. His reasoning was that any Consumption workflow could, in principle, use any Version 1 connection. Only input checks stood in the way.
The workflow's Code view exposed a parameter named host.api.RuntimeUrl. It let him send the call to a different address. If the host ended in azure-apihub.net, Azure added the authorization header. He says he cannot see why the parameter exists.
Microsoft's fix required the address to match exactly. He got around it because the check ran before the path was cleaned up. The runtime saw his own connection. The API Management instance saw the victim's.
A later fix for that bypass stopped checking the original RuntimeUrl path. That reopened the earlier RuntimeUrl attack.
The lesson: filters are not boundaries
This shows two ways to protect shared credentials. One is validation. The service trusts the request to name the right customer, then checks it. That has to be right every time. The other is a boundary. The caller simply has no permission to reach the other customer's credential.
The researcher's account suggests the Version 1 design leaned on the first approach. Each fix added another check. Each bypass found a gap between two checks.
The people exposed are the owners of the backend systems behind these connections.
Some limits apply. This is one researcher's account, and the post leaves out some payloads and screenshots. It does not describe attacks on real customers. It gives no CVE identifiers and does not quote Microsoft's own view. He says all the reported issues were fixed within a reasonable time.
What leaders should ask
The researcher adds a caveat. Connection owners can limit tokens and keys to minimal rights in the backend. He guesses this is rarely done. For OAuth connections, he says, the token belongs to the person who first made the connection.
That gives teams four questions for their cloud owners. Which Logic Apps and API Connections exist, and who created them? Whose credentials sit behind them? Are those credentials limited to what each workflow needs? Are any Version 1 connections still in use?
Limiting rights on the backend caps the damage when a platform check fails. A failed check is a bug. A credential that can do everything is often a choice your own team made.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: binsec.no.
