Amazon Bedrock AgentCore: falle che espongono credenziali AWS

Tra fine settembre e inizio ottobre 2026 tre ricerche hanno mostrato come gli agenti costruiti su Amazon Bedrock AgentCore, il servizio di AWS per eseguire agenti di intelligenza artificiale, potessero consegnare a un attaccante le credenziali AWS del proprio ruolo di esecuzione. Il filo comune non è una singola falla, ma la combinazione di tre elementi: un agente che può eseguire comandi o generare traffico, credenziali raggiungibili dall’ambiente in cui gira e permessi più ampi del necessario.

Cosa è successo

• Due CVE nell’SDK Python (BeyondTrust). Secondo Infosecurity Magazine, che riprende la ricerca pubblicata da BeyondTrust il 28 settembre, l’helper del Code Interpreter che installa pacchetti Python trasformava un nome di pacchetto costruito ad arte in un comando di shell eseguito nella sandbox. Da lì i ricercatori hanno letto le credenziali temporanee del ruolo di esecuzione.
• «AgentCorruption» (Zenity Labs). Secondo CSO Online, che ha ricevuto il rapporto in anticipo, i ricercatori hanno semplicemente chiesto a un agente le sue credenziali e le hanno ottenute. Dark Reading descrive la falla, ora corretta, come un modo per mettere a rischio l’intero ambiente AWS di un’organizzazione partendo da un solo chatbot.
• AgentCore Harness (Unit 42 di Palo Alto Networks). Il 18 settembre Unit 42 ha riferito che, nella configurazione predefinita, lo strumento shell integrato, attivo di default e in esecuzione come root, raggiunge la memoria in cui le credenziali gestite da AgentCore Identity sono risolte in chiaro: con una prompt injection un attaccante può farle esfiltrare all’agente.

Dettagli tecnici

CVE-2026-12530 colpisce l’SDK Python di AgentCore dalla versione 1.1.3 alla 1.6.0: un elenco incompleto di caratteri vietati permetteva di aggirare il controllo sul nome del pacchetto. AWS l’ha corretta nella 1.6.1 con una regola di validazione più rigida, ma BeyondTrust ha aggirato anche questa: CVE-2026-16796, che AWS indica per tutte le versioni precedenti alla 1.18.1, usava la sintassi degli extras di pip per far passare comandi di shell. La correzione è nella 1.18.1. AWS ha assegnato a entrambe 7.3 in CVSS 3.1 e 8.4 in CVSS 4.0.

Secondo BeyondTrust l’isolamento Firecracker delle sessioni ha tenuto: il punto debole era l’helper dell’SDK. Servivano tre condizioni: un input influenzabile dall’attaccante che arriva a install_packages(), una versione vulnerabile dell’SDK e un Code Interpreter personalizzato con un ruolo di esecuzione associato. L’input può venire da nomi di pacchetti forniti dagli utenti, da contenuti non fidati elaborati dall’agente o da file di dipendenze di un repository non fidato. Nei log di AWS, avverte BeyondTrust, l’attività dell’attaccante può sembrare normale attività applicativa.

Nella catena descritta da Zenity, l’agente raggiungeva il servizio dei metadati dell’istanza (IMDS) e restituiva un set completo di credenziali STS temporanee (access key ID, secret access key e session token), funzionanti anche da una macchina esterna ad AgentCore. Togliere all’agente lo strumento HTTP non bastava: il difetto di isolamento era della piattaforma, e il risultato si ripeteva con altri strumenti, compreso lo strumento shell integrato di Strands. Con i permessi di lettura su ECR i ricercatori hanno scaricato l’immagine dell’agente, con codice e dipendenze; poiché AgentCore chiama ogni repository bedrock-agentcore-<nome_agente>, in pochi secondi hanno recuperato il codice di tutti gli agenti della regione. Il ruolo predefinito aveva permessi di lettura, scrittura e cancellazione su vari servizi AgentCore e AWS della regione: invocare altri agenti, leggere le conversazioni, avvelenare la memoria per restare persistenti, raccogliere credenziali e chiavi API, eseguire azioni distruttive.

Già ad aprile Unit 42 aveva segnalato che AgentCore Runtime usava un servizio di metadati della microVM (MMDS) senza obbligo di token di sessione: prima delle correzioni di AWS, una SSRF poteva bastare per estrarre credenziali.

Mappatura MITRE ATT&CK indicativa, ricavata dai fatti riportati: T1059 (Command and Scripting Interpreter), T1552.005 (Unsecured Credentials: Cloud Instance Metadata API), T1078.004 (Valid Accounts: Cloud Accounts).

Stato delle correzioni e posizioni divergenti

• Per le due CVE dell’SDK la correzione è la versione 1.18.1 o successive.
• Zenity ha segnalato i problemi ad AWS il 25 dicembre 2025. Il 14 febbraio 2026 AWS ha portato AgentCore al solo IMDSv2, chiudendo il vettore iniziale, ma il 22 giugno i permessi del ruolo predefinito erano invariati. Secondo Zenity sono stati corretti tra il 22 giugno e il 29 settembre; l’8 ottobre il percorso d’attacco non era più sfruttabile.
• La segnalazione di Unit 42 su AgentCore Harness è stata chiusa da AWS come «informativa», nell’ambito del modello di responsabilità condivisa.
• AWS sostiene che la ricerca di Zenity presenti come vulnerabilità un comportamento atteso e documentato, e raccomanda di concedere ai ruoli di esecuzione solo i permessi necessari agli agenti.

Impatto per le aziende europee e italiane

Chi usa AgentCore per agenti rivolti a clienti o dipendenti è esposto in proporzione ai permessi del ruolo di esecuzione: le credenziali sottratte non restano nella sandbox. Se conversazioni o chiavi coinvolte riguardano dati personali, va valutata una violazione ai sensi del GDPR. Per i soggetti NIS2 gli agenti IA in cloud rientrano nelle misure dell’articolo 21: controllo degli accessi, sicurezza della catena di approvvigionamento, gestione delle vulnerabilità. Le fonti concordano su un punto: l’isolamento spetta alla piattaforma, ma i permessi sono responsabilità del cliente.

Cosa fare subito

1. Aggiorna l’SDK Python di AgentCore alla 1.18.1 o successiva in progetti, pipeline e immagini.
2. Non passare a install_packages() nomi di pacchetti non fidati o generati dal modello, come raccomanda AWS.
3. Sostituisci il ruolo di esecuzione predefinito con un ruolo per agente con i soli permessi necessari; nessun ruolo dove il codice non deve usare servizi AWS.
4. Rivedi gli strumenti integrati: disattiva lo strumento shell di AgentCore Harness e gli strumenti HTTP dove non servono, e tratta quelli che restano come ad alto rischio.
5. Limita il traffico in uscita degli agenti e non inserire segreti nelle immagini.
6. Sorveglia l’attività: monitora il Code Interpreter, definisci un riferimento di identità e strumenti per ogni agente così che le anomalie risaltino, e cerca nei log di AWS l’uso delle credenziali dei ruoli degli agenti fuori dal loro ambiente abituale.

Ultimo aggiornamento: 8 ottobre 2026