Glonce

Azure API Connections flaws let researcher cross-tenant compromise, netting $200,000

securityThe Glonce editorsHacker News🔥73Glonce rating73Impact65Novelty70Relevance70Surprise72Players75Credibility80

A security researcher published the third post in a series on Azure API Connections, a component of Azure Logic Apps. The earlier two posts had already described an insecure architecture and a full cross-tenant compromise; this post covers additional vulnerabilities that give an attacker the same core capability, using another tenant's connection to act against that tenant's backend service. The author says the vulnerabilities described in this post netted $200,000 in total, and also presented the work at a talk at Blue Hat Asia 2026.

According to the author, Azure API Connections route requests through a shared API Management (APIM) instance that checks an operation against the connector's API definition, then exchanges the caller's token for the backend service's configured credential before calling that backend. The backend can be almost any connected service, including Azure Key Vault, Azure SQL, or external systems such as Jira or Salesforce. The author argues that if an attacker can trick the APIM instance into operating on a connection that is not theirs, they inherit the victim's configured credential on the backend. The author notes that connection owners could in principle scope tokens to minimal privileges, but guesses this is rarely done, since OAuth connections generally carry the original creator's own token.

The starting point, recapped from the prior post, was a path-traversal bug in the DynamicInvoke endpoint of the Azure Resource Manager (ARM) REST API, which let the author read another tenant's Key Vault secret through his own connection. A few weeks after he reported it, Microsoft marked it fixed; the author judged the fix looked like a path restriction rather than a fix to the underlying token-handling issue, and suspected there would be ways around it.

Looking for a way around the fix, the author extracted code from the resource type itself after SSHing into a dedicated-host Standard Logic App, and found that the fix only restricted paths rather than addressing the root cause. In that same code, alongside the public DynamicInvoke function, the author found three further undocumented public functions reachable on the same code path, including one called DynamicList, which had no documentation anywhere the author could find. He showed that simply swapping DynamicInvoke for DynamicList in the request URI reached that function, and that the same underlying path-traversal logic applied, letting him demonstrate a cross-tenant write against a victim's Azure SQL database through the victim's own connection. He reported only the DynamicList case first, hoping to also report the other two separately, but Microsoft's fix was simply to block all of the undocumented endpoints outright; the author sees no other mitigation in place and expects they would be vulnerable again if ever re-exposed.

With the dynamic-invocation endpoints blocked, the author found a separate route through Logic Apps themselves. He identified a structural difference between Consumption Logic Apps, which run co-located with other tenants' workflows and create what he calls Version 1 connections, and Standard Logic Apps, which run on a dedicated host and create Version 2 connections authorized via a managed identity. Because a Consumption Logic App has no managed identity to authorize against a connection, the author reasoned that every Consumption Logic App must have implicit access to every Version 1 API Connection, with only input validation standing in the way. Editing a workflow's underlying definition directly (rather than through the restrictive GUI) let him discover an undocumented parameter, host.api.RuntimeUrl, that overrides the URL baked into a referenced connection; he found that as long as the substituted host ends in azure-apihub.net, the request still carries the required authorization header, giving him another way to redirect a call meant for his own connection onto a victim's backend. The author reported this to Microsoft as well; the visible text breaks off as Microsoft begins working on a fix, before describing the remaining findings or how the $200,000 total breaks down.

Key facts

  • A researcher's third post on Azure API Connections (part of Azure Logic Apps) describes further cross-tenant vulnerabilities, which he says netted him $200,000 in total.
  • A path-traversal bug in the ARM REST API's DynamicInvoke endpoint let the author read another tenant's Key Vault secret; Microsoft's first fix restricted paths but, per the author, left the underlying token issue unaddressed.
  • Extracting resource code from a Standard Logic App revealed three further undocumented public functions alongside DynamicInvoke, including DynamicList, which the author used to demonstrate a cross-tenant write on a victim's Azure SQL database; Microsoft's fix was to block all these endpoints outright.
  • The author argues every Consumption Logic App has implicit access to every Version 1 API Connection, and found an undocumented host.api.RuntimeUrl parameter that redirects a call to a different backend URL while still carrying the required authorization header.
  • The author also presented the findings at a talk at Blue Hat Asia 2026; the available text cuts off before Microsoft's final fix and the remaining findings.

Why it matters

The author frames the underlying issue as architectural rather than a single bug: the shared API Management layer that Azure API Connections route through was, in the author's account, designed in a way that implicitly trusts any caller to operate on any connection, relying on input validation as the only real barrier. That made it possible, according to the author, for one tenant to reach another tenant's Key Vault, Azure SQL database, or connected third-party services such as Jira or Salesforce through a connection that was never theirs.

Who it affects

Anyone running Azure Logic Apps with API Connections is implicated by the author's account, since the described primitive applies broadly across connection types and the backend services they reach, rather than to one specific customer. The piece is a vulnerability research writeup, not an AI story, but is included here as a major cloud security account.

How to use it

There is no product or pricing angle here: this is a vulnerability disclosure writeup. Organizations using Azure Logic Apps API Connections may want to review how their connections are scoped, since the author suggests minimally scoped tokens or keys would have limited the impact, though he guesses this is rarely done in practice.

How solid is it

The account comes directly from the researcher who reports having been paid for the findings and who includes technical detail such as request examples and his reasoning at each step, lending it credibility. The visible text is cut off partway through the final section, before Microsoft's response to the last issue described and before the remaining findings are laid out, so part of the full account is not available here.

Risks and caveats

The claims and figures in this piece come from the researcher alone; the article does not state that any real victim's data was actually exposed, only that the techniques were demonstrated using the author's own test setups. No dates, CVE identifiers, or a breakdown of how the $200,000 splits across the individual findings are given in the available text, and the author himself says he is not certain whether the ARM resource code he extracted actually runs on Microsoft's production machines or is merely an included artifact.

“API Connections allow anyone to fully compromise any other connection worldwide, giving full access to the connected backend.”

— the author