Esposte le credenziali della PA col caso “FortiBleed” e scatta l’allerta sicurezza per i container AWS

Due segnalazioni di sicurezza emerse nello stesso periodo richiamano l’attenzione su componenti fondamentali delle infrastrutture digitali moderne. Da un lato il CERT-AGID ha diffuso un alert relativo a FortiBleed, un vasto archivio contenente credenziali associate a dispositivi Fortinet esposti su internet che coinvolge anche organizzazioni della Pubblica Amministrazione italiana. Dall’altro, AWS ha pubblicato il bollettino di sicurezza 2026-046, che descrive cinque vulnerabilità critiche e ad alta gravità nel plugin CRI di containerd, uno dei componenti più utilizzati nei cluster Kubernetes e nei servizi containerizzati gestiti. Sebbene i due casi abbiano natura differente, entrambi evidenziano rischi significativi per la sicurezza delle organizzazioni: l’esposizione di credenziali privilegiate e la possibilità di compromettere ambienti container attraverso esecuzione di codice arbitrario, accesso non autorizzato o denial of service.

FortiBleed espone migliaia di credenziali Fortinet in tutto il mondo

Il caso FortiBleed riguarda un archivio contenente credenziali associate a dispositivi FortiGate utilizzati principalmente per servizi SSL VPN e interfacce di amministrazione remota. Il dataset è stato individuato dal ricercatore Bob Diachenko su un server accessibile pubblicamente e contiene informazioni riferite a 73.932 URL unici, distribuiti su 21.632 domini presenti in 194 paesi. All’interno dell’archivio figurano nomi utente, indirizzi email, password in chiaro e metadati che consentono di identificare le organizzazioni coinvolte. I settori interessati comprendono telecomunicazioni, finanza, servizi IT, sanità, istruzione, industria manifatturiera e pubblica amministrazione. La portata globale dell’esposizione rende FortiBleed uno degli incidenti più rilevanti degli ultimi mesi nel panorama della sicurezza delle infrastrutture di accesso remoto.

Il dataset non deriva da una vulnerabilità zero-day di FortiOS

Le analisi condotte finora indicano che il dataset non è il risultato di una vulnerabilità zero-day all’interno di FortiOS. Gli attaccanti avrebbero invece sfruttato tecniche consolidate e ampiamente utilizzate nel cybercrime. Tra queste figurano campagne di credential stuffing basate su credenziali provenienti da precedenti violazioni, utilizzo di log raccolti tramite infostealer, attacchi brute force contro interfacce VPN e pannelli amministrativi esposti pubblicamente e attività di cracking offline degli hash di autenticazione mediante cluster GPU. Le statistiche associate all’indagine mostrano circa 1,16 miliardi di tentativi di autenticazione contro oltre 320.000 dispositivi FortiGate raggiungibili da internet. Questo dato evidenzia come gli apparati di accesso remoto continuino a rappresentare uno degli obiettivi preferiti dagli attori malevoli interessati a ottenere un punto di ingresso nelle reti aziendali.

La Pubblica Amministrazione italiana figura tra i soggetti coinvolti

Il CERT-AGID ha confermato la presenza di enti appartenenti alla Pubblica Amministrazione italiana tra le organizzazioni interessate dal dataset. Le amministrazioni coinvolte sono state informate attraverso i canali istituzionali e sono state avviate attività di verifica per determinare l’eventuale validità delle credenziali esposte. Il rischio non riguarda esclusivamente gli enti già identificati. Qualsiasi organizzazione che utilizzi dispositivi FortiGate con accessi remoti pubblicamente raggiungibili potrebbe risultare vulnerabile qualora credenziali compromesse siano ancora attive. Un accesso valido a una VPN o a un’interfaccia amministrativa consente infatti agli aggressori di osservare traffico autenticato, raccogliere informazioni operative e tentare movimenti laterali verso sistemi interni, inclusi Active Directory, server di posta elettronica, piattaforme documentali e infrastrutture critiche.

Le misure raccomandate dal CERT-AGID per mitigare FortiBleed

Le indicazioni fornite dal CERT-AGID sono particolarmente stringenti. La priorità consiste nell’abilitare l’autenticazione multifattore (MFA) per tutti gli accessi remoti, incluse le connessioni SSL VPN e le console di gestione amministrativa. Gli enti sono inoltre invitati a limitare l’esposizione pubblica delle interfacce di amministrazione mediante ACL, policy local-in e restrizioni basate su indirizzi IP autorizzati. Un altro passaggio fondamentale riguarda la rotazione immediata delle credenziali amministrative e VPN, soprattutto per gli account privilegiati o condivisi. Gli amministratori devono analizzare con attenzione i log di autenticazione alla ricerca di anomalie geografiche, accessi provenienti da ASN inattesi, orari inconsueti, user agent sospetti o pattern di autenticazione ripetuti. Il CERT sottolinea inoltre che l’analisi non deve concentrarsi esclusivamente sui tentativi falliti, ma anche sugli accessi riusciti, poiché un singolo login valido proveniente da una fonte anomala può rappresentare un segnale di compromissione. L’aggiornamento di FortiOS rimane importante ma non è sufficiente se le credenziali risultano già esposte o riutilizzate.

AWS pubblica cinque vulnerabilità nel plugin CRI di containerd

Parallelamente all’allerta FortiBleed, AWS ha pubblicato il bollettino 2026-046 dedicato a cinque vulnerabilità individuate nel plugin CRI di containerd, il runtime container open source utilizzato estensivamente all’interno di Kubernetes. Le falle interessano le versioni comprese tra containerd 1.7 e 2.3 e coinvolgono direttamente piattaforme come Amazon EKS, Amazon ECS, AWS Fargate, Bottlerocket e Amazon Linux. Il plugin CRI rappresenta uno dei componenti fondamentali della comunicazione tra Kubernetes e il runtime dei container, motivo per cui eventuali vulnerabilità possono avere impatti rilevanti sull’intero ambiente di orchestrazione. Le problematiche individuate spaziano dall’esecuzione di codice arbitrario fino al denial of service, passando per lettura non autorizzata di file e bypass di controlli di sicurezza.

CVE-2026-50195 e CVE-2026-53488 rappresentano i rischi più elevati

La vulnerabilità con il punteggio più alto è CVE-2026-50195, classificata con CVSS 8.8. Il problema interessa ambienti che utilizzano la funzione checkpoint/restore e consente un attacco di cache poisoning delle immagini container su nodi Kubernetes condivisi. Un aggressore può sfruttare questa condizione per eseguire codice arbitrario all’interno di pod appartenenti ad altri workload presenti sullo stesso nodo. La seconda vulnerabilità più critica è CVE-2026-53488, valutata CVSS 8.3, che permette l’esecuzione di comandi arbitrari sull’host attraverso istruzioni LABEL non adeguatamente sanificate all’interno delle immagini container. A differenza della precedente, questa falla non richiede necessariamente l’utilizzo della funzione checkpoint/restore, ampliando il numero di ambienti potenzialmente esposti. Entrambe le vulnerabilità evidenziano come la gestione dei metadati nelle immagini container possa trasformarsi in un vettore di attacco capace di compromettere direttamente il nodo sottostante.

Le altre tre CVE coinvolgono dispositivi, file host e denial of service

Le ulteriori vulnerabilità segnalate da AWS riguardano scenari differenti ma comunque rilevanti. CVE-2026-53492, con punteggio CVSS 6.8, sfrutta annotazioni CDI (Container Device Interface) provenienti da immagini non attendibili per iniettare dispositivi e mount sull’host, aggirando parte dei controlli di isolamento previsti da Kubernetes quando CDI è abilitato. CVE-2026-53489, classificata CVSS 6.5, consente invece la lettura arbitraria di file presenti sull’host tramite percorsi simbolici non correttamente validati durante il ripristino da checkpoint. L’ultima falla, CVE-2026-47262, anch’essa con CVSS 6.5, provoca un consumo incontrollato della memoria che può terminare il processo containerd e generare un denial of service per tutti i container eseguiti sul nodo colpito. Sebbene abbiano punteggi inferiori rispetto alle prime due vulnerabilità, queste problematiche possono comunque avere impatti significativi in ambienti di produzione che ospitano applicazioni mission critical.

AWS distribuisce le correzioni ma gli ambienti self-managed richiedono interventi immediati

Per i servizi completamente gestiti, AWS ha già avviato la distribuzione delle versioni corrette dei componenti interessati. Le organizzazioni che utilizzano Amazon EKS, ECS o Fargate in modalità gestita beneficeranno delle mitigazioni attraverso i normali processi di aggiornamento del provider. Diversa la situazione per chi gestisce autonomamente cluster Kubernetes su Amazon EC2 o infrastrutture on-premise. In questi casi è necessario aggiornare manualmente containerd alle versioni corrette nel più breve tempo possibile. AWS segnala inoltre la possibilità di adottare misure temporanee come la disabilitazione delle funzionalità checkpoint/restore e del supporto CDI per ridurre l’esposizione ad alcune delle vulnerabilità identificate. Tuttavia, per diversi dei problemi descritti, l’aggiornamento rimane l’unica mitigazione realmente efficace.

Credenziali e runtime container restano tra gli obiettivi principali degli attaccanti

Le segnalazioni relative a FortiBleed e alle vulnerabilità di containerd mostrano come gli attaccanti continuino a concentrarsi sui punti più strategici delle infrastrutture moderne. Le credenziali di accesso remoto rappresentano ancora una delle vie più rapide per compromettere reti aziendali e pubbliche amministrazioni, mentre i runtime container costituiscono un bersaglio privilegiato in ambienti cloud e Kubernetes sempre più diffusi. Nel primo caso il rischio nasce dalla riutilizzazione delle credenziali e dalla scarsa protezione degli accessi remoti; nel secondo dall’esposizione di componenti software fondamentali che orchestrano l’esecuzione dei workload. Entrambi gli scenari confermano che la sicurezza non dipende esclusivamente dall’assenza di vulnerabilità software, ma anche dalla corretta gestione delle identità, dalla segmentazione degli accessi e dalla rapidità con cui vengono applicate patch e misure di mitigazione.