Исследователь Binary Security продолжил серию публикаций об архитектуре Azure API Connections, используемой в Logic Apps. Он суммарно обнаружил пять критических уязвимостей повышения привилегий. По его словам, каждая давала сходную возможность: заставить общий компонент Azure работать не с подключением атакующего, а с чужим подключением и получить доступ к соответствующему backend-сервису. В число потенциально затронутых систем входили Key Vault, Azure SQL, Jira, Salesforce и другие внешние сервисы. За найденные ошибки автор получил $200 000.
При обычном вызове Logic App обращается к общему экземпляру Azure API Management. Тот проверяет операцию по OpenAPI-описанию коннектора, заменяет входной ключ или токен на учётные данные, настроенные для backend, и выполняет запрос. Если удаётся подменить идентификатор подключения, сервис использует токен жертвы. Практический ущерб зависит от выданных ему прав: минимально ограниченные ключи снижают риск, но автор полагает, что такую настройку применяют не всегда. Дополнительный путь вызова открывают ARM REST API через DynamicInvoke и /extensions/proxy/.
Первую ошибку исследователь описал ранее: обход пути позволял читать секрет Key Vault другого тенанта. После исправления он изучил код, доступный на выделенном хосте Standard Logic App, и обнаружил четыре недокументированные функции рядом с DynamicInvoke. Ограничение Microsoft касалось только исходной функции, поэтому аналогичный подход сработал через DynamicList. Компания затем заблокировала эти endpoints. Автор не приводит доказательств, что после блокировки осталась доступная атака, но предупреждает о риске при их повторном включении без более глубокого исправления.
Следующая группа ошибок связана с различием Consumption и Standard Logic Apps. В Consumption-версии нет выделенной managed identity для каждого приложения, и исследователь пришёл к выводу, что изоляция Version 1 API Connections существенно зависит от проверки входных параметров. Параметр host.api.RuntimeUrl позволял после проверки собственного подключения направить выполнение по другому адресу в пределах azure-apihub.net.
Microsoft добавила сравнение RuntimeUrl с ожидаемым адресом, но первая проверка выполнялась до нормализации пути, из-за чего защиту удалось обойти. Последующее исправление обхода пути временно снова сняло исходную валидацию RuntimeUrl. По словам автора, все пять сообщённых уязвимостей были устранены в разумный срок, несмотря на разногласия с MSRC. Материал был также представлен на Blue Hat Asia 2026.