Google ADK per Python ha una vulnerabilità critica con punteggio CVSS 10.0: se usi adk web, controlla subito la versione installata e aggiorna a google-adk 2.7.0 o successiva. La falla è identificata come CVE-2026-79696 e può consentire esecuzione di codice da remoto senza autenticazione in precise condizioni di esposizione.
Non significa che ogni progetto costruito con Agent Development Kit sia automaticamente compromesso. Il rischio riguarda Google ADK per Python dalla 2.0.0 alla 2.6.0, il componente adk web, ambienti in cui è presente pytest e un servizio raggiungibile dalla rete. La patch è già disponibile, quindi la priorità pratica è ridurre l’esposizione e aggiornare.
| Controllo | Situazione |
|---|---|
| CVE | CVE-2026-79696 |
| Gravità | CVSS 10.0 Critical |
| Versioni coinvolte | google-adk 2.0.0 fino alla 2.6.0 |
| Versione corretta | 2.7.0 o successiva |
| Componente | adk web |
| Autenticazione richiesta | No, nello scenario vulnerabile |
| Condizione rilevante | pytest presente e servizio raggiungibile |
Cos’è CVE-2026-79696 e perché Google ADK è vulnerabile
La scheda CVE descrive una vulnerabilità di code injection nel servizio web di Google Cloud Agent Development Kit per Python. Il problema nasce da un controllo incompleto delle funzioni che possono essere richiamate durante la riproduzione di una sessione di test.
Un attaccante remoto, senza credenziali, può inviare dati appositamente costruiti a un’istanza vulnerabile e arrivare a eseguire codice con i privilegi del processo ADK. Il record ufficiale della vulnerabilità è stato assegnato da Google Cloud e rimanda direttamente alla release 2.7.0 di Google ADK su GitHub, che contiene la correzione.
Quali installazioni di Google ADK sono realmente a rischio
Il dettaglio importante è che non basta avere la libreria installata. La descrizione pubblicata per CVE-2026-79696 delimita uno scenario preciso: versioni di Google ADK per Python precedenti alla 2.7.0, utilizzo di adk web, presenza di pytest nell’ambiente e possibilità per un attaccante di raggiungere il servizio.
Questo può riguardare un ambiente Python OSS, una distribuzione su Cloud Run o un workload su GKE. Un’istanza di sviluppo confinata al computer locale ha un’esposizione molto diversa da un servizio pubblicato su Internet, ma la differenza di esposizione non sostituisce l’aggiornamento.
Se usi ADK solo in locale devi aggiornare?
Sì. Un servizio non raggiungibile dall’esterno riduce il rischio immediato, ma restare su una versione vulnerabile non porta alcun vantaggio. Un cambio di configurazione, un port forwarding, un container pubblicato per errore o un ambiente condiviso possono modificare rapidamente il perimetro.
La scelta più semplice è portare la dipendenza alla release corretta e mantenere adk web fuori dalle reti non necessarie.
Come controllare quale versione di google-adk hai installato
Nel virtual environment o nel container che esegue il progetto puoi controllare la versione del pacchetto con:
python -m pip show google-adkSe il risultato mostra una versione dalla 2.0.0 alla 2.6.0, rientri nell’intervallo interessato. Se il progetto utilizza file di lock o immagini container, controlla anche la versione realmente distribuita in produzione: aggiornare soltanto l’ambiente locale non corregge un’immagine già pubblicata.
La vulnerabilità riguarda una dipendenza legittima, non un pacchetto Python fasullo. È un caso diverso dalle campagne che abbiamo analizzato nell’approfondimento sui falsi pacchetti Python distribuiti attraverso Stack Exchange, ma la lezione operativa è simile: sapere esattamente quali dipendenze girano nell’ambiente è parte della sicurezza del software.
Come aggiornare Google ADK alla versione corretta
Per una normale installazione tramite pip puoi aggiornare il pacchetto con:
python -m pip install -U google-adkAl termine, esegui di nuovo pip show e verifica che la versione sia 2.7.0 o successiva. Nei progetti gestiti con requirements, Poetry, uv o altri sistemi di lock devi aggiornare anche il file che blocca le dipendenze, quindi ricostruire e ridistribuire l’ambiente.
- Identifica la versione realmente in esecuzione.
- Aggiorna google-adk almeno alla 2.7.0.
- Aggiorna requirements o lockfile.
- Ricostruisci eventuali immagini container.
- Ridistribuisci Cloud Run, GKE o il servizio interessato.
- Controlla che la nuova istanza esponga solo le porte e gli endpoint necessari.
Se non puoi aggiornare subito, cosa puoi fare
La soluzione indicata nel record CVE resta l’upgrade. Come riduzione temporanea del rischio, Google raccomanda di non esporre adk web a una rete. Se il servizio serve solo durante lo sviluppo, deve restare limitato all’ambiente di sviluppo.
Se pytest non è necessario in produzione, rimuoverlo dall’immagine o dall’ambiente riduce una delle condizioni indicate per lo scenario vulnerabile. Non va però interpretato come una patch equivalente alla 2.7.0.
CVSS 10 significa che Google ADK è già sotto attacco?
No. Un punteggio CVSS 10 descrive la gravità tecnica nelle condizioni previste, non dimostra che esista già una campagna di sfruttamento diffusa. Al momento della pubblicazione del record, CVE-2026-79696 non risulta inserita nel catalogo CISA KEV.
La distinzione è importante: rischio potenziale elevatissimo e sfruttamento osservato sono due dati diversi. In questo caso non serve aspettare una prova di attacchi reali, perché esiste già una release corretta e l’upgrade elimina il motivo principale per restare esposti.
È lo stesso principio che vale per le altre vulnerabilità critiche già corrette: nell’articolo su Chrome 153 e le falle corrette da Google abbiamo distinto la presenza di una patch dalla conferma di sfruttamento. La priorità cambia quando esistono attacchi reali, ma una RCE remota senza autenticazione resta comunque da correggere rapidamente.
Cosa controllare dopo l’aggiornamento
Dopo il deploy della 2.7.0 o di una release successiva, non fermarti al numero di versione mostrato sul computer dello sviluppatore. Controlla il runtime effettivo, verifica che le vecchie immagini non siano ancora attive e assicurati che adk web non sia stato lasciato esposto inutilmente.
- versione di google-adk nel runtime;
- immagini container realmente distribuite;
- regole ingress e firewall;
- presenza di
pytestnegli ambienti di produzione; - log relativi al periodo in cui il servizio vulnerabile era raggiungibile;
- eventuali credenziali accessibili al processo ADK.
Il record ufficiale CVE-2026-79696 indica chiaramente la correzione: google-adk 2.7.0 o successiva e nessuna esposizione di adk web alla rete quando non necessaria. Se il tuo progetto rientra nelle versioni 2.0.0-2.6.0, è il controllo da fare adesso.
