Google с марта 2026 года держит в статусе P1/S1 баг в Config Connector без патча, CVE и выплаты исследователю. Проблема неприятна не только для Google Cloud: если баг в Config Connector действительно позволяет пользователю одного Kubernetes namespace за секунды стать владельцем всей GCP-организации, то для команд, которые строят инфраструктуру на GKE и делегируют доступ разработчикам, это уже не спор о формулировках, а вопрос архитектурного риска.
О ситуации сообщает The Register. По данным издания, исследователь Джастин О'Лири 8 марта отправил в Google отчет об уязвимости, которую он назвал ConfigConfusion. Речь идет об open source-дополнении Config Connector, через которое Kubernetes может управлять ресурсами Google Cloud. 27 марта инженер Google принял отчет, написал исследователю «Nice catch!», сообщил о передаче кейса продуктовой команде и попросил проверить платежные настройки в профиле bug bounty. Внутри компании инцидент получил приоритет P1 и серьезность S1 — то есть высшую категорию для проблем, которые могут затрагивать большой процент пользователей и ломать базовые функции организации.
Дальше начался уже знакомый для багхантеров жанр «у нас все работает как задумано». 7 апреля Google через автоматическое уведомление сообщил О'Лири, что выплата не положена, потому что влияние бага не соответствует критериям программы вознаграждений. Формулировка еще интереснее: продукт, по версии компании, working as intended. При этом сам отчет не закрыт. Почти через три месяца после отправки он, как пишет The Register, все еще висит со статусом in progress (accepted), без исправления и без CVE. Для внешнего наблюдателя это выглядит как минимум странно: если уязвимости нет, почему кейс не закрыт; если она есть, где патч и advisory.
Суть бага в Config Connector О'Лири описывает довольно приземленно и оттого тревожно. Если у Config Connector service account есть права уровня организации, любой пользователь с доступом к одному namespace и kubectl может отправить вредоносный объект IAMPolicyMember. Дальше оператор, не проверяя, имеет ли инициатор право на такую операцию, передает контролируемый пользователем идентификатор организации в GCP IAM API и выполняет действие уже от имени своего привилегированного аккаунта. Итог — эскалация до roles/owner на уровне всей GCP Organization. О'Лири утверждает, что для демонстрации хватает трех строк YAML и примерно пяти секунд. В этом сценарии разработчик без собственных IAM-привилегий получает доступ к проектам, секретам, биллингу и даже связанным сервисам уровня организации. Отдельный неприятный штрих: по словам исследователя, след атакующего в IAM-аудите почти не виден, потому что запрос выполняется не от его личности, а от имени Config Connector.
Google отвечает предсказуемо: эксплуатация возможна только в том случае, если злоумышленник уже попал в среду компании и добрался до привилегированного экземпляра Config Connector, а сам service account зачем-то получил роль Organization Admin. Компания подчеркивает, что такая конфигурация противоречит принципу наименьших привилегий и публичным best practices Google Cloud. Формально аргумент не нулевой. Проблема в другом: для многих облачных инцидентов цепочка и состоит из нескольких слабых звеньев, а не из сказочной кнопки «получить root». Если оператор способен выполнять высокопривилегированные действия по запросу непривилегированного пользователя без явной авторизационной проверки, спор о том, считать ли это уязвимостью или «неудачной конфигурацией», уже начинает напоминать юридическую гимнастику.
О'Лири, в свою очередь, указывает на еще более неудобный для Google нюанс: сами документы Google описывают сценарии, в которых Config Connector получает права уровня организации для управления ресурсами сразу в нескольких GKE-кластерах. The Register пишет, что проверил этот тезис. То есть спор идет не о какой-то экзотической самодеятельности клиента, а о модели использования, которая как минимум допускается документацией. И вот здесь баг в Config Connector становится важным уже для практиков: безопасная система должна выдерживать не только идеальную реализацию least privilege, но и реальные производственные компромиссы, которые вендор сам же помогает настроить.
Для рынка это история не только про один оператор в Kubernetes и не только про Google. О'Лири прямо называет происходящее паттерном. Ранее в 2026 году у него был похожий конфликт с Microsoft вокруг Azure Backup for AKS: исследователь сообщил о повышении привилегий, компания отклонила отчет, а затем, по его словам, тихо исправила проблему без CVE и публичного advisory. Для программ bug bounty такой подход токсичен по двум причинам сразу. Во-первых, исследователи получают сигнал: находить сложные облачные цепочки невыгодно, потому что их можно переквалифицировать в «предпосылки эксплуатации». Во-вторых, клиенты не получают нормальной коммуникации о риске и не понимают, нужно ли им срочно пересматривать конфигурации.
Для российских и русскоязычных команд, которые работают с GKE, Anthos-подобными паттернами или вообще любят выносить управление облаком в Kubernetes CRD, вывод очень практический. Нужно отдельно проверять, какие именно сервисные аккаунты используют операторы, на каком уровне им выданы права и может ли namespace-пользователь инициировать действия вне своей зоны ответственности. Особенно это касается сред, где разработчикам выдают доступ к namespace ради скорости релизов, а привилегированные контроллеры потом тихо становятся «заместителями начальника», которые подписывают все, что им подсунули. На бумаге это удобная автоматизация; в инциденте — короткий путь к владению всей организацией.
Главный вопрос здесь уже даже не в том, заплатит ли Google одному исследователю. Гораздо важнее, как крупные облачные вендоры будут классифицировать «составные» облачные уязвимости дальше: как нормальный класс confused deputy-ошибок, требующий исправления и прозрачного advisory, или как неудобный пограничный кейс, который проще оставить между статусами accepted и denied. Во втором сценарии компании продолжат жить с рисками, о которых знают исследователи, знают вендоры и не знают только те, кто за это платит. Подробнее о кейсе можно прочитать в .