В Google Cloud и Microsoft Azure обнаружили две уязвимости класса Confused Deputy, которые позволяют атакующему вырасти из ограниченного доступа до административного. Для команд, которые управляют облаком через Kubernetes, сервисные учётные записи и IAM, это плохой сигнал: сбой произошёл не на периферии, а в самой связке между «удобной автоматикой» и контролем полномочий.
О находках рассказал Dark Reading со ссылкой на независимого исследователя Джастина О’Лири. По его данным, один сценарий затрагивал Azure Backup для AKS, второй — Config Connector в Google Cloud. В обоих случаях привилегированный сервис выполнял запрос от менее привилегированного пользователя и не проверял границы его прав должным образом.
Azure Backup для AKS открывал путь к cluster-admin
Первый сценарий О’Лири раскрыл 12 мая 2026 года. Речь шла о сервисе резервного копирования для Azure Kubernetes Service. По описанию исследователя, пользователь с ролью Backup Contributor, у которой нет прав внутри Kubernetes, мог получить уровень cluster-admin в AKS.
Дальше последствия уже вполне приземлённые: доступ к резервным копиям, извлечение чувствительных данных, запуск вредоносных контейнерных нагрузок и движение по инфраструктуре. Microsoft публично уязвимость не признала, но, как пишет Dark Reading, после переписки с исследователем и CERT/CC путь атаки, вероятно, закрыли без отдельного уведомления для клиентов.
Здесь важен не только сам баг, но и его форма. Azure Backup использует механизм Trusted Access, то есть доверенный сервис получает доступ к кластеру через выделенную цепочку разрешений. Если такая цепочка проверяет не всё, низкий уровень доступа внезапно становится входом в административную зону.
Config Connector в Google Cloud позволял обойти IAM
Вторую проблему исследователь опубликовал 18 июня 2026 года. Она касается Config Connector — инструмента с открытым кодом, который позволяет управлять ресурсами Google Cloud через Kubernetes. По данным О’Лири, при создании ресурса IAMPolicyMember для внешней организации Config Connector передавал указанный идентификатор в API Google Cloud со своими повышенными правами и не проверял, может ли конкретный пользователь вообще назначать роли на этот объект.
Итог выглядел жёстко даже по меркам облачной безопасности: пользователю с базовым доступом к пространству имён Kubernetes и без прав в Google Cloud хватало корректно оформить запрос, чтобы получить роль владельца организации. Это уже полный административный контроль на уровне всей организации, а не одной виртуальной машины или проекта.
Дополнительная проблема — видимость в журналах. По словам О’Лири, такие действия отражаются как активность сервисной учётной записи, а не самого атакующего. Для SOC и команд расследования это почти худший вариант: журналы есть, но они указывают не на того субъекта. Когда расследование стартует с ложной точки, время работает на атакующего.
Почему это не частный баг, а архитектурный риск
Термин Confused Deputy появился ещё в 1988 году: так называют ситуацию, когда более привилегированный посредник выполняет действие от имени менее привилегированного пользователя и не сохраняет контекст его полномочий. За почти 40 лет проблема никуда не делась, просто теперь её цена выше: вместо локальной программы под удар попадают облачные организации, резервные копии и целые кластеры.
Google, по информации Dark Reading и самого исследователя, не признала сценарий в Config Connector уязвимостью для программы вознаграждений. Позиция сводилась к тому, что клиенты сами должны аккуратно настраивать разрешения. Но если инструмент с повышенными правами не проверяет, имеет ли вызывающий субъект право на целевое действие, это уже не просто «неудачная конфигурация». Это изъян в модели доверия.
Что это значит для команд в России и СНГ
Практический вывод простой: связки вида Kubernetes — коннектор — сервисная учётная запись — IAM нельзя считать безопасными только потому, что их поддерживает облачный провайдер. Если у коннектора широкие права, а разработчики могут создавать или менять его объекты из обычного пространства имён, это потенциальный путь для повышения привилегий.
Для инфраструктурных и ИБ-команд это повод проверить три вещи: какие сервисы действуют от имени облака, какие права у них реально есть и можно ли инициировать эти действия с низкого уровня доступа. Отдельно стоит смотреть на журналы сервисных учётных записей: если «служебка» внезапно меняет IAM-политики или трогает чувствительные ресурсы, это не порядок, а сигнал копать глубже.
Похоже, следующий раунд в этой истории будет уже не про конкретные продукты Google и Microsoft, а про то, готовы ли сами облачные платформы признать такие сценарии ошибкой проектирования, а не спором о трактовке правил bug bounty.
Оригиналы: Dark Reading, разбор Google Cloud от Джастина О’Лири, разбор Azure Backup для AKS.