Google сказав "Молодець!", а потім відмовив у винагороді за критичну вразливість (CVSS 10.0), яку досі не виправив

Як працює Config Connector і де він ламається

Config Connector — це оператор Kubernetes, який дозволяє організаціям керувати ресурсами GCP (такими як хмарне сховище, бази даних і політики IAM) через команди Kubernetes . Він призначений для уніфікації інструментів: ви можете створювати, оновлювати та видаляти хмарні ресурси за допомогою kubectl, звичного інструменту командного рядка Kubernetes .

О'Лірі виявив, що цей уніфікований підхід має небезпечний побічний ефект. Вада дозволяє будь-якому користувачу Kubernetes-простору імен обійти контроль доступу та управління ідентифікацією (IAM) Google Cloud Platform. Розробник із базовим доступом лише до одного простору імен Kubernetes може використати це для отримання повного адміністративного контролю над усім середовищем GCP організації — фактично захопивши весь хмарний обліковий запис . О'Лірі розповів The Register, що експлойт можна виконати приблизно за п'ять секунд, не залишаючи жодного сліду в журналі аудиту .

Технічний механізм: підвищення привілеїв між просторами імен

Хоча Google не опублікував детального технічного опису, численні джерела та звіт О'Лірі вказують на те, що вразливість криється в тому, як Config Connector обробляє дозволи IAM у різних просторах імен Kubernetes .

У правильно налаштованому мультитенантному кластері GKE різні простори імен мають бути ізольовані — користувач у просторі імен A не повинен мати можливості керувати ресурсами в просторі імен B або надавати собі підвищені ролі GCP. Відкриття О'Лірі показує, що типи ресурсів IAM у Config Connector не забезпечують дотримання цих меж просторів імен . Створивши або змінивши ресурс політики IAM через Config Connector з одного простору імен, користувач із мінімальними дозволами Kubernetes може надати собі роль roles/owner у проекті GCP — або в усій організації .

Це порушення принципу найменших привілеїв і прямий обхід рівня авторизації IAM у GCP. Це не помилка конфігурації, яку адміністратор може виправити; це вада на рівні дизайну того, як Config Connector делегує повноваження IAM .

Хронологія: від "Молодець!" до "Працює за задумом"

Згідно з ексклюзивним звітом The Register від 18 червня 2026 року та іншими джерелами, події розгорталися наступним чином:

• Приблизно кінець березня / початок квітня 2026 року: О'Лірі виявляє ваду та подає детальний звіт до Cloud Vulnerability Reward Program (Cloud VRP) від Google. Звіт містить доказ концепції, який демонструє, як зловмисник може підвищити привілеї від користувача простору імен до власника організації GCP .
• Початкове сортування: Команда Google з винагород за помилки переглядає подання, класифікує його як високопріоритетну, високосерйозну вразливість, і представник Google особисто відповідає фразою "Молодець!" .
• Приблизно травень/червень 2026 року: Не випускаючи виправлення, Google змінює своє рішення. Компанія закриває звіт, оголошуючи, що така поведінка є "робочою за задумом" — тобто вона не підпадає під визначення вразливості згідно з правилами Cloud VRP. Жодної винагороди не виплачено .
• Станом на 18 червня 2026 року: Вада залишається невиправленою. Звіт О'Лірі, однак, досі позначений як "високопріоритетний" та "прийнятий" у системі відстеження Google — очевидна суперечність . Справу відкрито вже майже три місяці .

Чому Google міг відмовити у винагороді

Google публічно не пояснив свого рішення, але, виходячи з правил Cloud VRP та ширшого контексту змін у програмах Google 2026 року, можна припустити кілька факторів.

Офіційні правила Cloud VRP свідчать: "Звіти про вразливості Google Cloud, де тестувалися ресурси, що належать клієнтам, не підлягають винагороді." Сфера програми чітко обмежена вразливостями в інфраструктурі та сервісах, що належать Google, а не в компонентах, які налаштовує клієнт . Якщо Google вважав поведінку Config Connector питанням конфігурації клієнта, а не вразливістю продукту, він міг технічно відмовити у винагороді, навіть якщо така поведінка обходить очікувані контролі IAM.

Інша можливість: правила Cloud VRP визначають, що програма покриває "вади автентифікації або авторизації" в об'єктах, що входять до сфери дії, що має охоплювати знахідку О'Лірі . Але Google раніше стверджував в інших контекстах, що певні підвищення привілеїв не є помилками, якщо для їх активації потрібні специфічні дозволи — позиція, яка викликала критику дослідників . У випадку О'Лірі необхідний початковий дозвіл (доступ на рівні простору імен до ресурсів Config Connector) є мінімальним і часто надається розробникам, що робить ескалацію як реальною, так і небезпечною .

Третій фактор пов'язаний з переглядом Програми винагород за вразливості (VRP) 2026 року для Chrome та Android. Наприкінці квітня та на початку травня 2026 року Google оголосив про скорочення виплат для Chrome та реструктуризацію винагород, посилаючись на сплеск низькоякісних AI-згенерованих звітів . Компанія заявила, що "зменшує деякі суми винагород та бонусів для Android та Chrome", щоб зосередитися на "якості та реальному впливі, а не на простій кількості" . Хоча справа О'Лірі підпадає під окрему Cloud VRP, а не програми для Chrome або Android, публічна позиція компанії щодо посилення виплат могла вплинути на рішення — особливо якщо Google розглядав проблему Config Connector як дизайнерський вибір, а не помилку .

Зростаюча критика з боку дослідників

Інцидент викликав критику з боку спільноти дослідників безпеки, деякі з яких стверджують, що Google використовує наратив про AI-звіти як привід для відмови в законних, вручну виявлених вразливостях . Коментар PC Perspective назвав рішення "скупістю на винагороди за помилки" та зазначив невідповідність між початковою похвалою Google і остаточною відмовою . Cyber News Live підкреслив, що вада може дозволити захоплення за п'ять секунд без жодного запису .

Справа також виникла в той час, коли Google одночасно збільшує верхні винагороди для певних категорій помилок Android — до 1,5 мільйона доларів за постійні zero-click експлойти Titan M . Цей двосторонній підхід — щедра винагорода за глибокі апаратні експлойти при одночасній відмові навіть у визнанні серйозних обходів IAM — підживлює сприйняття того, що програми винагород Google стратегічно розподіляють бюджети, а не чесно оцінюють ризики .

Що це означає для організацій, які використовують Config Connector

Організації, які використовують Config Connector у мультитенантних або спільних кластерах GKE, повинні розцінювати це як терміновий, невиправлений ризик. Без офіційного виправлення від Google наступні заходи можуть зменшити ризик:

• Обмежте створення ресурсів iam* на рівні простору імен за допомогою політик RBAC Kubernetes. Не надавайте дозволів create, update або Delete на спеціальних ресурсах IAMPolicy, IAMPolicyMember або IAMPartialPolicy для ненадійних просторів імен.
• Використовуйте просторово-іменний режим Config Connector з окремими сервісними обліковими записами з низькими привілеями для кожного простору імен. Документація Google підтримує таку конфігурацію, яка обмежує радіус вибуху .
• Моніторте зміни IAM у GCP з боку Config Connector. Увімкніть журнали аудиту та налаштуйте сповіщення для будь-яких викликів setIamPolicy, що надходять з вашого кластера GKE.
• Розгляньте можливість вимкнення Config Connector у середовищах, де потрібна мультитенантна ізоляція, доки Google не усуне вразливість.

Офіційна документація Google щодо захисту доступу до ресурсів за допомогою IAM описує рекомендовані конфігурації, але не розглядає вектор обходу між просторами імен, який лежить в основі звіту О'Лірі . Організації повинні вважати свої розгортання Config Connector потенційно вразливими.

Ключові висновки

• Вада підвищення привілеїв у Google Config Connector (CVSS 10.0) дозволяє будь-якому користувачу простору імен Kubernetes отримати повне право власності на проект GCP.
• Команда Google з винагород за помилки спочатку прийняла звіт як високопріоритетний, а потім змінила рішення, оголосивши поведінку "робочою за задумом" та відмовивши у винагороді.
• Майже через три місяці після першого звіту вразливість залишається невиправленою, і Google не надав термінів виправлення.
• Інцидент відбувається на тлі ширших змін у програмах Google 2026 року, які скорочують виплати для Chrome, але збільшують винагороди для Android, ускладнюючи відносини компанії з дослідниками безпеки.