CVE-2026-89049: SSM Agent, IMDS e rischio SSRF

Immagina di aver configurato tutto correttamente: utenti autenticati, sessioni tracciate, permessi assegnati con criterio. Poi scopri che una singola falla di validazione in un componente fidato può aprire una porta verso le credenziali più sensibili della tua infrastruttura. È esattamente questo lo scenario descritto da CVE-2026-89049, una vulnerabilità critica che ha colpito l’AWS Systems Manager Agent (SSM Agent) e ha riacceso i riflettori su un problema strutturale: la fiducia accordata agli “authenticated users” nelle feature di gestione remota non basta, da sola, a garantire la sicurezza. Il vero bersaglio, ancora una volta, è l’Instance Metadata Service (IMDS), un endpoint che continua a rappresentare una superficie d’attacco permanente nel cloud AWS.

Cosa è successo con CVE-2026-89049

La vulnerabilità riguardava tutte le versioni di SSM Agent precedenti alla 3.3.4851.0. Il problema nasceva da una validazione debole degli indirizzi di destinazione remota, basata su un semplice confronto di stringhe (string-matching).

• La denylist che doveva bloccare gli indirizzi link-local (come 169.254.169.254) non riconosceva le rappresentazioni alternative dello stesso indirizzo.
• Formati equivalenti come IPv4-mapped IPv6, notazioni numeriche alternative o encoding differenti riuscivano a bypassare il controllo.
• Il risultato: una sessione SSM con port-forwarding, apparentemente legittima e autorizzata, poteva essere reindirizzata verso l’IMDS dell’istanza.

Questo significa che un utente già autenticato, con permessi minimi su Session Manager, poteva sfruttare una feature legittima per raggiungere un endpoint che avrebbe dovuto restare inaccessibile.

Il meccanismo: quando la denylist non basta

Il cuore del problema è un classico errore di sicurezza informatica: affidarsi a un confronto di stringhe letterali invece che a una canonicalizzazione robusta degli indirizzi. Esistono infatti molteplici modi di rappresentare lo stesso indirizzo IP:

• Formati IPv4-mapped IPv6 (come ::ffff:IPv4)
• Notazioni numeriche, decimali, esadecimali o ottali
• Percent-encoding nei path di richiesta
• Varianti con zeri iniziali o formattazioni non standard

Se il sistema di controllo non normalizza questi formati prima di confrontarli con la denylist, basta una rappresentazione “non riconosciuta” per bypassare il filtro. In questo caso specifico, si è trattato di un vero e proprio SSRF-by-design: una funzione pensata per l’amministrazione remota è stata trasformata in un vettore di attacco verso servizi interni.

L’effetto a cascata: da SSM alle credenziali IAM

Una volta raggiunto l’IMDS, l’attaccante può leggere le credenziali temporanee associate al ruolo IAM dell’istanza. Queste credenziali, se il ruolo ha permessi ampi, permettono di:

• Accedere a bucket S3
• Leggere segreti da Secrets Manager
• Interagire con RDS, DynamoDB o KMS, se autorizzato

L’impatto reale dipende quasi interamente dai permessi assegnati al ruolo dell’istanza. Un ruolo troppo permissivo trasforma una vulnerabilità SSRF in una compromissione completa dell’account.

Il principio del least privilege come mitigazione strutturale

Se c’è una lezione da trarre da CVE-2026-89049, è questa: limitare i permessi dei ruoli EC2 è la difesa più efficace contro il “blast radius” di un incidente del genere. Anche se le credenziali vengono rubate, un ruolo con permessi minimi riduce drasticamente il danno.

Alcune raccomandazioni pratiche:

1. Evitare di assegnare permessi troppo ampi come S3:* o SecretsManager:* ai ruoli delle istanze.
2. Utilizzare policy IAM con risorse specifiche e condizioni contestuali, quando possibile.
3. Separare i ruoli per compiti diversi, evitando di concentrare troppi permessi su un singolo ruolo condiviso.

Shared responsibility: chi fa cosa

Il modello di responsabilità condivisa di AWS resta centrale in questo scenario:

• AWS corregge le vulnerabilità nei componenti gestiti, come SSM Agent, e fornisce strumenti come IMDSv2.
• Il cliente deve configurare correttamente IAM, imporre IMDSv2, aggiornare gli agenti, monitorare i log e ridurre la superficie di attacco.

La patch di AWS non esonera l’organizzazione dal dovere di applicare il principio del least privilege e di monitorare attivamente l’infrastruttura.

Perché l’IMDS resta un bersaglio ricorrente

Non è la prima volta che l’IMDS finisce al centro di un incidente di sicurezza. Il pattern è ormai noto: SSRF → accesso all’IMDS → furto di credenziali → compromissione di risorse AWS. Uno degli esempi più noti resta l’incidente Capital One del 2019, che ha coinvolto milioni di record esposti proprio attraverso questo meccanismo.

Nonostante contromisure come IMDSv2 e le denylist, la classe di vulnerabilità rimane pericolosa perché dipende da validazioni imperfette, feature legittime mal configurate e permessi troppo ampi.

Mitigazioni immediate da applicare

Ecco un elenco di azioni concrete da adottare subito per ridurre il rischio legato a CVE-2026-89049 e a vulnerabilità simili:

• Patch: aggiornare SSM Agent alla versione 3.3.4851.0 o successiva su tutte le istanze gestite.
• Limitare l’accesso a Session Manager: restringere quali principal IAM possono invocare ssm:StartSession e usare documenti come AWS-StartPortForwardingSessionToRemoteHost.
• Forzare IMDSv2: impostare HttpTokens = required e valutare la disabilitazione di IMDSv1 sulle istanze critiche.
• Controlli di rete: bloccare a livello di firewall le richieste non autorizzate verso 169.254.169.254.
• Logging e monitoraggio: abilitare i log di Session Manager su CloudWatch o S3 e tracciare le chiamate CloudTrail relative a StartSession e STS.
• Automazione della sicurezza: usare AWS Config e Service Control Policies per imporre IMDSv2 e vietare configurazioni obsolete.

Attività di hunting e risposta agli incidenti

Dopo un sospetto di compromissione, è utile cercare segnali specifici nei log:

• Chiamate API anomale associate al ruolo dell’istanza, provenienti da indirizzi o regioni inusuali.
• Invocazioni di StartSession o StartPortForwardingSessionToRemoteHost da utenti non previsti.
• Sessioni Session Manager con port-forwarding verso target non consentiti.
• Chiamate a STS:AssumeRole o GetCallerIdentity subito dopo una sessione SSM sospetta.
• Findings di GuardDuty relativi a un uso anomalo delle credenziali EC2.

Una strategia di difesa in profondità

Il caso di CVE-2026-89049 conferma che nessun singolo controllo è sufficiente. Serve una strategia multilivello:

1. Patch management costante e hardening degli agenti.
2. Least privilege applicato rigorosamente ai ruoli IAM delle istanze.
3. IMDSv2 obbligatorio, con hop-limit configurato correttamente.
4. Segmentazione di rete per isolare l’accesso ai metadata.
5. Logging centralizzato e detection continua tramite CloudTrail, GuardDuty e Detective.

Non bisogna mai affidarsi a un solo strato di protezione, come una denylist basata su stringhe. La sicurezza cloud efficace nasce dalla sovrapposizione di controlli indipendenti.

Conclusione

CVE-2026-89049 non è solo un bug tecnico da patchare: è un promemoria del perché l’IMDS resta una superficie d’attacco permanente nel cloud AWS. Affidarsi a validazioni fragili come le denylist su stringhe letterali espone infrastrutture intere al rischio di furto di credenziali. Le organizzazioni devono agire su più fronti: aggiornare tempestivamente gli agenti, imporre IMDSv2, applicare rigorosamente il principio del least privilege sui ruoli delle istanze, segmentare la rete e mantenere un monitoraggio costante. AWS può correggere le vulnerabilità nei propri componenti gestiti, ma la sicurezza operativa e la configurazione corretta restano, in gran parte, responsabilità del cliente.