Google sagde 'Nice catch!' – men nægtede dusør for alvorlig sårbarhed, der stadig er uløst

En kritisk sikkerhedssårbarhed i Googles Config Connector – en Kubernetes-operator, der bruges til at administrere Google Cloud Platform (GCP)-ressourcer – er blevet centrum for en voksende kontrovers om Googles bounty-praksis. Sikkerhedsforsker Justin O'Leary opdagede fejlen, der har fået den maksimale CVSS-score på 10.0, og rapporterede den til Googles bug bounty-team. Teamet accepterede først rapporten, markerede den som høj prioritet og roste O'Leary med et 'Nice catch!' . Derefter ændrede Google kurs, erklærede, at adfærden var 'working as intended', afviste dusøren og lod fejlen være uløst i næsten tre måneder . Sagen har rejst spørgsmål om Googles engagement i sikkerhedsforskning – især samtidig med, at virksomheden omstrukturerer sine bounty-programmer med henvisning til en strøm af AI-genererede indsendelser .

Hvordan Config Connector fungerer – og hvor det går galt

Config Connector er en Kubernetes-operator, der giver organisationer mulighed for at administrere GCP-ressourcer – såsom cloud-lager, databaser og IAM-politikker – via Kubernetes-kommandoer . Det er designet til at samle værktøjer: Du kan oprette, opdatere og slette cloud-ressourcer ved hjælp af kubectl, det velkendte Kubernetes-kommandolinjeværktøj .

O'Leary fandt, at denne samlede tilgang kommer med en farlig bivirkning. Fejlen gør det muligt for enhver Kubernetes-namespace-bruger at omgå Google Cloud Platforms Identity and Access Management (IAM)-kontroller. En udvikler med basisadgang til ét enkelt Kubernetes-namespace kan udnytte dette til at opnå fuld administrativ kontrol over en hel organisations GCP-miljø – reelt set eje hele cloud-kontoen . O'Leary fortalte til The Register, at udnyttelsen kan udføres på omkring fem sekunder, uden at der efterlades et revisionsspor .

Den tekniske mekanisme: Tværgående navneområde-privilegieeskalering

Selvom Google ikke har offentliggjort en detaljeret teknisk beskrivelse, angiver flere kilder og O'Learys rapport, at sårbarheden ligger i, hvordan Config Connector håndterer IAM-rettigheder på tværs af forskellige Kubernetes-navneområder .

I et korrekt konfigureret multi-tenant GKE-klynge bør forskellige navneområder være isolerede – en bruger i navneområde A bør ikke kunne administrere ressourcer i navneområde B eller give sig selv forhøjede GCP-roller. O'Learys opdagelse viser, at Config Connectors IAM-ressourcetyper ikke håndhæver disse navneområde-grænser . Ved at oprette eller ændre en IAM-politikressource via Config Connector fra et enkelt navneområde, kan en bruger med minimale Kubernetes-rettigheder give sig selv rollen roles/owner på GCP-projektet – eller hele organisationen .

Dette er en krænkelse af princippet om mindste rettighed og en direkte omgåelse af GCP's IAM-autorisationslag. Det er ikke en fejlkonfiguration, som en administrator kan rette; det er en designfejl i, hvordan Config Connector delegerer IAM-autoritet .

Tidslinjen: Fra 'Nice catch!' til 'Working as intended'

Ifølge The Registers eksklusive rapport af 18. juni 2026 og bekræftende kilder forløb tidslinjen som følger:

• Slut marts / start april 2026 (omtrentlig): O'Leary opdager fejlen og indsender en detaljeret rapport til Googles Cloud Vulnerability Reward Program (Cloud VRP). Rapporten inkluderer et proof-of-concept, der viser, hvordan en angriber kan eskalere fra navneområdebruger til GCP-organisationsejer .
• Første gennemgang: Googles bug bounty-team gennemgår indsendelsen, kategoriserer den som en høj-prioritet, høj-alvorlighedssårbarhed, og en Google-repræsentant svarer personligt med 'Nice catch!' .
• ~Maj/juni 2026: Uden at udstede en rettelse omgør Google sin beslutning. Virksomheden lukker rapporten og erklærer, at adfærden er 'working as intended' – hvilket betyder, at den ikke kvalificerer sig som en sårbarhed under Cloud VRP-reglerne. Der udbetales ingen dusør .
• Pr. 18. juni 2026: Fejlen forbliver uløst. O'Learys fejlrapport er dog stadig markeret som 'høj prioritet' og 'accepteret' i Googles sporingssystem – en tilsyneladende modsigelse . Sagen har været åben i næsten tre måneder .

Hvorfor Google kan have afvist dusøren

Google har ikke offentligt forklaret sin omgørelse, men flere faktorer kan spille ind baseret på Cloud VRP-reglerne og den bredere kontekst af Googles programændringer i 2026.

De officielle Cloud VRP-regler siger: 'Google Cloud-sårbarhedsrapporter, hvor kundeejede ressourcer blev testet, er ikke berettiget til dusører.' Programmets omfang er udtrykkeligt begrænset til sårbarheder i Google-ejet infrastruktur og -tjenester, ikke i kundekonfigurerbare komponenter . Hvis Google betragtede Config Connectors adfærd som et spørgsmål om kundekonfiguration snarere end en produktsårbarhed, kunne det teknisk set afvise dusøren under denne formulering – selvom adfærden omgår forventede IAM-kontroller.

En anden mulighed: Cloud VRP-reglerne specificerer, at programmet dækker 'autentificerings- eller autorisationsfejl' i omfattede elementer, hvilket burde dække O'Learys fund . Men Google har tidligere argumenteret i andre sammenhænge for, at visse privilegieeskaleringer ikke er fejl, hvis de kræver specifikke rettigheder for at udløse – en holdning, der har mødt kritik fra forskere . I O'Learys tilfælde er den nødvendige indledende tilladelse (navneområde-niveau adgang til Config Connector-ressourcer) minimal og almindeligt givet til udviklere, hvilket gør eskaleringen både reel og farlig .

En tredje faktor relaterer sig til Googles 2026-omlægning af Vulnerability Reward Program for Chrome og Android. I slutningen af april og starten af maj 2026 annoncerede Google, at det skar i Chrome-udbetalingerne og omstrukturerede dusørerne med henvisning til en bølge af AI-genererede lavkvalitetsindsendelser . Virksomheden udtalte, at det 'reducerer nogle dusørbeløb og bonusser på tværs af Android og Chrome' for at fokusere på 'kvalitet og reel effekt frem for ren mængde' . Selvom O'Learys sag falder under det separate Cloud VRP, ikke Chrome- eller Android-programmerne, kan virksomhedens offentlige holdning om at stramme udbetalingerne have påvirket beslutningen – især hvis Google så Config Connector-problemet som et designvalg frem for en fejl .

Voksende forsker-modstand

Hændelsen har udløst kritik fra sikkerhedsforskningsmiljøet, hvor nogle argumenterer for, at Google bruger AI-indsendelsesfortællingen som dække for at afvise legitime, manuelt opdagede sårbarheder . PC Perspectives kommentar kaldte beslutningen 'at blive gerrig med bug bounties' og påpegede uoverensstemmelsen mellem Googles indledende ros og dets endelige afvisning . Cyber News Live fremhævede, at fejlen kunne muliggøre en fem-sekunders overtagelse uden noget spor .

Sagen kommer også på et tidspunkt, hvor Google samtidig hæver topdusørerne for visse kategorier af Android-fejl – op til 1,5 millioner dollars for vedvarende Titan M zero-click exploits . Denne todelte tilgang – at belønne dybe hardwareudnyttelser generøst, mens man nægter selv anerkendelse for alvorlige cloud IAM-omgåelser – har næret opfattelsen af, at Googles bug bounty-programmer strategisk allokerer budgetter snarere end ærligt vurderer risiko .

Hvad dette betyder for organisationer, der bruger Config Connector

Organisationer, der kører Config Connector i multi-tenant eller delte GKE-klynger, bør betragte dette som en akut, ulappet risiko. Uden en officiel rettelse fra Google kan følgende afhjælpninger reducere eksponeringen:

• Begræns iam* ressourceoprettelse på navneområdeniveau ved hjælp af Kubernetes RBAC-politikker. Giv ikke create, update eller Delete-tilladelser på IAMPolicy, IAMPolicyMember eller IAMPartialPolicy-brugerdefinerede ressourcer til ikke-pålidelige navneområder.
• Brug namespace-mode Config Connector med separate, lavt-rettigheds servicekonti pr. navneområde. Googles dokumentation understøtter denne konfiguration, hvilket begrænser eksplosionsradiusen .
• Overvåg GCP IAM-ændringer fra Config Connector-oprindelse. Aktivér revisionslogfiler og opsæt alarmer for ethvert setIamPolicy-kald, der stammer fra din GKE-klynge.
• Overvej at deaktivere Config Connector i miljøer, hvor multi-tenant-isolering er påkrævet, indtil Google løser sårbarheden.

Googles officielle dokumentation om sikring af adgang til ressourcer med IAM beskriver anbefalede konfigurationer, men adresserer ikke den tværgående navneområde-omgåelsesvektor, der er kernen i O'Learys rapport . Organisationer bør antage, at deres Config Connector-installationer kan være sårbare.

Vigtige pointer

• En privilegieeskaleringsfejl i Googles Config Connector (CVSS 10.0) gør det muligt for enhver Kubernetes-navneområdebruger at opnå fuldt ejerskab af GCP-projektet.
• Googles bug bounty-team accepterede først rapporten som høj prioritet, omgjorde derefter kursen, erklærede den 'working as intended' og afviste en dusør.
• Næsten tre måneder efter den oprindelige rapport forbliver sårbarheden uløst uden en tidsplan for en rettelse fra Google.
• Hændelsen finder sted i lyset af Googles bredere programændringer i 2026, der skærer i Chrome-udbetalinger, mens de hæver Android-dusører, hvilket komplicerer virksomhedens forhold til sikkerhedsforskere.