Microsoft's Azure API Connections — the plumbing that lets Logic Apps talk to Key Vaults, SQL databases, Jira, Salesforce, and hundreds of other services — contain a design flaw so fundamental that a single security researcher found five separate cross-tenant compromise paths exploiting the same root cause. The researcher, who presented at Blue Hat Asia 2026, netted $200,000 in bug bounties. The vulnerabilities are gone. The architecture that produced them is not. The core problem is structural, not incidental. When a Logic App fires a request through Azure's shared API Management (APIM) gateway, that gateway performs a token exchange: it swaps the caller's credential for the stored credential of the target backend service. But the APIM instance has implicit access to every connection routed through it, regardless of tenant. The only thing preventing Tenant A from using Tenant B's stored credentials is input validation — checking that the requested path stays within the caller's own connection. That is a guardrail, not a wall. The first exploit was a textbook path traversal. By encoding directory-traversal sequences (../../..) in the DynamicInvoke endpoint's path parameter, the researcher directed the APIM gateway to resolve a different tenant's Key Vault connection and return its secrets. Microsoft's fix: a path blacklist on DynamicInvoke. The researcher then SSHed into a dedicated Standard Logic App host, extracted the actual server-side code, and found three completely undocumented sibling endpoints — DynamicList among them — that performed the same function with zero path restrictions. Same traversal, different door. Microsoft's second fix blocked all the dynamic endpoints entirely. The researcher pivoted again, this time exploiting a subtler architectural split. Standard Logic Apps (dedicated hosts) use Version 2 connections authorized via managed identity. Consumption Logic Apps (shared hosts) use Version 1 connections with no such identity binding — meaning every Consumption Logic App has implicit access to every V1 connection. The only barrier, again, is input validation in the workflow editor and API layer. The pattern is damning in its repetition: the researcher identifies a new entry point, Microsoft patches the specific input path, and the researcher finds another because the underlying token-exchange architecture never changes. Each fix is a blacklist bolted onto a system whose default state is full access. The researcher explicitly notes that if any blocked endpoint is ever re-enabled, the vulnerability likely returns immediately. The $200,000 bounty total across five findings signals that Microsoft treats these as high-severity. But severity ratings and bounties address symptoms. The architectural reality — a shared gateway with implicit cross-tenant credential access gated only by input validation — remains. Every new endpoint, every new connector type, every edge case in path parsing is a fresh attack surface. The researcher's observation that scoped tokens are "rarely done" and that OAuth connections always carry the creating user's full token means the blast radius of any future bypass is likely maximum privilege. This is a case study in the difference between fixing vulnerabilities and fixing architecture. Microsoft has been reactive and reasonably fast on individual reports. But the researcher's ability to chain five distinct bypasses against the same root cause — path traversal, undocumented endpoints, connection-type misauthorization — suggests the whack-a-mole phase is not over. The question is whether Microsoft will redesign the token-exchange boundary or continue to bet that input validation can catch every edge case in a system where the default is full access.
