Google sa ”Nice catch!” – nekar sedan buggbounty för kritisk sårbarhet som fortfarande inte är åtgärdad

Hur Config Connector fungerar – och var det brister

Config Connector är en Kubernetes-operator som gör det möjligt för organisationer att hantera GCP-resurser – som molnlagring, databaser och IAM-policyer – via Kubernetes-kommandon . Tanken är att förena verktygen: du kan skapa, uppdatera och ta bort molnresurser med kubectl, det välbekanta Kubernetes-kommandoradsverktyget .

O’Leary upptäckte att detta enhetliga angreppssätt har en farlig baksida. Felet gör att vilken Kubernetes-namnrymdsanvändare som helst kan kringgå Google Cloud Platforms Identity and Access Management (IAM)-kontroller. En utvecklare som bara har grundläggande åtkomst till en enda Kubernetes-namnrymd skulle kunna utnyttja detta för att få full administrativ kontroll över en hel organisations GCP-miljö – i praktiken äga hela molnkontot . O’Leary berättade för The Register att sårbarheten kan utnyttjas på cirka fem sekunder, utan att något spår lämnas i loggen .

Den tekniska mekanismen: privilegieeskalering över namnrymdsgränser

Google har inte publicerat en detaljerad teknisk beskrivning, men flera källor och O’Learys rapportering visar att sårbarheten ligger i hur Config Connector hanterar IAM-behörigheter över olika Kubernetes-namnrymder .

I en korrekt konfigurerad fleranvändarkluster (multi-tenant GKE-kluster) ska olika namnrymder vara isolerade – en användare i namnrymd A ska inte kunna hantera resurser i namnrymd B eller ge sig själv förhöjda GCP-roller. O’Learys upptäckt visar att Config Connectors IAM-resurstyper inte upprätthåller dessa namnrymdsgränser . Genom att skapa eller ändra en IAM-policyresurs via Config Connector från en enda namnrymd kan en användare med minimala Kubernetes-behörigheter ge sig själv rollen roles/owner på GCP-projektet – eller hela organisationen .

Detta är ett brott mot principen om minsta möjliga behörighet (principle of least privilege) och en direkt förbikoppling av GCP:s IAM-auktoriseringslager. Det är inte en felkonfiguration som en administratör kan åtgärda; det är en designrelaterad brist i hur Config Connector delegerar IAM-auktoritet .

Tidslinjen: från ”Nice catch!” till ”Working as intended”

Enligt The Registers exklusiva rapport den 18 juni 2026 och bekräftande källor såg tidslinjen ut så här:

• Slutet av mars/början av april 2026 (ungefärligt): O’Leary upptäcker felet och skickar en detaljerad rapport till Googles Cloud Vulnerability Reward Program (Cloud VRP). Rapporten innehåller en proof of concept som visar hur en angripare kan gå från namnrymdsanvändare till ägare av hela GCP-organisationen .
• Första granskningen: Googles buggbounty-team granskar inlämningen, kategoriserar den som högprioriterad och hög allvarlighetsgrad, och en Google-representant svarar personligen med ”Nice catch!” .
• Maj/juni 2026: Utan att utfärda en korrigering ändrar Google sig. Företaget avslutar rapporten och förklarar att beteendet ”fungerar som avsett” – det vill säga att det inte kvalificerar sig som en sårbarhet enligt reglerna för Cloud VRP. Ingen belöning betalas ut .
• Per den 18 juni 2026: Felet är fortfarande opatchat. O’Learys buggrapport är dock fortfarande markerad som ”högprioriterad” och ”accepterad” i Googles spårningssystem – en uppenbar motsägelse . Ärendet har varit öppet i nästan tre månader .

Varför Google kan ha nekat belöningen

Google har inte offentligt förklarat sitt omslag, men flera faktorer kan spela in, baserat på reglerna för Cloud VRP och den bredare kontexten av Googles programförändringar 2026.

De officiella reglerna för Cloud VRP säger: ”Google Cloud vulnerability reports where customer-owned resources were tested are ineligible for rewards.” Programmets omfattning är uttryckligen begränsad till sårbarheter i Google-ägd infrastruktur och tjänster, inte i kundkonfigurerbara komponenter . Om Google ansåg att Config Connectors beteende var en fråga om kundkonfiguration snarare än en produktsårbarhet, skulle de tekniskt sett kunna neka belöningen enligt denna formulering – även om beteendet kringgår förväntade IAM-kontroller.

En separat möjlighet: Cloud VRP-reglerna anger att programmet täcker ”authentication or authorization flaws” i omfattade objekt, vilket borde täcka O’Learys fynd . Men Google har tidigare i andra sammanhang argumenterat för att vissa privilegieeskaleringar inte är buggar om de kräver specifika behörigheter för att utlösas – en hållning som har fått kritik från forskare . I O’Learys fall är den nödvändiga initiala behörigheten (åtkomst på namnrymdsnivå till Config Connector-resurser) minimal och vanligt given till utvecklare, vilket gör eskaleringen både verklig och farlig .

En tredje faktor har att göra med Googles översyn av Vulnerability Reward Program 2026 för Chrome och Android. I slutet av april och början av maj 2026 meddelade Google att man skär ner Chrome-utbetalningarna och omstrukturerar belöningarna, med hänvisning till en ökning av AI-genererade bidrag av låg kvalitet . Företaget uppgav att man ”minskar några belopp och bonusar för Android och Chrome” för att fokusera på ”kvalitet och verklig påverkan framför enbart volym” . Även om O’Learys fall faller under det separata Cloud VRP, inte Chrome- eller Android-programmen, kan företagets offentliga hållning om att strama åt utbetalningarna ha påverkat beslutet – särskilt om Google såg Config Connector-problemet som ett designval snarare än en bugg .

Växande missnöje bland forskare

Incidenten har väckt kritik från säkerhetsforskningssamhället, där vissa menar att Google använder AI-berättelsen som täckmantel för att neka legitimt, manuellt upptäckta sårbarheter . PC Perspectives kommentar kallade beslutet ”snålt med buggbounty” och noterade diskrepansen mellan Googles initiala beröm och det slutliga avslaget . Cyber News Live lyfte fram att felet skulle kunna möjliggöra en fem sekunders övertagning utan spår .

Fallet kommer också i en tid när Google samtidigt ökar maxbelöningarna för vissa kategorier av Android-buggar – upp till 1,5 miljoner dollar för beständiga Titan M zero-click-exploats . Denna tvådelade strategi – att belöna djupa hårdvaruexploater generöst medan man till och med nekar erkännande för allvarliga IAM-förbikopplingar i molnet – har underblåst uppfattningen att Googles buggbounty-program strategiskt fördelar budgetar snarare än att ärligt bedöma risker .

Vad detta innebär för organisationer som använder Config Connector

Organisationer som kör Config Connector i fleranvändar- eller delade GKE-kluster bör behandla detta som en akut, opatchad risk. Utan officiell patch från Google kan följande åtgärder minska exponeringen:

• Begränsa skapandet av iam*-resurser på namnrymdsnivå med Kubernetes RBAC-policyer. Ge inte create, update eller Delete-behörigheter på anpassade resurser som IAMPolicy, IAMPolicyMember eller IAMPartialPolicy till ej betrodda namnrymder.
• Använd Config Connector i namnrymdsläge (namespace mode) med separata, lågprivilegierade tjänstekonton per namnrymd. Googles dokumentation stöder denna konfiguration, vilket begränsar skadeomfattningen .
• Övervaka GCP IAM-ändringar som kommer från Config Connector. Aktivera granskningsloggar och sätt upp varningar för alla setIamPolicy-anrop som kommer från ditt GKE-kluster.
• Överväg att inaktivera Config Connector i miljöer där isolering mellan flera användare krävs, tills Google åtgärdar sårbarheten.

Googles officiella dokumentation om att skydda åtkomsten till resurser med IAM beskriver rekommenderade konfigurationer men tar inte upp den korsande namnrymdsförbikopplingsvektor som är kärnan i O’Learys rapport . Organisationer bör anta att deras Config Connector-installationer kan vara sårbara.

Viktiga slutsatser

• En privilegieeskaleringssårbarhet i Googles Config Connector (CVSS 10.0) gör att vilken Kubernetes-namnrymdsanvändare som helst kan få fullt ägarskap över GCP-projektet.
• Googles buggbounty-team accepterade först rapporten som högprioriterad, men ändrade sig sedan och deklarerade att beteendet ”fungerar som avsett” och nekade belöningen.
• Nästan tre månader efter den ursprungliga rapporten är sårbarheten fortfarande opatchad utan tidsplan för åtgärd från Google.
• Incidenten inträffar mot bakgrund av Googles bredare programförändringar 2026 som sänker Chrome-utbetalningarna samtidigt som Android-belöningarna höjs, vilket komplicerar företagets relation med säkerhetsforskare.