ConfigConfusion: un file YAML per diventare Organization Owner…

ConfigConfusion sfrutta Google Kubernetes Config Connector per escalationare da utente namespace a Organization Owner senza credenziali GCP. Google ha classificato

Il 23 settembre 2026 il ricercatore Justin O'Leary ha reso pubblica ConfigConfusion, una vulnerabilità architetturale in Google Kubernetes Config Connector (KCC) che permette a un utente con accesso a un namespace Kubernetes di escalationare a Organization Owner di una GCP organization. Tre righe di YAML e circa cinque secondi bastano per l'exploit. Google aveva accettato il report come P1/S1 il 27 marzo 2026, poi lo ha rifiutato come "working as intended" senza rilasciare patch.

Punti chiave

Un utente Kubernetes con permessi di creare IAMPolicyMember nel proprio namespace diventa Organization Owner di GCP senza possedere credenziali cloud
Google ha accettato il report come P1/S1 il 27 marzo 2026; 11 giorni dopo, un Security Bot ha invertito la decisione con la motivazione "working as intended"
La stessa azienda ha patchato pattern confused deputy identici in Cloud Run (ImageRunner, gennaio 2025) e Cloud Composer (ConfusedComposer, aprile 2025)
AWS ACK e Azure Service Operator adottano architetture che limitano il blast radius separando controller o usando identità per-namespace

Come funziona il confused deputy tra Kubernetes e GCP

Il meccanismo sfrutta una disgiunzione strutturale tra due sistemi di autorizzazione. Kubernetes RBAC controlla chi può creare una risorsa IAMPolicyMember nel cluster. GCP IAM controlla chi può modificare le policy dell'organization. Nessuno dei due verifica che l'utente che sottomette la risorsa Kubernetes sia autorizzato a ottenere il privilegio GCP richiesto.

Config Connector opera come intermediario con un service account dedicato, tipicamente dotato di privilegi a livello organization per poter gestire risorse cross-project. Quando un utente Kubernetes crea un IAMPolicyMember che referenzia un'organization esterna, KCC esegue l'operazione GCP usando la propria identità, non quella dell'utente originale. L'utente Kubernetes non ha mai bisogno di credenziali GCP né di accesso al service account.

O'Leary ha classificato il difetto come CWE-441 (confused deputy). La vulnerabilità non risiede in un bug di implementazione, ma in un'assenza di controllo di autorizzazione end-to-end tra i due domini di trust. Come ha dichiarato il ricercatore a The Register: "The vulnerability is the missing authorization check. Config Connector executes privileged operations on behalf of users without verifying those users are authorized."

Da "Nice catch!" a "not a vulnerability": la timeline della disclosure

La disclosure di O'Leary documenta una sequenza di inversioni nel trattamento del caso. Il 27 marzo 2026 un engineer di Google ha risposto al report: "Nice catch! I've filed a bug with the responsible product team based on your report. We'll work with the product team to ensure this issue is addressed." Il caso è stato classificato P1/S1, la priorità massima, e avviato il processo di pagamento del bounty.

11 giorni dopo, il 7 aprile 2026, un Google Security Bot ha automaticamente invertito la decisione: "Working as intended. The Config Connector Service Account requires the organization admin role for the reported scenario to be exploitable which is not recommended and breaks best practice." Questa motivazione contrasta con la documentazione ufficiale di Google, che presenta la configurazione org-level per KCC come feature supportata — non come pratica sconsigliata.

Il 1 maggio 2026 la Google CNA ha rifiutato l'assegnazione CVE con la motivazione: "We do not believe it is a vulnerability." Nonostante ciò, al 18 giugno 2026 il caso manteneva ancora lo status P1/S1 "In Progress (Accepted)" nel sistema di tracciamento interno. Circa 3 mesi dopo, al 23 settembre 2026, la vulnerabilità non risulta ancora patchata secondo la copertura mediatica.

"Three lines, five seconds, full admin control."
— Justin O'Leary, descrizione dell'exploit

ImageRunner e ConfusedComposer: stesso pattern, trattamento diverso

La documentazione di O'Leary evidenzia che Google ha patchato pattern confused deputy simili in altri servizi. ImageRunner, scoperto da Tenable nel gennaio 2025, sfruttava un confused deputy in Cloud Run per ottenere accesso non autorizzato a container registry. ConfusedComposer, sempre da Tenable nell'aprile 2025, usava un'analoga disgiunzione in Cloud Composer. Entrambi sono stati patchati da Google.

I tre casi condividono lo stesso meccanismo CWE-441. Secondo l'analisi di DeafNews, la differenza di trattamento solleva questioni sulla governance dei bug bounty che il brief non consente di risolvere con certezza: la motivazione precisa del mantenimento dello status P1/S1 nonostante il rifioto è indicata come UNKNOWN nelle fonti disponibili.

O'Leary ha sintetizzato la dinamica in un'intervista a The Register: "This is a pattern. This is just how these trillion-dollar companies deal with people like me." The Register ha confermato il riferimento a pattern citando Liv Matan di Tenable.

Perché l'audit trail mancante rende il rilevamento difficile

Una conseguenza operativa concreta riguarda la tracciabilità. Le operazioni GCP eseguite da Config Connector vengono attribuite al service account KCC, non all'utente Kubernetes che ha sottomesso la risorsa. Nell'event log GCP compare l'identità del controller, non quella del soggetto che ha originato la richiesta.

Questa disgiunzione rende impraticabile il rilevamento basato su correlazione diretta tra eventi Kubernetes e operazioni GCP. Un analista SOC che osservi la creazione di un IAMPolicyMember organization-level vedrebbe un'operazione legittima eseguita da un service account autorizzato, senza indicatore che la richiesta originasse da un utente namespace.

Il brief non specifica mitigazioni operative per questo scenario. AWS ACK e Azure Service Operator v2 adottano architetture alternative: separazione dei controller o uso di identità per-namespace, che limitano il blast radius di operazioni simili. Queste sono configurazioni documentate dei servizi concorrenti, non raccomandazioni applicabili a KCC.

Cosa fare adesso

Le informazioni si basano sulle fonti disponibili, con limiti derivanti dalla mancanza di advisory strutturato da parte di Google. I fatti verificati nel dossier indicano quanto segue:

Verificare se KCC è configurato con scope organization-level nel proprio ambiente; la feature è documentata ufficialmente da Google e implementata dalla release 1.27.0
Riconoscere che le operazioni GCP eseguite da KCC non riportano l'identità dell'utente Kubernetes originale nei log
Valutare che Google ha classificato il caso "working as intended" e rifiutato l'assegnazione CVE; al 23 settembre 2026 non risulta patch rilasciata
Considerare che Google ha trattato pattern tecnicamente analoghi in Cloud Run e Cloud Composer come vulnerabilità da correggere

Secondo l'analisi di DeafNews, la discrepanza tra accettazione iniziale (P1/S1 con "Nice catch!") e rifioto successivo ("working as intended" con qualificatore "not recommended and breaks best practice") documenta un contrasto interno nelle valutazioni di Google, non risolvibile con le fonti attuali.

Chiusura editoriale

ConfigConfusion esemplifica una categoria di rischi architetturali che attraversano i confini tra piattaforme: il confused deputy non è un bug di codice isolato, ma una disgiunzione di trust tra sistemi che operano in cascata. Il caso è particolare per il contrasto documentato tra la pratica ufficiale di Google (supporto org-level in KCC) e la classificazione del Security Bot (pratica "not recommended"), nonché per il mantenimento dello status P1/S1 nonostante il rifioto formale.

La mancanza di advisory strutturato da parte di Google limita la capacità di valutare l'impatto reale sui tenant GCP. Le fonti disponibili — il blog di O'Leary, il reporting di BleepingComputer e The Register, e la documentazione GitHub di KCC — forniscono una base fattuale solida ma non consentono verifica indipendente delle comunicazioni interne Google.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter