Falla Linux, dopo Cardano tocca a Solana: Anza allerta i validatori su Ubuntu, mentre Red Hat pubblica le correzioni

Aggiornamento del 2 novembre 2026, 05:55 UTC: Anza, che sviluppa blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il client per validatori Agave di Solana, ha chiesto ai validatori su Ubuntu di filtrare il traffico in ingresso e disattivare due funzioni di rete in attesa di un kernel corretto, come hanno riferito The Defiant e TokenPost nella serata del 1° novembre, ora statunitense. Red Hat ha pubblicato il 1° novembre kernel corretti per RHEL 8, 9 e 10, secondo i suoi avvisi. Il tracker di Ubuntu, aggiornato l’ultima volta il 30 ottobre, non mostrava ancora alcuna correzione quando l’abbiamo letto il 2 novembre. Nulla di quanto abbiamo letto indica una scadenza o la quota di stake di Solana interessata.

Il 30 ottobre Intersect, l’organizzazione che riunisce i membri della rete, ha chiesto agli operatori di stake pool Cardano di controllare il kernel Linux dei loro block producer e relay, poi di installare un kernel corretto e riavviare appena la propria distribuzione ne pubblica uno. La falla, CVE-2026-98432, ha un punteggio CVSS di 9,8 su 10. È un difetto del kernel Linux, non di Cardano, e l’aggiornamento settimanale di Intersect non dice nulla su fondi, consenso o sfruttamento.

Gli operatori su Ubuntu non possono ancora seguire il consiglio. Quando abbiamo letto il suo tracker il 2 novembre, aggiornato l’ultima volta il 30 ottobre, tutte e sette le versioni elencate, dalla 16.04 alla 26.10, risultavano vulnerabili. Red Hat, che il 31 ottobre non indicava alcun kernel corretto, ha poi pubblicato le correzioni per RHEL 8, 9 e 10. Nelle fonti che abbiamo letto non risultano sfruttamenti in corso, e la falla non era nel catalogo CISA delle vulnerabilità note e sfruttate (ancora alla versione 2026.10.30) quando l’abbiamo controllato il 2 novembre. Questo vale per quelle fonti: non dimostra che nessun attacco esista.

Anza chiede ai validatori Solana su Ubuntu di intervenire sulla stessa falla

Solana è la seconda rete i cui operatori, a quanto ci risulta, hanno ricevuto l’allerta. The Defiant ha riferito alle 00:23 UTC del 2 novembre che Anza ha chiesto agli operatori su Ubuntu di filtrare il traffico in ingresso e disattivare due funzioni di rete in attesa di un kernel corretto. TokenPost ha dato la stessa notizia alle 19:26 ora della costa est statunitense del 1° novembre, cioè alle 00:26 UTC del 2 novembre. Non abbiamo trovato una copia pubblica dell’avviso di Anza, quindi queste informazioni si basano su quegli articoli.

Le misure sono state rilanciate da Tim Garcia, che guida le relazioni con i validatori alla Solana Foundation. Secondo TokenPost, ha detto che la falla del kernel è stata corretta ma Ubuntu non ha ancora rilasciato una patch, e che nel frattempo i validatori devono bloccare i pacchetti TCP in ingresso con opzioni IPv4, disattivare Multipath TCP e disattivare la migrazione dei socket di richiesta TCP. Il consiglio è temporaneo e riguarda i validatori su Ubuntu, non tutti i validatori di Solana. La terza misura ha un riscontro nel testo del CVE, che descrive un problema simile nella migrazione dei socket di richiesta quando l’impostazione net.ipv4.tcp_migrate_req vale 1.

Ubuntu conta per quello che documenta Anza: la sua pagina dei requisiti dice «We build and run on Ubuntu 24.04» (compiliamo ed eseguiamo su Ubuntu 24.04) e richiede un indirizzo IPv4 pubblico. L’articolo di The Defiant, ripreso da cryptonews.net, data l’allerta al 1° novembre e spiega che il controllo di un host potrebbe esporre la chiave d’identità del validatore conservata sulla macchina, mentre un crash del kernel potrebbe interrompere la produzione di blocchi. La pagina sulla sicurezza di Anza limita in partenza un altro rischio: la coppia di chiavi di prelievo «non dovrebbe mai essere conservata sul validatore, in nessun momento».

Diverse cose non si sanno. Nessuna fonte che abbiamo letto indica una scadenza, la quota di stake di Solana su Ubuntu o quanta parte abbia applicato le misure. Nessuna dice che un validatore sia stato colpito, né se il software di validazione apra un listener MPTCP, la condizione del proof of concept pubblicato. Non abbiamo potuto stabilire nemmeno se gli operatori di altri client Solana abbiano ricevuto indicazioni separate.

Le obiezioni sono arrivate la stessa sera. TokenPost riferisce che 23pds, responsabile della sicurezza informatica di SlowMist, contesta l’idea che ogni sistema Ubuntu offra un accesso root senza clic. Secondo l’articolo, lo sfruttamento richiede un server in ascolto su MPTCP, funzione che Linux non attiva di default, e lui non ha visto conferme ufficiali di sfruttamento su larga scala. La tesi si concilia male con l’avvertimento di Damien Neil, di Go, riportato più avanti, secondo cui la causa radice non è specifica di MPTCP.

Cosa ha detto Intersect agli operatori di stake pool Cardano

L’avviso è fatto di poche righe, sotto il titolo «Security advisory for SPOs», nella sezione sugli aggiornamenti di Cardano dell’update settimanale n. 135. Non abbiamo trovato un post a sé. Dice che esistono kernel corretti per alcune distribuzioni mentre altre, Ubuntu compresa, stanno ancora preparando i propri, e rimanda alla pagina di Ubuntu sulla falla.

«Se gestite uno stake pool, controllate quale kernel usano il vostro block producer e i vostri relay», ha scritto Intersect. Gli operatori devono poi applicare il kernel corretto e riavviare. Altre indicazioni sono promesse su X e nei canali degli SPO. L’avviso non entra in dettagli tecnici e non propone alcuna soluzione temporanea.

Non va confuso con la pre-release di Node 11.2 che compare nello stesso aggiornamento. Quella versione contiene le funzioni dell’hard fork Dijkstra, senza Leios, il lavoro di scalabilità di cui abbiamo raccontato questa settimana il merge del codice. Aggiornare cardano-node cambia il software del nodo, non il kernel del sistema operativo, quindi non serve contro questa falla.

CVE-2026-98432 è una race condition nel codice TCP di Linux

Secondo la descrizione di Ubuntu, il difetto sta nella gestione TCP su IPv4 del kernel. Quando una connessione viene stabilita, la memoria che contiene le sue opzioni IP può essere liberata mentre un altro core del processore la sta ancora leggendo per costruire la risposta a una richiesta di connessione ritrasmessa. Leggere memoria già liberata si chiama use-after-free. La correzione rinvia il rilascio di quella memoria finché nessun lettore può ancora usarla.

Il bollettino RHSB-2026-016 di Red Hat, del 30 ottobre, afferma che un aggressore remoto e non autenticato potrebbe sfruttare la race condition, arrivando potenzialmente all’esecuzione di codice da remoto. Aggiunge: «Lo sfruttamento richiede una tempistica precisa delle richieste di rete, ma non richiede privilegi né interazione dell’utente». Secondo Red Hat è colpito qualsiasi sistema con un kernel vulnerabile e la rete TCP su IPv4 attiva, e in modo più diretto le macchine che accettano connessioni TCP in ingresso. Il record del CVE indica 4.4 come prima versione del kernel interessata ed elenca le correzioni upstream nelle versioni stabili 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 e 7.2.10.

Due date: il CVE del 15 ottobre, l’analisi dell’exploit del 27 ottobre

Ubuntu e il National Vulnerability Database statunitense indicano entrambi il 15 ottobre come data di pubblicazione del CVE. La pagina di Ubuntu è stata aggiornata l’ultima volta il 30 ottobre, il record dell’NVD il 31 ottobre. Il post di ricerca di Anthropic, che descrive un exploit per la falla, è datato 27 ottobre. Quella data appartiene al post: la pagina non ne riporta una per il CVE in sé. L’avviso di Intersect è arrivato tre giorni dopo.

Le correzioni sono arrivate nei rami stabili del kernel upstream, ma i clienti di Red Hat hanno aspettato fino al 1° novembre, diciassette giorni dopo la comparsa del record del CVE, e quelli di Ubuntu erano ancora in attesa il 2 novembre. Gli avvisi di Red Hat precisano che serve un riavvio. Il suo bollettino, ancora datato 30 ottobre quando l’abbiamo riletto, continua a dire che le correzioni sono in via di accelerazione: i dati del CVE e gli avvisi sono più recenti. Lo stato per distribuzione, come letto il 2 novembre:

Un maintainer di MPTCP mette in dubbio il punteggio di 9,8

Il post di Anthropic racconta che il suo modello di IA Claude, dopo un primo suggerimento, ha scritto un exploit che permette a un aggressore remoto di eseguire comandi come root, senza credenziali, su server Linux con un listener multipath TCP (MPTCP). Il proof of concept ha impiegato 48 minuti per ottenere un puntatore del kernel e altri cinque per eseguire un comando. Secondo il post, una gara persa fa solo fallire l’handshake, quindi l’aggressore può riprovare.

Matthieu Baerts ha messo in discussione questo quadro il 30 ottobre, in una discussione sul tracker di Go. Il file MAINTAINERS del kernel Linux lo indica come maintainer del codice MPTCP, anche se nel suo commento non ha dichiarato alcun ruolo. Ha scritto che il riproduttore è stato eseguito in laboratorio, ha inviato un numero enorme di richieste di connessione e ha usato MPTCP perché, per fortuna, richiedeva meno tempo del TCP. Ha aggiunto di essere «abbastanza sicuro» che le opzioni IPv4 siano già bloccate su molte reti e che l’attacco sembri molto improbabile fuori dal laboratorio. «Non ho idea di come abbiano ottenuto un punteggio di 9,8 in certi posti», ha scritto, definendo il post una «pubblicità».

Il giorno prima, Damien Neil, rispondendo per il progetto Go nella stessa discussione, era stato più prudente. Il 29 ottobre ha scritto che la causa radice «non è specifica di MPTCP». Per quanto ne sapeva, nessuno poteva dire se l’esecuzione di codice fosse possibile senza un listener MPTCP, e sconsigliava di sperare di no. L’avviso di sicurezza del team Go della stessa data indica un kernel aggiornato come soluzione migliore.

Le valutazioni ufficiali non chiariscono la questione. Red Hat definisce la falla Critical e così classifica il suo avviso per RHEL 8, anche se quello per RHEL 9, che raggruppa 18 CVE, e quello per RHEL 10 hanno come valutazione complessiva Important. Il 31 ottobre la sua pagina sul CVE definiva preliminari i valori CVSS; il 2 novembre quella dicitura non c’era più. La pagina dice ancora che un’esecuzione di codice affidabile richiede un controllo preciso dell’heap e che la falla provoca soprattutto un crash o una possibile corruzione della memoria. Ubuntu mostra 9,8 con priorità High. Il 2 novembre il record dell’NVD riportava ancora lo stato «Received», cioè l’NVD non l’ha ancora analizzato.

Cosa non si sa sui nodi Cardano

Nessuna delle fonti che abbiamo letto dice se un host con cardano-node possa essere attaccato tramite questa falla, né se quel software apra un listener MPTCP, la condizione del proof of concept pubblicato. In generale i relay accettano connessioni TCP in ingresso dalla rete, e Red Hat indica proprio queste macchine come le più direttamente esposte. È una nostra lettura di come funzionano i relay, non una conclusione sulla rete Cardano tratta da una fonte.

L’avviso di Intersect non cita fondi né consenso, e nessuna fonte che abbiamo letto collega la falla all’uno o all’altro. Il difetto riguarda i sistemi operativi dei server, non il protocollo Cardano. Delegare non consegna gli ADA a un pool: «I tuoi ada restano nel tuo wallet e puoi spenderli in qualsiasi momento», scrive cardano.org.

Al 31 ottobre non avevamo trovato una dichiarazione separata della Cardano Foundation o di Input Output. Quello di Anza è l’unico avviso di un’altra blockchain che abbiamo trovato, anche se la descrizione di Red Hat riguarda qualsiasi sistema Linux con un kernel vulnerabile e il TCP su IPv4 attivo.

Cosa possono fare ora gli operatori Cardano e Solana

I passaggi che seguono vengono da Intersect e dai fornitori. Né l’avviso di Intersect né gli articoli su quello di Anza danno istruzioni a chi delega il proprio staking. Non abbiamo potuto leggere l’avviso di Anza, quindi non riportiamo righe di comando per le sue misure: i validatori su Ubuntu devono prenderle da quell’avviso.

1. Controllare quale kernel usano il block producer e ogni relay, come chiede Intersect.
2. Confrontarlo con la pagina di sicurezza della propria distribuzione, perché la versione corretta cambia da una release all’altra.
3. Installare il kernel corretto appena viene pubblicato, poi riavviare. Intersect cita esplicitamente il riavvio, e gli avvisi di Red Hat precisano che il sistema va riavviato perché l’aggiornamento abbia effetto.
4. Chi usa AlmaLinux può aiutare a provare i kernel del repository di test, che il progetto invita a verificare prima di usarli in produzione.
5. Il bollettino di Red Hat riporta una regola nftables provvisoria che scarta i pacchetti TCP IPv4 in ingresso con opzioni IP. Precisa che la regola riduce l’esposizione ma non può impedire del tutto lo sfruttamento, e che può disturbare alcuni carichi di lavoro, quindi va provata prima.
6. Solo per chi usa AlmaLinux, non un’istruzione di Anza: il post di AlmaLinux del 30 ottobre dice che, se MPTCP è attivo e non serve, va eseguito sudo sysctl -w net.mptcp.enabled=0. Blocca solo i nuovi socket MPTCP, precisa, quindi i listener ancora aperti vanno elencati con sudo ss -lnMp e i servizi che li gestiscono vanno riavviati.

Red Hat è chiara sui limiti del suo filtro: «Applicare gli aggiornamenti di sicurezza del kernel appena disponibili è l’unica soluzione completa».

Da seguire nei prossimi giorni: i kernel corretti di Ubuntu, i prodotti Red Hat ancora da correggere, l’analisi del punteggio da parte dell’NVD, ogni modifica al catalogo CISA, le ulteriori indicazioni promesse da Intersect e un eventuale testo pubblico di Anza.