Google řekl "Dobrý úlovek!" a pak odmítl vyplatit odměnu za kritickou chybu, kterou stále neopravil

Jak funguje Config Connector a kde je problém

Config Connector je Kubernetes operátor, který organizacím umožňuje spravovat GCP zdroje – jako cloudové úložiště, databáze nebo IAM politiky – pomocí Kubernetes příkazů . Jeho cílem je sjednotit nástroje: cloudové zdroje lze vytvářet, upravovat a mazat pomocí kubectl, známého nástroje příkazové řádky Kubernetes .

O'Leary zjistil, že tento jednotný přístup má nebezpečný vedlejší efekt. Zranitelnost umožňuje kterémukoli uživateli Kubernetes namespaceu obejít kontroly Identity and Access Management (IAM) od Google Cloud Platform. Vývojář se základním přístupem do jediného Kubernetes namespaceu může tuto chybu zneužít k získání plné administrativní kontroly nad celým GCP prostředím organizace – de facto ovládne celý cloudový účet . O'Leary podle deníku The Register uvedl, že exploit lze provést asi za pět sekund a nezanechá po sobě žádný auditní záznam .

Technický mechanismus: Eskalace oprávnění napříč namespacey

Google sice nezveřejnil podrobný technický popis, ale z více zdrojů a z O'Learyho zprávy vyplývá, že chyba spočívá ve způsobu, jakým Config Connector nakládá s IAM oprávněními napříč různými Kubernetes namespacey .

Ve správně nakonfigurovaném multi-tenantovém GKE clusteru mají být namespacey izolované – uživatel v namespaceu A by neměl mít možnost spravovat zdroje v namespaceu B nebo si sám přidělit zvýšené GCP role. O'Learyho objev ukazuje, že IAM resource typy Config Connectoru tato hranice namespaceů nevynucují . Vytvořením nebo úpravou IAM politiky prostřednictvím Config Connectoru z jediného namespaceu si může uživatel s minimálními Kubernetes oprávněními přidělit roli roles/owner na projektu GCP – nebo na celé organizaci .

Jde o porušení principu nejmenších oprávnění a přímé obejití autorizační vrstvy IAM. Nejedná se o chybnou konfiguraci, kterou by mohl správce opravit – je to designová vada v tom, jak Config Connector deleguje IAM autoritu .

Časová osa: Od "Dobrý úlovek!" k "Zamýšlené chování"

Podle exkluzivní zprávy deníku The Register z 18. června 2026 a dalších zdrojů události probíhaly následovně:

• Konec března / začátek dubna 2026 (přibližně): O'Leary objevuje chybu a podává podrobnou zprávu do programu Cloud Vulnerability Reward Program (Cloud VRP). Zpráva obsahuje proof-of-concept demonstrující, jak může útočník eskalovat z uživatele namespaceu na vlastníka celé GCP organizace .
• Prvotní třídění: Tým bug bounty Googlu hlášení přezkoumá, zařadí ho jako vysoce prioritní a vysoce závažné. Zástupce Googlu osobně odpovídá slovy "Nice catch!" .
• ~Květen/červen 2026: Aniž by vydal opravu, Google své rozhodnutí obrací. Firma hlášení uzavírá s tím, že chování je "zamýšlené" – tedy že se nejedná o zranitelnost podle pravidel Cloud VRP. Žádná odměna není vyplacena .
• K 18. červnu 2026: Chyba stále není opravena. O'Learyho hlášení je však v systému Googlu stále označeno jako "vysoce prioritní" a "přijaté" – zřejmý rozpor . Případ je otevřený již téměř tři měsíce .

Proč Google odměnu zamítl?

Google své obrácení veřejně nevysvětlil, ale v úvahu připadá několik faktorů na základě pravidel Cloud VRP a širšího kontextu změn programu v roce 2026.

Oficiální pravidla Cloud VRP uvádějí: "Hlášení o zranitelnostech Google Cloud, kde byly testovány zdroje vlastněné zákazníkem, nemají nárok na odměny." Rozsah programu je výslovně omezen na zranitelnosti infrastruktury a služeb vlastněných Googlem, nikoli na komponenty konfigurovatelné zákazníkem . Pokud Google považoval chování Config Connectoru za věc zákaznické konfigurace spíše než za produktovou chybu, mohl odměnu technicky zamítnout – i když chování obchází očekávané IAM kontroly.

Další možnost: pravidla Cloud VRP uvádějí, že program pokrývá "chyby v autentizaci nebo autorizaci" u položek v rozsahu, což by mělo O'Learyho nález zahrnovat . Google ale v minulosti v jiných souvislostech argumentoval, že určité eskalace oprávnění nejsou chyby, pokud vyžadují specifická oprávnění ke spuštění – což se setkalo s kritikou výzkumníků . V O'Learyho případě je vyžadované počáteční oprávnění (přístup na úrovni namespaceu k prostředkům Config Connectoru) minimální a běžně přidělované vývojářům, což eskalaci činí reálnou i nebezpečnou .

Třetím faktorem jsou změny programu odměn za zranitelnosti pro Chrome a Android v roce 2026. Koncem dubna a začátkem května 2026 Google oznámil, že snižuje výplaty za Chrome a restrukturalizuje odměny s odkazem na nápor nekvalitních hlášení generovaných AI . Firma uvedla, že "snižuje některé částky odměn a bonusů napříč Androidem a Chromem", aby se zaměřila na "kvalitu a reálný dopad namísto pouhého objemu" . Ačkoli O'Learyho případ spadá pod samostatný Cloud VRP, nikoli programy pro Chrome nebo Android, veřejné zpřísňování výplat ze strany Googlu mohlo rozhodnutí ovlivnit – zvláště pokud firma problém Config Connectoru vnímala jako designové rozhodnutí spíše než chybu .

Rostoucí odpor výzkumníků

Incident vyvolal kritiku ze strany bezpečnostní komunity. Někteří tvrdí, že Google využívá vyprávění o AI hlášeních jako záminku k odmítání legitimních, ručně objevených zranitelností . Komentář PC Perspective označil rozhodnutí za "škudlení na bug bounties" a poukázal na rozpor mezi počáteční chválou a konečným odmítnutím . Cyber News Live zdůraznil, že chyba umožňuje převzetí kontroly během pěti sekund bez zanechání stop .

Případ přichází v době, kdy Google současně zvyšuje maximální odměny za určité kategorie chyb v Androidu – až na 1,5 milionu dolarů za zero-click exploit s perzistencí v Titan M . Tento dvojí přístup – štědré odměňování hlubokých hardwarových exploitů a zároveň odepření byť jen uznání za závažné obejití cloudového IAM – posiluje vnímání, že Google ve svých bug bounty programech strategicky alokuje rozpočty, místo aby čestně posuzoval rizika .

Co to znamená pro organizace používající Config Connector

Organizace provozující Config Connector v multi-tenantových nebo sdílených GKE clusterech by to měly brát jako naléhavé, neopravené riziko. Bez oficiální záplaty od Googlu mohou následující opatření snížit expozici:

• Omezte vytváření iam* zdrojů na úrovni namespaceu pomocí Kubernetes RBAC politik. Nepřidělujte oprávnění create, update ani Delete na vlastní zdroje IAMPolicy, IAMPolicyMember nebo IAMPartialPolicy nedůvěryhodným namespaceům.
• Používejte namespace režim Config Connectoru s oddělenými, málo privilegovanými servisními účty pro každý namespace. Dokumentace Googlu tuto konfiguraci podporuje a omezuje dopad případného průniku .
• Monitorujte změny IAM v GCP pocházející z Config Connectoru. Zapněte auditní logy a nastavte upozornění na všechna volání setIamPolicy přicházející z vašeho GKE clusteru.
• Zvažte dočasné vypnutí Config Connectoru v prostředích, kde je vyžadována multi-tenantová izolace, dokud Google chybu nevyřeší.

Oficiální dokumentace Googlu k zabezpečení přístupu ke zdrojům pomocí IAM popisuje doporučené konfigurace, ale neřeší vektor obcházení napříč namespacey, který je jádrem O'Learyho hlášení . Organizace by měly předpokládat, že jejich nasazení Config Connectoru může být zranitelné.

Klíčové body

• Chyba eskalace oprávnění v nástroji Google Config Connector (CVSS 10,0) umožňuje kterémukoli uživateli Kubernetes namespaceu získat plné vlastnictví projektu GCP.
• Tým bug bounty Googlu hlášení nejprve přijal jako vysoce prioritní, poté obrátil a prohlásil chování za "zamýšlené" a odměnu zamítl.
• Téměř tři měsíce po prvotním hlášení zranitelnost stále není opravena a Google neuvedl žádný termín opravy.
• Incident se odehrává na pozadí širších změn programu Googlu v roce 2026, které snižují výplaty za Chrome a zvyšují odměny za Android, což komplikuje vztahy firmy s bezpečnostními výzkumníky.