Google dice 'Bel colpo' ma nega il bug bounty: vulnerabilità CVSS 10.0 ancora senza fix

Come funziona Config Connector e dove si rompe

Config Connector è un operatore Kubernetes che consente alle organizzazioni di gestire le risorse GCP — come storage cloud, database e policy IAM — tramite comandi Kubernetes . È progettato per unificare gli strumenti: è possibile creare, aggiornare ed eliminare risorse cloud usando kubectl, il familiare strumento a riga di comando di Kubernetes .

O'Leary ha scoperto che questo approccio unificato ha un pericoloso effetto collaterale. La falla consente a qualsiasi utente di un namespace Kubernetes di bypassare i controlli Identity and Access Management (IAM) di Google Cloud Platform. Uno sviluppatore con accesso di base a un solo namespace Kubernetes potrebbe sfruttare questa vulnerabilità per ottenere il controllo amministrativo completo sull'intero ambiente GCP di un'organizzazione — di fatto impossessandosi dell'intero account cloud . O'Leary ha detto a The Register che l'exploit potrebbe essere eseguito in circa cinque secondi, senza lasciare traccia di audit .

Il meccanismo tecnico: escalation dei privilegi tra namespace

Sebbene Google non abbia rilasciato una descrizione tecnica dettagliata, molteplici fonti e la segnalazione di O'Leary indicano che la vulnerabilità risiede nel modo in cui Config Connector gestisce le autorizzazioni IAM attraverso diversi namespace Kubernetes .

In un cluster GKE multi-tenant configurato correttamente, diversi namespace dovrebbero essere isolati — un utente nel namespace A non dovrebbe essere in grado di gestire le risorse nel namespace B o concedersi ruoli GCP elevati. La scoperta di O'Leary mostra che i tipi di risorse IAM di Config Connector non applicano questi confini tra namespace . Creando o modificando una risorsa policy IAM tramite Config Connector da un singolo namespace, un utente con permessi Kubernetes minimi può concedersi il ruolo roles/owner sul progetto GCP — o sull'intera organizzazione .

Questa è una violazione del principio del privilegio minimo e un bypass diretto del livello di autorizzazione IAM di GCP. Non è una configurazione errata che un amministratore potrebbe risolvere; è un difetto a livello di progettazione nel modo in cui Config Connector delega l'autorità IAM .

La timeline: da 'Bel colpo!' a 'Funzionamento previsto'

Secondo il rapporto esclusivo del 18 giugno 2026 di The Register e fonti che lo corroborano, la timeline si è svolta come segue:

• Fine marzo/inizio aprile 2026 (approssimativamente): O'Leary scopre la falla e invia un rapporto dettagliato al Cloud Vulnerability Reward Program (Cloud VRP) di Google. Il rapporto include una prova di concetto che dimostra come un aggressore possa passare da utente di namespace a proprietario dell'organizzazione GCP .
• Triage iniziale: Il team di bug bounty di Google esamina la segnalazione, la categorizza come vulnerabilità ad alta priorità e alta gravità, e un rappresentante di Google risponde personalmente con 'Bel colpo!' .
• ~Maggio/Giugno 2026: Senza rilasciare una correzione, Google inverte la sua decisione. L'azienda chiude il rapporto, dichiarando che il comportamento è 'funzionamento previsto' — il che significa che non si qualifica come vulnerabilità secondo le regole del Cloud VRP. Non viene emessa alcuna ricompensa .
• Al 18 giugno 2026: La falla rimane non corretta. Il rapporto di bug di O'Leary, tuttavia, è ancora contrassegnato come 'alta priorità' e 'accettato' nel sistema di tracciamento di Google — un'apparente contraddizione . Il caso è aperto da quasi tre mesi .

Perché Google potrebbe aver negato la ricompensa

Google non ha spiegato pubblicamente il suo dietrofront, ma diversi fattori potrebbero essere in gioco in base alle regole del Cloud VRP e al contesto più ampio dei cambiamenti del programma 2026 di Google.

Le regole ufficiali del Cloud VRP affermano: “I rapporti di vulnerabilità di Google Cloud in cui sono state testate risorse di proprietà del cliente non sono idonei per le ricompense.” L'ambito del programma è esplicitamente limitato alle vulnerabilità nell'infrastruttura e nei servizi di proprietà di Google, non nei componenti configurabili dal cliente . Se Google ha considerato il comportamento di Config Connector una questione di configurazione del cliente piuttosto che una vulnerabilità del prodotto, potrebbe tecnicamente negare la ricompensa ai sensi di questo linguaggio — anche se il comportamento bypassa i controlli IAM previsti.

Un'altra possibilità: le regole del Cloud VRP specificano che il programma copre “difetti di autenticazione o autorizzazione” negli elementi in ambito, che dovrebbero coprire la scoperta di O'Leary . Ma Google ha già sostenuto in altri contesti che certe escalation di privilegi non sono bug se richiedono autorizzazioni specifiche per essere attivate — una posizione che ha attirato critiche dai ricercatori . Nel caso di O'Leary, l'autorizzazione iniziale richiesta (accesso a livello di namespace alle risorse di Config Connector) è minima e comunemente concessa agli sviluppatori, rendendo l'escalation sia reale che pericolosa .

Un terzo fattore riguarda la revisione del Vulnerability Reward Program 2026 per Chrome e Android. Tra la fine di aprile e l'inizio di maggio 2026, Google ha annunciato di tagliare i pagamenti per Chrome e di ristrutturare le ricompense, citando un'impennata di segnalazioni di bassa qualità generate dall'IA . L'azienda ha dichiarato di “ridurre alcuni importi delle ricompense e i bonus su Android e Chrome” per concentrarsi su “qualità e impatto nel mondo reale rispetto al mero volume” . Sebbene il caso di O'Leary rientri nel Cloud VRP separato, non nei programmi Chrome o Android, la posizione pubblica dell'azienda di inasprire i pagamenti potrebbe aver influenzato la decisione — in particolare se Google ha visto il problema di Config Connector come una scelta progettuale piuttosto che un bug .

Crescente reazione dei ricercatori

L'incidente ha suscitato critiche dalla comunità della ricerca sulla sicurezza, con alcuni che sostengono che Google stia usando la narrazione delle segnalazioni IA come copertura per negare vulnerabilità legittime scoperte manualmente . Il commento di PC Perspective ha definito la decisione “diventare tirchi con i bug bounty” e ha notato la discrepanza tra l'elogio iniziale di Google e il suo rifiuto finale . Cyber News Live ha evidenziato che la falla potrebbe consentire un'acquisizione in cinque secondi senza lasciare traccia .

Il caso arriva anche in un momento in cui Google sta contemporaneamente aumentando le ricompense massime per alcune categorie di bug Android — fino a 1,5 milioni di dollari per exploit zero-click persistenti su Titan M . Questo approccio a due livelli — premiare generosamente gli exploit hardware profondi mentre si nega persino il riconoscimento per gravi bypass IAM cloud — ha alimentato le percezioni che i programmi di bug bounty di Google stiano allocando strategicamente i budget piuttosto che valutare onestamente il rischio .

Cosa significa per le organizzazioni che usano Config Connector

Le organizzazioni che eseguono Config Connector in cluster GKE multi-tenant o condivisi dovrebbero trattare questo come un rischio urgente e non corretto. Senza una patch ufficiale di Google, le seguenti mitigazioni possono ridurre l'esposizione:

• Limitare la creazione di risorse iam* a livello di namespace utilizzando le policy RBAC di Kubernetes. Non concedere autorizzazioni create, update o Delete sulle risorse personalizzate IAMPolicy, IAMPolicyMember o IAMPartialPolicy a namespace non fidati.
• Utilizzare Config Connector in modalità namespace con account di servizio distinti e con privilegi ridotti per namespace. La documentazione di Google supporta questa configurazione, che limita il raggio d'esplosione .
• Monitorare le modifiche IAM GCP provenienti da Config Connector. Abilitare i log di audit e impostare avvisi per qualsiasi chiamata setIamPolicy proveniente dal cluster GKE.
• Considerare la disattivazione di Config Connector in ambienti in cui è richiesto l'isolamento multi-tenant, fino a quando Google non risolverà la vulnerabilità.

La documentazione ufficiale di Google sulla protezione dell'accesso alle risorse con IAM descrive le configurazioni raccomandate ma non affronta il vettore di bypass tra namespace al centro del rapporto di O'Leary . Le organizzazioni dovrebbero presumere che le loro distribuzioni di Config Connector possano essere vulnerabili.

Punti chiave

• Una falla di escalation dei privilegi in Google Config Connector (CVSS 10.0) consente a qualsiasi utente di un namespace Kubernetes di ottenere la piena proprietà del progetto GCP.
• Il team di bug bounty di Google ha inizialmente accettato il rapporto come alta priorità, poi ha fatto marcia indietro, dichiarandolo 'funzionamento previsto' e negando una ricompensa.
• Quasi tre mesi dopo il rapporto iniziale, la vulnerabilità rimane non corretta senza una tempistica di fix da parte di Google.
• L'incidente si verifica nel contesto dei più ampi cambiamenti del programma 2026 di Google che tagliano i pagamenti per Chrome mentre aumentano le ricompense per Android, complicando il rapporto dell'azienda con i ricercatori di sicurezza.