Vulnerabilità Brotli di Node.js (CVE-2026-111497): usavamo una versione interessata, l'abbiamo corretta e non abbiamo trovato segni di sfruttamento

Stamattina abbiamo scritto che il problema di sicurezza di PHP non riguardava LFW.com, perché sui nostri server non gira PHP.

Questo invece ci riguardava: il nostro server usava una versione interessata. LFW.com funziona con Node.js, e il progetto Node.js ha pubblicato correzioni di sicurezza oggi alle 6:38 (ora della costa est degli Stati Uniti). Abbiamo aggiornato il nostro server alle 13:24 dello stesso giorno.

Cosa ha corretto Node.js

Il rilascio corregge dieci vulnerabilità nelle versioni 26.x, 24.x e 22.x. Quattro sono di gravità alta. Quella che conta di più per noi:

• CVE-2026-111497, il decodificatore Brotli. Brotli è un modo comune di comprimere il traffico web. Un difetto nel modo in cui Node.js lo decomprime può scrivere oltre la fine di un blocco di memoria. Il progetto Node.js dice che consente l'esecuzione di codice da remoto: far girare il codice di qualcun altro sul suo server.

Alle 14:00 (ora della costa est degli Stati Uniti) del 21 ottobre, né il progetto Node.js né la stampa specializzata segnalano attacchi reali o un exploit pubblico.

Aggiorni a 22.23.4, 24.22.1 o 26.12.1. Node.js dice che le versioni a fine vita sono sempre coinvolte e non ricevono correzioni, quindi le porti a una versione supportata.

Come ci ha raggiunto

Quasi tutto LFW.com è fatto di pagine generate in anticipo. Ma il server svolge anche lavori che comportano scaricare siti web di altre persone:

• l'audit gratuito, che carica qualsiasi sito un visitatore scriva;
• il nostro monitoraggio, che controlla dei siti a orari prestabiliti.

Quando Node.js scarica una pagina, decomprime Brotli automaticamente. Un sito ostile potrebbe quindi rispondere a una di quelle richieste con dati compressi costruiti per corrompere la memoria del nostro server. Nel caso peggiore, l'attaccante può eseguire i propri comandi sul nostro server: leggere ciò che conserva, installare una backdoor o usarlo per attaccare altri siti. L'audit gratuito è la parte più a rischio, perché l'indirizzo lo sceglie uno sconosciuto.

Cosa abbiamo fatto, e quando

La cronologia, in ora della costa est degli Stati Uniti:

• 6:38: il progetto Node.js ha pubblicato le versioni corrette.
• 13:24: abbiamo aggiornato Node.js sul nostro server a 22.23.4 e riavviato il sito.
• Subito dopo: abbiamo cercato sul server segni che qualcuno avesse usato il difetto mentre era aperto.

Sono passate circa sei ore e tre quarti tra la divulgazione pubblica e il nostro aggiornamento. Avremmo preferito meno.

Come abbiamo verificato che nessuno l'abbia sfruttata

Abbiamo iniziato da ciò che il nostro server ha davvero scaricato in quelle ore:

• Nessun audit gratuito è stato eseguito. Nessuno ha chiesto al server di caricare un sito esterno a sua scelta.
• Nessuna scansione di siti è stata eseguita.
• Il monitoraggio ha controllato solo i nostri siti.

Le tracce che un attacco lascia di solito

Poi le abbiamo cercate sul server:

• Nessun crash. Un tentativo fallito di corrompere la memoria di solito fa cadere il programma. I log del server web dell'ultima settimana non mostrano crash, errori di memoria né riavvii forzati.
• Niente di più in esecuzione. L'account del servizio esegue solo il server web e il motore di ricerca, senza programmi estranei avviati da nessuno dei due.
• Niente di nuovo sul disco. Nessuno script o programma nuovo nelle cartelle temporanee, e nessuna modifica alle attività pianificate o alle impostazioni dei servizi oltre al nostro rilascio.
• Nessun nuovo accesso. Gli accessi al server degli ultimi 30 giorni provengono solo dalle nostre due chiavi, e l'elenco delle chiavi autorizzate non cambia da settembre.

Il traffico web

Infine, abbiamo letto ogni richiesta dalla pubblicazione all'aggiornamento:

• Meno traffico del giorno prima, e nessun errore del server.
• Ogni richiesta è passata da Cloudflare. Il nostro firewall accetta traffico web solo da Cloudflare, quindi nulla ha raggiunto il server direttamente.
• Circa 200 sondaggi di routine, il rumore di fondo che riceve ogni sito pubblico. La maggior parte cercava file PHP su un server senza PHP. Ognuno ha ricevuto una risposta di pagina non trovata o non consentita.

Questi controlli trovano i segni abituali di un attacco. Non possono dimostrare che non sia successo nulla, e non lo sosteniamo. Non abbiamo trovato niente.

Dove Cloudflare aiuta, e dove no

Il nostro traffico passa dal proxy di Cloudflare, che filtra le richieste prima che arrivino al nostro server. È una protezione reale per ciò che entra.

Ma la via principale di questo difetto andava nella direzione opposta: il nostro server che legge le risposte di altri siti. Cloudflare non si trova in quella direzione, quindi a correggerlo è stato l'aggiornamento.

Le nostre postazioni di lavoro

Anche le nostre postazioni di lavoro usano Node.js. Non sono esposte a internet, quindi il rischio era più basso. Per scrupolo, abbiamo dato priorità anche al loro aggiornamento a versioni corrette.

Il resto del rilascio

Le altre correzioni vale la pena conoscerle se usa Node.js:

• Due modi per aggirare il controllo del nome nei certificati TLS (CVE-2026-105483 e CVE-2026-106069), entrambi di gravità alta. Il controllo del certificato è il modo in cui un programma sa di parlare con il server giusto.
• Un difetto che tronca i nomi DNS (CVE-2026-105482), di gravità alta: i nomi con un carattere NUL nascosto vengono tagliati.
• Valori casuali ripetuti negli snapshot (CVE-2026-106074), di gravità media. Le applicazioni impacchettate come eseguibile unico o snapshot di avvio potevano ripetere gli stessi identificativi "casuali" in ogni processo.
• Certificati radice aggiornati. Il rilascio aggiorna anche i certificati inclusi in Node.js dopo la compromissione di un'autorità di certificazione intermedia di eMudhra.

L'elenco completo è nell'avviso di Node.js.

Cosa controllare da soli

Se il suo sito o i suoi strumenti funzionano con Node.js:

• Aggiorni a 22.23.4, 24.22.1 o 26.12.1. Contano anche gli strumenti di compilazione.
• Parta da tutto ciò che scarica contenuti esterni: verificatori di link, proxy per immagini, lettori di feed, webhook, scraper. È ciò che il difetto di Brotli raggiunge.
• Ricompili tutto ciò che è impacchettato come eseguibile unico o snapshot. Aggiornare Node.js sul server non aggiorna una copia incorporata in un programma.
• Usa un hosting gestito? Controlli la pagina di stato del suo provider. Molti aggiornano Node.js al posto suo.

Se le serve una mano

Siamo felici di aiutarla su ognuno di questi punti, dal trovare cosa funziona con Node.js al controllo di un server dopo un aggiornamento. Ci scriva.