9.308 chiavi AWS esposte online funzionavano ancora

La ricerca pubblicata da Truffle Security nell’agosto 2026 descrive un problema di sicurezza cloud tanto esteso quanto persistente. Tra agosto 2022 e agosto 2026, i ricercatori hanno individuato 431.875 segreti AWS in repository pubblici, cronologie Git, dataset, immagini Docker, registri di container e log dei sistemi di integrazione continua. Dopo deduplicazione e verifica, il campione comprendeva 64.024 chiavi AWS uniche. 145

Il dato più preoccupante non è soltanto il numero di credenziali finite online, ma quante risultavano ancora utilizzabili: il 10 agosto 2026, 9.308 delle 10.616 coppie complete testate — circa l’88% — hanno effettuato correttamente l’autenticazione. 145

Chiavi con privilegi elevati

Nel set verificato figuravano 10.625 credenziali root, 48.744 chiavi di utenti IAM — il sistema AWS per la gestione di identità e autorizzazioni — e 4.655 chiavi non classificabili. Le credenziali root rappresentavano il 16,6% delle chiavi uniche. 1

Truffle Security ha identificato 817 chiavi attive collegate ad aziende. Tra queste c’erano:

• 526 chiavi root, il livello di accesso più elevato di un account AWS;
• 242 chiavi di utenti IAM con la policy AdministratorAccess, che può consentire il controllo completo dell’account;
• 768 credenziali complessive potenzialmente in grado di garantire il pieno controllo di un account AWS aziendale;
• 130 chiavi root attive associate ad account di gestione di AWS Organizations, la funzione che coordina più account AWS: una compromissione potrebbe quindi avere conseguenze anche sugli account membri. 13

In un gruppo più ristretto di utenti IAM per i quali era possibile elencare le policy, 976 su 1.157 — l’84% — disponevano di AdministratorAccess. Altri 144 avevano IAMFullAccess. Truffle Security precisa che si tratta di un’indicazione orientativa: gli utenti che permettevano l’enumerazione delle policy potrebbero non rappresentare l’intero insieme degli utenti IAM esposti. 1

Quanti account AWS sono stati coinvolti?

I materiali forniti riportano due totali diversi, probabilmente riferiti a perimetri di analisi differenti. Un riepilogo associa le 64.024 chiavi a 9.945 account AWS distinti, mentre il riepilogo del report originale parla di 50.654 account distinti. Le fonti disponibili non spiegano la differenza; per questo i due numeri non devono essere considerati intercambiabili. 1

Il rischio a livello aziendale è comunque chiaro: centinaia di credenziali attive erano legate a imprese e 768 potevano offrire il controllo completo di un account corporate. 13

Hugging Face è stata la principale fonte singola

Hugging Face, piattaforma dove vengono condivisi modelli, dataset e applicazioni di intelligenza artificiale, ha rappresentato la maggiore fonte individuale: 8.482 chiavi AWS uniche e attive distribuite in 3.394 dataset pubblici. Il 17,9% di queste chiavi era di tipo root, la quota più alta tra le fonti monitorate. 125

Il problema è amplificato dal modo in cui i contenuti pubblici vengono riutilizzati. Una copia del codice che contiene un segreto può finire in un dataset di addestramento e poi essere replicata in altri dataset. Eliminare la credenziale dal repository originale, quindi, non garantisce che tutte le copie siano scomparse. 1

Il dato sulle chiavi AWS rientra in una scansione più ampia di Hugging Face. Truffle Security afferma di aver analizzato 7,6 petabyte e 187 milioni di file, individuando 221.303 credenziali uniche ancora attive in 6.003 dataset. Questi numeri riguardano ogni tipo di credenziale, non soltanto le chiavi AWS. 6

Chiavi vecchie, spesso mai sostituite

Tra le 2.903 chiavi attive per cui era leggibile la data di creazione, l’età mediana era di 1.831 giorni, cioè circa cinque anni. La metà aveva più di cinque anni; la più vecchia ne aveva 17,4. Soltanto 25 chiavi, lo 0,9%, erano state create nei 30 giorni precedenti. 1

Solo 398 delle 2.903 chiavi — il 13,7% — avevano una chiave sostitutiva più recente. Il dato suggerisce che la maggior parte non fosse stata ruotata, rimpiazzata o eliminata dopo l’esposizione. 1

La conseguenza pratica è netta: un segreto comparso in materiale pubblico dovrebbe essere considerato compromesso in modo permanente, anche se il file originale o la voce nel repository sono stati modificati. Cronologie Git, immagini dei container, artefatti dei pacchetti e dataset pubblici possono conservare le versioni precedenti. 1

Pochi alert di spesa e rischio di cryptomining

Anche i controlli sui costi erano poco diffusi. Dei 2.754 account per cui era possibile leggere le impostazioni, soltanto 262 — il 9,5% — avevano configurato almeno un avviso di budget. La soglia mediana era di 8 dollari. 12

Il restante 90,5% non presentava un allarme di spesa rilevabile. Un attaccante con credenziali valide potrebbe sfruttare la capacità di calcolo cloud per il cryptomining o per altri carichi di lavoro, generando costi anomali prima che l’organizzazione se ne accorga. 12

Gli account con dati di spesa leggibili hanno totalizzato 420.631 dollari nel luglio 2026. Cinquanta hanno speso più di 1.000 dollari e nove più di 10.000 nello stesso mese. Queste cifre descrivono la spesa osservata, ma non dimostrano che sia stata causata dall’abuso delle credenziali. 1

La quarantena AWS non equivale sempre alla disattivazione

Truffle Security ha riferito di aver osservato AWS applicare la policy AWSCompromisedKeyQuarantine alle chiavi IAM esposte. Questa policy limita le operazioni che la chiave può eseguire, ma non implica necessariamente che l’autenticazione venga bloccata subito. 1

Tra le chiavi IAM attive esaminate, 929 su 7.590 — il 12% — presentavano questa policy. Altre 112 utilizzavano una versione precedente, che AWS ha smesso di applicare nel 2023. Secondo i risultati, alcune chiavi sono rimaste utilizzabili nonostante notifiche di esposizione risalenti nel tempo. 1

Una policy di quarantena va quindi considerata un segnale di compromissione, non la prova che il segreto sia stato ritirato in sicurezza. L’organizzazione dovrebbe identificare il proprietario e i permessi della chiave, quindi revocarla o sostituirla. 1

Come sono state verificate le credenziali

Truffle Security ha dichiarato di aver riverificato soltanto le coppie di credenziali complete. Per analizzare account e privilegi ha utilizzato chiamate IAM in sola lettura, una chiave alla volta; non ha pubblicato il materiale delle chiavi e ha notificato ogni proprietario che è riuscita a identificare. 15

Questo aspetto è importante per interpretare il dato dell’88%: la percentuale riguarda il sottoinsieme di coppie complete sottoposte a un nuovo test, non tutti i ritrovamenti pubblici né ogni segreto parziale individuato durante la scansione. 14

Cosa dovrebbero fare le organizzazioni

I risultati sostengono una checklist di risposta immediata:

1. Eliminare le chiavi di accesso root. Secondo Truffle Security, non hanno un uso operativo legittimo. 1
2. Inventariare tutte le chiavi IAM, incluse quelle presenti nei repository, nella cronologia Git, nei log CI, nelle immagini, nei registri e nei dataset pubblicati. 1
3. Revocare o ruotare subito le credenziali esposte. Cancellare la copia visibile non basta se il segreto è ancora presente in cronologie o artefatti derivati. 1
4. Impostare un’età massima per le chiavi e applicare la rotazione. Le credenziali vecchie e inutilizzate dovrebbero essere rimosse, non lasciate attive indefinitamente. 1
5. Configurare gli avvisi di budget. Anche una soglia contenuta, come 10 dollari, può segnalare tempestivamente una spesa non autorizzata. 1
6. Monitorare AWSCompromisedKeyQuarantine e trattarla come un’indicazione che la credenziale potrebbe essere stata esposta. 1
7. Adottare la scansione continua dei segreti nel codice, nella cronologia, nei sistemi di build, negli artefatti dei container, nei registri e nei dataset pubblici. 1

Il messaggio centrale della ricerca è che l’esposizione pubblica non è una fuga di dati “una tantum”. Senza revoca, rotazione e monitoraggio, una chiave AWS può restare per anni una porta ancora funzionante verso l’infrastruttura cloud.