Google sa «Nice Catch!» – så nektet de pengebelønning for en CVSS 10.0-sikkerhetsfeil de fortsatt ikke har rettet

Hvordan Config Connector fungerer – og hvor det svikter

Config Connector er en Kubernetes-operator som lar organisasjoner administrere GCP-ressurser – som skylagring, databaser og IAM-policyer – via Kubernetes-kommandoer . Det er designet for å samle verktøy: du kan opprette, oppdatere og slette skyressurser med kubectl, det kjente Kubernetes-kommandolinjeverktøyet .

O'Leary fant at denne enhetlige tilnærmingen har en farlig bivirkning. Feilen lar enhver Kubernetes-navnerombruker omgå Google Cloud Platforms Identity and Access Management (IAM)-kontroller. En utvikler med grunnleggende tilgang til bare ett Kubernetes-navnerom kan utnytte dette til å få full administrativ kontroll over hele organisasjonens GCP-miljø – og i praksis eie hele skykontoen . O'Leary fortalte The Register at utnyttelsen kan utføres på omtrent fem sekunder, uten å etterlate seg noen revisjonsspor .

Den tekniske mekanismen: Rettighetsutvidelse på tvers av navnerom

Selv om Google ikke har offentliggjort en detaljert teknisk beskrivelse, indikerer flere kilder og O'Learys rapportering at sårbarheten ligger i hvordan Config Connector håndterer IAM-tillatelser på tvers av forskjellige Kubernetes-navnerom .

I en riktig konfigurert GKE-klynge for flere leietakere er forskjellige navnerom ment å være isolert – en bruker i navnerom A skal ikke kunne administrere ressurser i navnerom B eller gi seg selv forhøyede GCP-roller. O'Learys oppdagelse viser at Config Connectors IAM-ressurstyper ikke håndhever disse navneromsgrensene . Ved å opprette eller endre en IAM-policyressurs via Config Connector fra et enkelt navnerom, kan en bruker med minimale Kubernetes-tillatelser gi seg selv roles/owner-rollen på GCP-prosjektet – eller hele organisasjonen .

Dette er et brudd på prinsippet om minste privilegium og en direkte omgåelse av GCPs IAM-autorisasjonslag. Det er ikke en feilkonfigurasjon som en administrator kan fikse; det er en designfeil i hvordan Config Connector delegerer IAM-autoritet .

Tidslinjen: Fra «Nice Catch!» til «Working as Intended»

Ifølge The Registers eksklusive rapport fra 18. juni 2026 og bekreftende kilder, forløp tidslinjen som følger:

• Slutten av mars / begynnelsen av april 2026 (omtrentlig): O'Leary oppdager feilen og sender en detaljert rapport til Googles Cloud Vulnerability Reward Program (Cloud VRP). Rapporten inkluderer en konseptbevis som viser hvordan en angriper kan eskalere fra navnerombruker til GCP-organisasjonseier .
• Første vurdering: Googles bug bounty-team gjennomgår innleveringen, kategoriserer den som høy prioritet og høy alvorlighetsgrad, og en Google-representant svarer personlig med «Nice catch!» .
• ~Mai/juni 2026: Uten å utstede en rettelse snur Google sin beslutning. Selskapet lukker rapporten og erklærer at oppførselen er «working as intended» – det kvalifiserer ikke som en sårbarhet under Cloud VRP-reglene. Ingen belønning utbetales .
• Per 18. juni 2026: Feilen forblir ulaust. O'Learys bug rapport er imidlertid fortsatt merket som «høy prioritet» og «akseptert» i Googles sporingssystem – en tilsynelatende selvmotsigelse . Saken har vært åpen i nesten tre måneder .

Hvorfor Google kan ha nektet belønningen

Google har ikke offentlig forklart hvorfor de snudde, men flere faktorer kan spille inn basert på Cloud VRP-reglene og den bredere konteksten av Googles programendringer i 2026.

De offisielle Cloud VRP-reglene sier: «Rapporter om Google Cloud-sårbarheter der kundeeide ressurser ble testet, er ikke kvalifisert for belønning.» Programmets omfang er uttrykkelig begrenset til sårbarheter i Googles egen infrastruktur og tjenester, ikke i kundekonfigurerbare komponenter . Hvis Google anså Config Connectors oppførsel som et spørsmål om kundekonfigurasjon snarere enn en produktsårbarhet, kunne de teknisk sett nekte belønningen under denne ordlyden – selv om oppførselen omgår forventede IAM-kontroller.

En annen mulighet: Cloud VRP-reglene spesifiserer at programmet dekker «autentiserings- eller autorisasjonsfeil» i omfattede elementer, noe som burde dekke O'Learys funn . Men Google har tidligere argumentert i andre sammenhenger at visse rettighetsutvidelser ikke er feil hvis de krever spesifikke tillatelser for å utløses – et standpunkt som har høstet kritikk fra forskere . I O'Learys tilfelle er den nødvendige starttillatelsen (navneromsnivåtilgang til Config Connector-ressurser) minimal og vanligvis gitt til utviklere, noe som gjør eskaleringen både reell og farlig .

En tredje faktor er knyttet til Googles 2026-omlegging av Vulnerability Reward Program for Chrome og Android. I slutten av april og begynnelsen av mai 2026 kunngjorde Google at de kutter Chrome-utbetalinger og omstrukturerer belønninger, med henvisning til en bølge av KI-genererte innleveringer av lav kvalitet . Selskapet uttalte at de «reduserer noen belønningssummer og bonuser på tvers av Android og Chrome» for å fokusere på «kvalitet og reell påvirkning fremfor ren mengde» . Selv om O'Learys sak faller inn under det separate Cloud VRP, ikke Chrome- eller Android-programmene, kan selskapets offentlige holdning om å stramme inn utbetalinger ha påvirket beslutningen – spesielt hvis Google så på Config Connector-problemet som et designvalg snarere enn en feil .

Voksende misnøye blant forskere

Hendelsen har utløst kritikk fra sikkerhetsforskningsmiljøet, der noen hevder at Google bruker KI-innleveringsfortellingen som et dekke for å avvise legitime, manuelt oppdagede sårbarheter . PC Perspectives kommentar kalte beslutningen «å bli gjerrig på bug bounties» og påpekte avviket mellom Googles første ros og den endelige avvisningen . Cyber News Live fremhevet at feilen kunne muliggjøre en fem-sekunders overtakelse uten å etterlate seg spor .

Saken kommer også på et tidspunkt da Google samtidig øker toppbelønningene for visse kategorier av Android-feil – opp til 1,5 millioner dollar for vedvarende Titan M null-klikk-utnyttelser . Denne to-delte tilnærmingen – å belønne dype maskinvareutnyttelser sjenerøst samtidig som man nekter selv anerkjennelse for alvorlige IAM-omgåelser i skyen – har næret oppfatninger om at Googles bug bounty-programmer strategisk allokerer budsjetter snarere enn å ærlig vurdere risiko .

Hva dette betyr for organisasjoner som bruker Config Connector

Organisasjoner som kjører Config Connector i GKE-klynger med flere leietakere eller delte klynger, bør behandle dette som en akutt, ulaust risiko. Uten en offisiell rettelse fra Google kan følgende tiltak redusere eksponeringen:

• Begrens opprettelse av iam*-ressurser på navneromsnivå ved hjelp av Kubernetes RBAC-policyer. Ikke gi create, update eller Delete-tillatelser på IAMPolicy, IAMPolicyMember eller IAMPartialPolicy-egendefinerte ressurser til upålitelige navnerom.
• Bruk navneromsmodus for Config Connector med distinkte tjenestekontoer med lave privilegier per navnerom. Googles dokumentasjon støtter denne konfigurasjonen, som begrenser skadeomfanget .
• Overvåk GCP IAM-endringer fra Config Connector-opprinnelse. Aktiver revisjonslogger og sett opp varsler for alle setIamPolicy-kall som stammer fra GKE-klyngen din.
• Vurder å deaktivere Config Connector i miljøer hvor isolasjon av flere leietakere er påkrevd, inntil Google løser sårbarheten.

Googles offisielle dokumentasjon om sikring av tilgang til ressurser med IAM beskriver anbefalte konfigurasjoner, men adresserer ikke omgåelsesvektoren på tvers av navnerom som er kjernen i O'Learys rapport . Organisasjoner bør anta at deres Config Connector-distribusjoner kan være sårbare.

Hovedpunkter

• En rettighetsutvidelsesfeil i Googles Config Connector (CVSS 10.0) lar enhver Kubernetes-navnerombruker få fullt eierskap over GCP-prosjektet.
• Googles bug bounty-team godtok først rapporten som høy prioritet, for så å snu og erklære det som 'working as intended' og nekte belønning.
• Nesten tre måneder etter den første rapporten er sårbarheten fortsatt ikke laust, og Google har ikke gitt noen tidslinje for rettelse.
• Hendelsen kommer i kjølvannet av Googles bredere programendringer i 2026, som kutter Chrome-utbetalinger samtidig som Android-belønninger økes, noe som kompliserer selskapets forhold til sikkerhetsforskere.