Log4Shell: risolta nel 2021, la troviamo ancora nel 2026

Log4Shell è il nome con cui è nota la vulnerabilità CVE-2021-44228, che colpisce Log4j, una libreria per la gestione dei log presente in una quantità enorme di applicazioni scritte in Java. È stata divulgata il 9 dicembre 2021 e ha ricevuto da Apache il punteggio di gravità massimo previsto dalla scala CVSS.

La correzione è disponibile da pochi giorni dopo, è pubblica e non costa nulla. Nonostante questo continuiamo a trovarla nei nostri rilievi, e non su sistemi dimenticati in un angolo. Il motivo è che nessuno aggiorna una libreria di cui non sa di avere una copia, e Log4j nella maggior parte dei casi non è un software che si è scelto di installare: è dentro qualcos’altro.

Vediamo che cosa fa Log4j, dove nasce il difetto, quali versioni sono interessate e perché il problema sopravvive alla propria correzione.

1. Che cos’è Log4j
2. Dove nasce il difetto
3. Chi è esposto
4. Cosa permette di fare a un attaccante
5. Versioni interessate e correzioni
6. Perché nel 2026 è ancora un problema

Che cos’è Log4j

Log4j, che sta per Logging for Java, è una libreria open source della Apache Software Foundation e serve a scrivere i file di log delle applicazioni. Un file di log è il registro di quello che un programma ha fatto: errori, accessi, richieste ricevute, valori elaborati.

Registrare cosa succede è una delle prime cose che si programmano, in qualsiasi applicazione, e nel mondo Java lo strumento con cui si fa è Log4j. Ecco perché una sola vulnerabilità ha avuto una portata di quel tipo: non era un prodotto compromesso, era un pezzo presente dentro migliaia di prodotti diversi.

Va detto che la libreria in sé non è concepita male. Il difetto riguarda una funzione specifica, introdotta anni prima che qualcuno se ne accorgesse, che in condizioni non previste si è rivelata sfruttabile.

Dove nasce il difetto

Le versioni interessate di Log4j supportavano un meccanismo di sostituzione: alcune sequenze di caratteri inserite nel testo da registrare non venivano scritte così com’erano, ma sostituite con un valore recuperato altrove. Serviva a mettere nei log informazioni dinamiche, come una variabile d’ambiente o un parametro di configurazione.

Fra le fonti da cui pescare quel valore c’era anche un’interfaccia che interroga servizi di directory, e che in certe configurazioni va a cercarlo su un server remoto. Fuori dall’azienda, cioè.

Il difetto sta nel fatto che il testo da registrare arriva spesso dall’esterno. Un’applicazione web scrive nei log l’indirizzo di chi si collega, il tipo di browser, i parametri delle richieste che riceve. Se dentro uno di quei valori compare la sequenza di sostituzione, la libreria non la tratta come testo da scrivere: la legge come istruzione, e va a contattare l’indirizzo indicato.

È lo stesso meccanismo di fondo delle vulnerabilità di injection: un dato che arriva da fuori finisce in un contesto dove viene interpretato come codice, perché il confine fra i due non è mai stato tracciato.

Chi è esposto

La domanda difficile non è quali prodotti contengono Log4j, ma se lo si sa. Ed è qui che sta la vera dimensione del problema.

Un’azienda che ha sviluppato in casa un’applicazione Java può andare a guardare le proprie dipendenze e togliersi il dubbio. Il problema è tutto il resto: Log4j sta anche dentro software commerciali comprati da terzi, dentro apparati di rete con firmware Java, dentro strumenti di gestione e monitoraggio, dentro servizi che vi eroga un fornitore. In tutti questi casi la libreria c’è e nessuno l’ha mai scritta su un inventario.

Questa è la differenza fra la vulnerabilità di un prodotto e la vulnerabilità di una dipendenza. Nel primo caso si sa cosa aggiornare. Nel secondo bisogna prima scoprire dove si trova, e cercarla vuol dire guardare dentro componenti che non ha scritto nessuno in azienda e di cui spesso non si ha il codice.

Il tema va oltre Log4j: qualsiasi componente di terze parti incluso in un’applicazione porta con sé le proprie vulnerabilità, e negli standard OWASP i componenti obsoleti sono una categoria a sé proprio per questo.

Cosa permette di fare a un attaccante

Log4Shell rientra nell’esecuzione di codice da remoto, che è la classe più grave. Chi la sfrutta non ottiene la lettura di un dato o l’accesso a una funzione: ottiene la possibilità di far girare istruzioni proprie sul sistema colpito.

Da lì quanto è grave dipende da come è configurato quel sistema, non dalla vulnerabilità. Con quali privilegi gira il processo dell’applicazione, cosa riesce a raggiungere in rete, se la macchina è isolata o parla con i sistemi interni. Sono le stesse variabili che decidono l’ampiezza del danno in qualsiasi compromissione.

Nelle campagne partite subito dopo la divulgazione l’uso più comune non è stato spettacolare: installare software che estrae criptovaluta sfruttando la potenza di calcolo delle macchine colpite. Poi l’inserimento in reti di dispositivi pilotati da remoto, e in altri casi l’accesso è stato semplicemente rivenduto a qualcun altro, oppure usato come punto di partenza per un attacco ransomware.

Il primo è quello di cui è più difficile accorgersi, perché non rompe niente: un server che macina criptovaluta per conto di terzi continua a fare il suo lavoro, solo più piano.

Versioni interessate e correzioni

La sequenza di quei rilasci è la parte più istruttiva della vicenda. Quattro versioni in poche settimane, perché la prima correzione era stata fatta di corsa e non copriva tutti i casi. Chi ha aggiornato alla 2.15.0 a dicembre e ha considerato chiusa la faccenda è rimasto scoperto per settimane senza saperlo.

Chi ha aggiornato alla 2.15.0 a dicembre e ha considerato chiusa la faccenda è rimasto scoperto per settimane senza saperlo. Su cosa resta oggi di quegli interventi, e su come verificarlo, abbiamo scritto in la patch del 2021 potrebbe non esserci più.

Una nota pratica: verificare la versione in uso non è sempre banale. La libreria può essere inclusa dentro un pacchetto applicativo, e in quel caso la versione che conta non è quella dichiarata dal software, ma quella che sta davvero nei suoi componenti.

Perché nel 2026 è ancora un problema

Sul piano della libreria, Log4Shell è chiuso da anni. Sul piano dei sistemi reali no, e le ragioni sono tre.

La prima è l’inventario che non c’è. Non si aggiorna una libreria di cui non si sa di avere una copia, e questo vale soprattutto per i software forniti da terzi.

La seconda è il software che non si aggiorna. Applicazioni fatte su misura anni prima, il cui fornitore non esiste più o non fa più manutenzione, restano alla versione con cui sono state consegnate. Il caso rientra nella categoria più larga delle vulnerabilità che non si possono correggere, dove l’unica strada è il contenimento.

La terza è che i sistemi interni vengono controllati con molta meno attenzione di quelli esposti su internet. Dopo dicembre 2021 la corsa all’aggiornamento ha riguardato in prevalenza il perimetro raggiungibile da fuori. Gli strumenti di gestione, i sistemi di monitoraggio e gli apparati che parlano solo con la rete interna sono stati guardati meno, e un attaccante che ha già ottenuto un accesso trova lì una vulnerabilità con punteggio dieci ancora sfruttabile.

Log4Shell resta un tema non perché sia irrisolta, ma perché è il caso più documentato di una cosa che vediamo continuamente: la correzione esiste, è pubblica, è gratuita, e non è arrivata dove doveva arrivare. È lo stesso motivo per cui nei nostri report finiscono ancora vulnerabilità del 2013 e del 2017.