Google zei 'Goed gevangen!' maar weigerde bug bounty voor kritiek lek (CVSS 10.0) dat nog altijd openstaat

Een kritieke beveiligingslek in Google's Config Connector – een Kubernetes-operator voor het beheren van Google Cloud Platform (GCP)-resources – heeft geleid tot een groeiende controverse over Google's bugbountypraktijken. Beveiligingsonderzoeker Justin O'Leary ontdekte de fout, kreeg de maximale ernstscore CVSS 10.0, en meldde deze bij Google's bugbountyteam. Dat team accepteerde het rapport aanvankelijk, bestempelde het als 'hoge prioriteit' en prees O'Leary met een 'Nice catch!' . Daarna draaide Google bij: het gedrag werd 'werkt zoals bedoeld' verklaard, er werd geen beloning uitgekeerd en het lek bleef bijna drie maanden lang onverholpen . De zaak roept vragen op over Google's toewijding aan beveiligingsonderzoek – temeer omdat het bedrijf tegelijkertijd zijn bugbountyprogramma's herstructureert vanwege een toestroom van AI-gegenereerde inzendingen .

Hoe Config Connector werkt en waar het misgaat

Config Connector is een Kubernetes-operator waarmee organisaties GCP-resources – zoals cloudopslag, databases en IAM-beleid – kunnen beheren via Kubernetes-commando's . Het doel is om tools te verenigen: je kunt cloudresources aanmaken, bijwerken en verwijderen met kubectl, de vertrouwde Kubernetes-opdrachtregeltool .

O'Leary ontdekte dat deze uniforme aanpak een gevaarlijk neveneffect heeft. De fout stelt elke Kubernetes namespace-gebruiker in staat om de Identity and Access Management (IAM)-controles van Google Cloud Platform te omzeilen. Een ontwikkelaar met alleen basis toegang tot één Kubernetes namespace kan hiermee volledige beheerdersrechten over de hele GCP-omgeving van een organisatie krijgen – feitelijk het hele cloudaccount overnemen . O'Leary vertelde The Register dat de aanval in ongeveer vijf seconden uit te voeren is, zonder dat er een audit trail achterblijft .

Het technische mechanisme: privilege-escalatie over namespaces heen

Google heeft geen gedetailleerde technische beschrijving vrijgegeven, maar meerdere bronnen en O'Leary's eigen rapportage wijzen erop dat de kwetsbaarheid zit in de manier waarop Config Connector IAM-machtigingen afhandelt over verschillende Kubernetes-namespaces heen .

In een correct geconfigureerde multi-tenant GKE-cluster zouden verschillende namespaces geïsoleerd moeten zijn – een gebruiker in namespace A mag geen resources in namespace B kunnen beheren of zichzelf verhoogde GCP-rollen kunnen geven. O'Leary's ontdekking toont aan dat Config Connector's IAM-resourcetypen deze namespacegrenzen niet afdwingen . Door vanuit één namespace een IAM-beleidsresource via Config Connector aan te maken of aan te passen, kan een gebruiker met minimale Kubernetes-rechten zichzelf de rol roles/owner op het GCP-project geven – of op de hele organisatie .

Dit is een schending van het principe van 'least privilege' en een directe omzeiling van GCP's IAM-autorisatielaag. Het is geen verkeerde configuratie die een beheerder kan herstellen; het is een ontwerpfout in de manier waarop Config Connector IAM-bevoegdheden delegeert .

De tijdlijn: van 'Nice catch!' naar 'werkt zoals bedoeld'

Volgens het exclusieve rapport van The Register van 18 juni 2026 en ondersteunende bronnen verliep de tijdlijn als volgt:

• Eind maart / begin april 2026 (ongeveer): O'Leary ontdekt de fout en dient een gedetailleerd rapport in bij Google's Cloud Vulnerability Reward Program (Cloud VRP). Het rapport bevat een proof of concept die aantoont hoe een aanvaller van namespace-gebruiker kan escaleren naar GCP-organisatie-eigenaar .
• Eerste triage: Google's bugbountyteam beoordeelt de inzending, categoriseert deze als hoge prioriteit en hoge ernst, en een Google-medewerker reageert persoonlijk met 'Nice catch!' .
• ~mei/juni 2026: Zonder een reparatie uit te geven, draait Google zijn beslissing terug. Het bedrijf sluit het rapport en verklaart dat het gedrag 'werkt zoals bedoeld' is – het kwalificeert dus niet als een kwetsbaarheid onder de Cloud VRP-regels. Er wordt geen beloning uitgekeerd .
• Per 18 juni 2026: Het lek is nog steeds niet gerepareerd. O'Leary's bugrapport staat echter nog steeds als 'hoge prioriteit' en 'geaccepteerd' in Google's trackingsysteem – een duidelijke tegenstrijdigheid . De zaak is dan bijna drie maanden open .

Waarom Google de beloning mogelijk heeft geweigerd

Google heeft zijn beslissing niet publiekelijk toegelicht, maar op basis van de Cloud VRP-regels en de bredere context van Google's programmawijzigingen in 2026 spelen mogelijk verschillende factoren een rol.

De officiële Cloud VRP-regels stellen: “Google Cloud vulnerability reports where customer-owned resources were tested are ineligible for rewards.” Het programma beperkt zich expliciet tot kwetsbaarheden in door Google beheerde infrastructuur en diensten, niet in componenten die door klanten configureerbaar zijn . Als Google het gedrag van Config Connector beschouwt als een kwestie van klantconfiguratie in plaats van een productkwetsbaarheid, kon het de beloning technisch gezien weigeren op basis van deze formulering – zelfs als het gedrag de verwachte IAM-controles omzeilt.

Een andere mogelijkheid: de Cloud VRP-regels specificeren dat het programma “authenticatie- of autorisatiefouten” dekt in items die binnen de reikwijdte vallen, wat O'Leary's bevinding zou moeten dekken . Maar Google heeft in andere contexten eerder betoogd dat bepaalde privilege-escalaties geen bugs zijn als ze specifieke rechten vereisen om te activeren – een standpunt dat kritiek kreeg van onderzoekers . In O'Leary's geval is de vereiste initiële toestemming (toegang op namespace-niveau tot Config Connector-resources) minimaal en wordt deze vaak aan ontwikkelaars verleend, waardoor de escalatie zowel reëel als gevaarlijk is .

Een derde factor betreft Google's herziening van het Vulnerability Reward Program voor 2026 voor Chrome en Android. Eind april en begin mei 2026 kondigde Google aan dat het Chrome-uitkeringen verlaagde en beloningen herstructureerde vanwege een golf van AI-gegenereerde inzendingen van lage kwaliteit . Het bedrijf gaf aan “sommige beloningsbedragen en bonussen voor Android en Chrome te verlagen” om zich te richten op “kwaliteit en echte impact in plaats van louter volume” . Hoewel O'Leary's zaak onder het aparte Cloud VRP valt, niet onder de Chrome- of Android-programma's, kan het standpunt van het bedrijf over het aanscherpen van uitkeringen de beslissing hebben beïnvloed – vooral als Google het Config Connector-probleem als een ontwerpkeuze beschouwde in plaats van een bug .

Groeiende weerstand van onderzoekers

Het voorval heeft kritiek uit de beveiligingsonderzoeksgemeenschap opgeroepen. Sommigen stellen dat Google het AI-inzendingennarratief gebruikt als dekmantel om legitieme, handmatig ontdekte kwetsbaarheden te negeren . PC Perspective's commentaar noemde de beslissing “gierig worden met bug bounties” en wees op de discrepantie tussen Google's aanvankelijke lof en de uiteindelijke weigering . Cyber News Live benadrukte dat de fout een overname in vijf seconden mogelijk maakt zonder dat er een spoor achterblijft .

De zaak komt ook op een moment dat Google tegelijkertijd de hoogste beloningen verhoogt voor bepaalde categorieën Android-bugs – tot $1,5 miljoen voor persistente Titan M zero-click exploits . Deze tweesporige aanpak – diepe hardware-exploits royaal belonen terwijl er zelfs erkenning wordt geweigerd voor ernstige cloud IAM-omzeilingen – heeft de perceptie versterkt dat Google's bugbountyprogramma's strategisch budgetten toewijzen in plaats van risico's eerlijk te beoordelen .

Wat dit betekent voor organisaties die Config Connector gebruiken

Organisaties die Config Connector in multi-tenant of gedeelde GKE-clusters draaien, moeten dit beschouwen als een dringend, onopgelost risico. Zonder een officiële patch van Google kunnen de volgende maatregelen de blootstelling verminderen:

• Beperk het aanmaken van iam*-resources op namespace-niveau met behulp van Kubernetes RBAC-beleid. Verleen geen create-, update- of Delete-rechten op IAMPolicy, IAMPolicyMember of IAMPartialPolicy-custom resources aan niet-vertrouwde namespaces.
• Gebruik namespace-mode Config Connector met aparte, laag geprivilegieerde service accounts per namespace. Google's documentatie ondersteunt deze configuratie, die de impact beperkt .
• Monitor GCP IAM-wijzigingen die afkomstig zijn van Config Connector. Schakel audittrails in en stel waarschuwingen in voor setIamPolicy-aanroepen die vanuit je GKE-cluster komen.
• Overweeg Config Connector uit te schakelen in omgevingen waar multi-tenant isolatie vereist is, totdat Google de kwetsbaarheid heeft opgelost.

Google's officiële documentatie over het beveiligen van toegang tot resources met IAM beschrijft aanbevolen configuraties, maar gaat niet in op de cross-namespace bypass-vector die centraal staat in O'Leary's rapport . Organisaties moeten ervan uitgaan dat hun Config Connector-implementaties kwetsbaar kunnen zijn.

Kernpunten

• Een privilege-escalatiefout in Google's Config Connector (CVSS 10.0) stelt elke Kubernetes namespace-gebruiker in staat om volledig eigenaar te worden van het GCP-project.
• Google's bugbountyteam accepteerde het rapport aanvankelijk als hoge prioriteit, maar draaide bij en verklaarde het gedrag als 'werkt zoals bedoeld', waarmee een beloning werd geweigerd.
• Bijna drie maanden na het eerste rapport is de kwetsbaarheid nog steeds niet gerepareerd en is er geen reparatietermijn van Google.
• Het voorval speelt tegen de achtergrond van Google's bredere programmawijzigingen in 2026, die Chrome-uitkeringen verlagen terwijl Android-beloningen stijgen, wat de relatie met beveiligingsonderzoekers onder druk zet.