Red Hat Lightwell: oltre 400 vulnerabilità Java corrette

Lightwell, l’iniziativa per la sicurezza dell’open source di IBM e Red Hat, ha individuato e corretto oltre 400 vulnerabilità finora sconosciute in librerie Java molto diffuse. Lo riportano Infosecurity Magazine (6 ottobre 2026) e CSO Online (9 ottobre 2026), in occasione della disponibilità generale di Lightwell Clearinghouse, il servizio a cui le aziende clienti possono sottoporre le proprie dipendenze open source.

Le fonti sono due e non pubblicano l’elenco delle vulnerabilità né le CVE assegnate: da questa notizia non nascono quindi aggiornamenti specifici da installare. Il tema interessa però chiunque gestisca applicazioni Java in produzione con versioni delle librerie ferme da anni.

Cosa è successo

Secondo Infosecurity Magazine le oltre 400 vulnerabilità sono state corrette dall’avvio del progetto, a giugno, nelle librerie Java «fondamentali»; CSO Online parla di vulnerabilità mai scoperte prima in librerie Java di largo uso. Entrambe le testate riportano l’impegno di IBM e Red Hat: 5 miliardi di dollari e 20.000 ingegneri dedicati al progetto. Secondo CSO Online l’annuncio risale a maggio.

Infosecurity Magazine scrive che il Clearinghouse arriva alla disponibilità generale dopo una fase pilota, e cita tra i primi utenti diverse grandi aziende finanziarie statunitensi e canadesi, tra cui Bank of America, Citi, Goldman Sachs, JPMorganChase, Mastercard, Visa e Wells Fargo. Nelle fonti non compaiono adesioni europee.

Gunnar Hellekson, vicepresidente di Red Hat e responsabile di Lightwell, citato da entrambe le testate, sostiene che gli agenti di IA sfruttano le vecchie dipendenze «alla velocità delle macchine» e che trovare i bug è solo metà del lavoro: il resto è portare le correzioni sulle versioni già in produzione. Infosecurity Magazine collega l’iniziativa anche all’aumento delle segnalazioni di vulnerabilità prodotte con l’IA, spesso rumorose o inesatte, che pesano sui manutentori dei progetti open source.

Come funziona Lightwell

Secondo Infosecurity Magazine, a luglio IBM e Red Hat hanno presentato due offerte:

• Lightwell Network: un flusso continuo di binari firmati digitalmente, codice sorgente e documentazione per la conformità, comprese le SBOM (software bill of materials) complete;
• Lightwell Clearinghouse Premier: per clienti selezionati che usano in produzione versioni bloccate (pinned) e hanno bisogno di correzioni mirate e di backport.

Il flusso del Premier, come lo descrive la testata:

1. il cliente segnala una vulnerabilità legata a un pacchetto e a una versione precisi;
2. Red Hat la analizza e ne stabilisce gravità, applicabilità e rimedio;
3. sviluppa una patch o un backport per quella versione;
4. si coordina con il progetto upstream perché la correzione sia tecnicamente accettabile;
5. compila il pacchetto corretto sulla propria infrastruttura;
6. il risultato è firmato e attestato, con la provenienza verificabile;
7. il cliente installa il binario, senza dover ripetere da sé correzione e validazione.

Secondo Red Hat le correzioni arrivano da repository protetti che si integrano con scanner, repository, pipeline CI/CD e processi di validazione già in uso.

Il quadro tecnico: le dipendenze bloccate

Le fonti non descrivono attacchi né indicatori di compromissione: il punto tecnico è la gestione delle dipendenze. Nelle applicazioni Java una libreria arriva spesso come dipendenza transitiva, tramite Maven o Gradle, e finisce impacchettata dentro un JAR o un WAR: non compare tra i pacchetti del sistema operativo e sfugge agli inventari tradizionali. Quando la correzione esce solo su una versione più recente, aggiornare può voler dire cambiare API e ritestare l’applicazione, e per questo molte aziende restano su versioni vecchie. Il backport serve proprio a portare la sola correzione sulla versione in uso.

Come esempio del tipo di difetto che il servizio cercherà, CSO Online cita il bypass della sandbox del motore di template Thymeleaf, critico (CVSS 9.1), scoperto ad aprile; la testata non indica il numero CVE né le versioni colpite. Quando una libreria vulnerabile è raggiungibile da un’applicazione esposta su Internet, lo sfruttamento rientra nella tecnica MITRE ATT&CK T1190 (Exploit Public-Facing Application).

CSO Online ricorda infine che Lightwell non è l’unica iniziativa sul tema: Azul offre una valutazione gratuita del rischio di vulnerabilità per le Java Virtual Machine.

Impatto per le aziende europee e italiane

Per i soggetti NIS2 la sicurezza della catena di approvvigionamento e la gestione delle vulnerabilità nello sviluppo e nella manutenzione dei sistemi sono misure richieste dalla direttiva, e le librerie open source dentro le applicazioni ne fanno parte. Banche e altri soggetti finanziari, come i primi utenti citati, devono inoltre gestire il rischio ICT, anche di terze parti, secondo il regolamento DORA. Chi produce software venduto nell’Unione deve rispettare anche il Cyber Resilience Act, che chiede di documentare i componenti e di gestirne le vulnerabilità.

Lightwell è un servizio commerciale per i clienti Red Hat: le fonti non dicono se e quando le correzioni saranno disponibili per tutti nelle versioni pubblicate dai progetti originali.

Cosa fare subito

1. Fai l’inventario delle librerie Java delle tue applicazioni, comprese le dipendenze transitive, generando una SBOM a ogni build.
2. Individua le versioni bloccate da tempo e chi ne è responsabile: sono quelle per cui una correzione può non arrivare mai dal progetto originale.
3. Confronta la SBOM con le vulnerabilità note in modo continuo, non solo al rilascio: nuove CVE emergono anche su versioni ferme.
4. Controlla se usi Thymeleaf e verifica negli avvisi ufficiali del progetto quali versioni correggono il bypass della sandbox.
5. Dai priorità alle applicazioni esposte su Internet e alle librerie raggiungibili da input esterno.
6. Chiedi ai fornitori di software e ai partner di sviluppo le SBOM e i tempi di correzione per le librerie che includono.

Come aiuta ARXDOME

ARX Shield mostra le vulnerabilità aperte per macchina e per pacchetto, con la loro età e quelle già sfruttate in evidenza, e ARX Sentry tiene l’inventario del software installato su computer e server. Le librerie impacchettate dentro le applicazioni vanno invece controllate con la SBOM nella pipeline di sviluppo. ARX Expose aggiunge la vista da fuori: le vulnerabilità note sui servizi pubblici e i prodotti riconosciuti sulla superficie d’attacco.

Ultimo aggiornamento: 9 ottobre 2026