Il 15 aprile 2026 Google ha rilasciato la versione 1.148.0 del SDK google-cloud-aiplatform, correggendo una vulnerabilità scoperta dal team Unit 42 di Palo Alto Networks che permetteva a un attaccante di ottenere esecuzione di codice remota nell'infrastruttura di serving Vertex AI di una vittima senza possedere alcun accesso al suo progetto cloud. La chiave di volta è un pattern di naming deterministico per i bucket di staging temporanei, combinato con l'assenza di un controllo di proprietà nel client SDK. L'attacco funziona interamente cross-tenant: l'aggressore opera dal proprio progetto Google Cloud, con qualsiasi account di fatturazione.
- Il codice vulnerabile in
gcs_utils.pygenera il nome bucket di staging concatenando project ID, stringa fissa "vertex-staging" e location, rendendo il nome predicibile e squat-tabile - Il controllo
staging_bucket.exists()verifica solo l'esistenza del bucket, non la proprietà del progetto chiamante: se un bucket con quel nome esiste in un altro progetto, il SDK vi carica silenziosamente i dati - L'attaccante dispone di circa 2,5 secondi per sostituire il modello legittimo con un payload pickle malevolo prima che questo venga caricato nel container di serving
- L'esecuzione avviene nel contesto del Per-Product, Per-Project Service Account (P4SA) di Vertex AI, con potenziale movimento laterale nell'ambiente cloud della vittima
Il meccanismo: quando il nome del bucket diventa un vettore d'attacco
La vulnerabilità risiede nella funzione stage_local_data_in_gcs() del modulo gcs_utils.py, alla riga 6: staging_bucket_name=project+"-vertex-staging-"+location. Questa riga, presente nelle versioni 1.139.0 e 1.140.0 del SDK, implementa una convenzione di naming rigida e deterministicica per i bucket di staging temporanei usati durante il caricamento dei modelli ML.
Il problema emerge dall'interazione tra questa convenzione e le proprietà di Google Cloud Storage. I nomi bucket devono essere globalmente unici in tutta l'infrastruttura GCS. Un attaccante che conosca il project ID della vittima — informazione spesso pubblicamente reperibile in repository, documentazione tecnica o URL di servizi — può calcolare il nome del bucket di staging per una specifica regione. Se la vittima non ha mai utilizzato Vertex AI in quella regione, il bucket non esiste. L'attaccante lo crea nel proprio progetto. Quando la vittima successivamente invoca l'upload del modello, il controllo if not staging_bucket.exists() restituisce True: il bucket esiste, ma nel progetto dell'attaccante, non in quello della vittima.
Il codice prosegue con l'upload senza ulteriori verifiche di proprietà. Secondo Unit 42: "If the bucket exists, even in a completely different project, the SDK proceeds to upload model artifacts to it without any further verification."
"By exploiting this flaw in vulnerable versions of the SDK, an attacker can achieve remote code execution (RCE) within a target's Vertex AI serving infrastructure, with zero initial access to the victim's project." — Unit 42, Palo Alto Networks
La race condition da 2,5 secondi: finestra per il poisoning del modello
Una volta che il modello legittimo è stato caricato nel bucket squattato, l'attaccante deve agire rapidamente. I ricercatori di Unit 42 hanno misurato sperimentalmente una finestra temporale di circa 2,5 secondi per sostituire il file del modello con un payload malevolo prima che il servizio Vertex AI lo prelevi e lo carichi nel container di serving. Come riportano i ricercatori: "Our tests show that this window is approximately 2.5 seconds, requiring near-real-time attacker operation."
Il payload sfrutta la deserializzazione pickle — o equivalentemente joblib — al momento del caricamento del modello. Python's pickle esegue il metodo __reduce__ degli oggetti deserializzati, permettendo l'esecuzione di codice arbitrario. Il modello malevolo, apparentemente un file di modello ML standard, contiene una classe pickle con __reduce__ modificato per eseguire comandi nel contesto del container di serving.
L'esecuzione avviene con le credenziali del Per-Product, Per-Project Service Account (P4SA) di Vertex AI, un account di servizio gestito da Google con privilegi significativi all'interno del progetto vittima. Questo apre possibilità di movimento laterale nell'ambiente cloud, sebbene il brief non specifichi tecniche o ambiti precisi di questa fase successiva.
Perché è importante
Il dossier non conferma che la vulnerabilità sia stata sfruttata in-the-wild prima del rilascio del fix. Non è noto se Google abbia notificato attivamente gli utenti dei progetti potenzialmente esposti, né è documentato se la correzione in versione 1.148.0 si limiti al controllo di ownership o includa mitigazioni aggiuntive come la randomizzazione del nome bucket.
Il brief non specifica se il project ID sia l'unico requisito informativo per l'attacco o se parametri aggiuntivi — come la regione esatta di deployment — siano necessari per calcolare il nome del bucket target. Non è inoltre verificabile indipendentemente la data esatta della disclosure iniziale a Google e la durata dell'intervallo tra segnalazione e rilascio del patch.
Ciò che rende questa vulnerabilità significativa nel panorama della sicurezza cloud è la natura invisibile dell'infrastruttura di staging implicita. Gli sviluppatori che utilizzano Vertex AI attraverso il client SDK non necessariamente sono consapevoli dell'esistenza di bucket temporanei generati automaticamente, né del fatto che i nomi di questi bucket siano derivabili da informazioni pubbliche. La fiducia implicita nel client SDK come custode dell'isolamento multi-tenant si rivela qui un punto di fragilità sistemica.
L'evoluzione del cloud squatting: da domini dimenticati a bucket predetti
Il cloud squatting — la pratica di occupare risorse cloud con nomi prevedibili prima che il legittimo proprietario ne abbia bisogno — si è finora manifestato principalmente come acquisizione di nomi di dominio scaduti o di bucket S3 abbandonati. Questa vulnerabilità ne rappresenta una mutazione qualitativa: non si tratta più di risorse dimenticate dall'utente, ma di risorse che il servizio managed genererà automaticamente in futuro, con nomi perfettamente calcolabili in anticipo.
L'angolo di Unit 42 mette in luce una tensione architetturale nei servizi AI managed: la convenienza dell'abstrazione SDK richiede che il client gestisca dettagli infrastrutturali al posto dell'utente, ma questa opacità elimina anche la visibilità necessaria per valutare i confini di sicurezza. Il project ID, elemento normalmente considerato pubblico e non sensibile, diventa in questo scenario un identificatore critico per il targeting.
Secondo i ricercatori: "The root enabler of this attack is a predictable default bucket name, combined with a missing ownership check in the SDK's staging logic." La combinazione di naming deterministico e trust implicito nel client crea un confine cross-tenant violabile senza alcuna compromissione preliminare dell'account vittima.
Cosa fare adesso
Le azioni documentate nel dossier sono limitate alle seguenti:
- Verificare la versione installata del SDK
google-cloud-aiplatform: le versioni 1.139.0 e 1.140.0 sono vulnerabili - Aggiornare alla versione 1.148.0 o successiva, rilasciata il 15 aprile 2026 con il fix
- Rilevare se il project ID dell'organizzazione sia esposto pubblicamente in repository, documentazione o URL accessibili
- Verificare se siano stati creati bucket con pattern
{project-id}-vertex-staging-{location}in progetti non appartenenti all'organizzazione
Il brief non documenta misure correttive specifiche aggiuntive né procedure di verifica per deployment già effettuati con versioni vulnerabili del SDK.
Domande e risposte
L'attacco funziona con qualsiasi versione del SDK Vertex AI?
No. Solo le versioni 1.139.0 e 1.140.0 sono state confermate come vulnerabili da Unit 42. La versione 1.148.0, rilasciata il 15 aprile 2026, contiene il fix.
L'attaccante deve avere accesso alla console o alle credenziali della vittima?
No. L'attacco è completamente cross-tenant. L'attaccante opera dal proprio progetto Google Cloud con qualsiasi account di fatturazione. Il solo requisito documentato è la conoscenza del project ID della vittima.
La finestra di 2,5 secondi rende l'attacco impraticabile?
I ricercatori la definiscono "near-real-time", indicando che richiede operazione dell'attaccante in prossimità immediata dell'upload della vittima. Non è documentato se tecniche di automazione possano renderla sistematicamente sfruttabile.
Fonti
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.