Five critical vulnerabilities in Azure API Connections allowed a Binary Security researcher to use other customers’ connections to act against their connected services. The impact did not depend on directly breaking Key Vault, Azure SQL, or an external application: it involved inducing Azure’s connector infrastructure to use the authorization already configured for the victim’s connection.
The researcher says the findings described earned him $200,000. He also says Microsoft fixed the vulnerabilities after receiving the reports, although the series shows how a fix focused on one endpoint could leave another route to the same capability open.
“In total, the vulnerabilities here netted me a cool $200,000.”
— Binary Security author
A connection that carries its authority with it
API Connections is part of Azure Logic Apps. It allows a workflow to call external services without separately implementing all the authentication and credential exchange. According to Binary Security’s description, a Logic App queries a shared instance of Azure API Management (APIM); APIM validates the operation against the connector’s OpenAPI definition, exchanges the received token for the credential configured for the service, and sends the request to the backend.
That backend could be an Azure service, such as Key Vault or Azure SQL, or an external application such as Jira or Salesforce. That is why the security boundary is not just about who can edit a Logic App: it also matters whether each request is tied to the specific connection the requester is authorized to use. If APIM ends up operating on someone else’s connection, the backend receives a call carrying the authority already associated with that connection.
flowchart LR A["Logic App o ARM"] --> B["APIM compartido"] B --> C["Valida operación y cambia credencial"] C --> D["Servicio conectado"] E["Conexión de otro cliente"] --> B
The diagram summarizes the mechanism described by Binary Security: the problem arose when a request managed to direct the operation to a connection that did not belong to the customer sending it. ARM, Azure’s management plane, could also be a way to invoke connection operations through APIM.
From one access route to several partial fixes
The first case the researcher reviews comes from an earlier post in his series. A path traversal vulnerability in the DynamicInvoke endpoint of the ARM REST API allowed him to read a Key Vault secret from another tenant using his own connection. The example published by Binary Security shows a response containing the secret’s value. The researcher says Microsoft marked the flaw as fixed a few weeks after he reported it.
The fix appeared to restrict the paths accepted by DynamicInvoke, rather than address the underlying issue: that a request could reach the credential associated with another connection. To check what other surfaces existed, the researcher extracted code for the resource type of a dedicated Logic App Standard. He notes that he did not know whether this code ran on Microsoft’s systems or was an included artifact, but found several public functions on the same route, including DynamicList, which was undocumented.
By testing DynamicList, he reproduced the same path traversal logic and demonstrated a write to an Azure SQL database through the victim’s connection. According to his account, Microsoft blocked the undocumented endpoints after receiving that report. The researcher does not describe that decision as a fix for the common cause: he suggests that if those endpoints were exposed again, they could become vulnerable again.
The change in attack surface did not end the investigation. The researcher moved on to Logic Apps workflows themselves and found differences between the Consumption and Standard models. Logic Apps Standard use a dedicated host and create version 2 connections, authorized through the Logic App’s managed identity. Consumption Logic Apps, whose workflows share an environment with others, create version 1 connections and do not have that dedicated identity for authorization.
Based on this difference, the researcher deduced that Consumption Logic Apps could have implicit access to version 1 connections, with input validation serving as the effective barrier. Directly changing the reference to the victim’s connector did not work: the runtime checked that the connection belonged to the user. However, while reviewing the workflow definition, he found the host.api.RuntimeUrl parameter, which allowed the runtime URL included in the connection to be replaced.
The researcher says that if the specified host ended in azure-apihub.net, the request still included the necessary authorization header. This allowed him to bypass the ownership check for the referenced connection and direct the call to another route. Microsoft added a check to require that the URL match the expected endpoint for that connection. But, according to Binary Security, validation took place before the path was normalized: the runtime and APIM interpreted the destination differently.
The sequence of fixes also had an unexpected effect. The researcher says that when Microsoft fixed that path traversal, it stopped validating the original RuntimeUrl path, reopening the earlier attack. The investigation therefore illustrates something more specific than a series of unrelated errors: multiple inputs and routes led to a common capability, and changes made to one could alter the behavior of another.
The impact depends on the permissions of each connection
The impact does not amount to automatically gaining unlimited privileges across all connected services. Binary Security acknowledges that owners can restrict the scope of tokens and keys. The capability gained in the backend is limited by the permissions the connection already had: a credential with restricted access offers less latitude than one with broad permissions. The researcher considers minimal permissions uncommon, but that is his assessment, not a measurement of customers’ configurations.
For teams using Logic Apps, the practical takeaway is to review what authority their connections carry, not just who can modify their workflows. A connection to Key Vault, SQL, or a third-party service may represent permissions granted by an identity or by the person who authorized OAuth. Reducing those permissions limits potential damage if an isolation layer fails; it does not replace the requirement to ensure that each call can use only the corresponding connection.
How fixes are evaluated in managed services also matters. In the cases described, Microsoft changed behavior on the service side, so the researcher does not discuss installing a patch in each Logic App. But restricting a path on an endpoint, blocking undocumented functions, and validating a URL before normalizing it are distinct defenses. The recurrence of flaws around the same capability makes clear why a fix must be tested against alternative routes and request transformations.
Binary Security says the five critical flaws were fixed within a reasonable time after the reports and expresses general satisfaction with the response, despite disagreements with MSRC. The researcher also presented the work at Blue Hat Asia 2026. His post does not establish that the cases demonstrated in testing resulted in unauthorized access to real customers’ data.
The question organizations are left with is not whether each connection grants access to its entire backend, but what operations each identity or credential actually permits, and whether their logs can detect use outside expected workflows.
Sources: Binary Security AS, The Protec Blog - Guarding Your Future, One Byte at a Time., Glonce, PAN
