Nelle ultime due settimane due vulnerabilità critiche hanno colpito i due livelli su cui poggia ogni sito web: il kernel Linux, che accetta le connessioni, e PHP, che esegue il codice delle applicazioni.
La prima è CVE-2026-98432, un use-after-free nello stack TCP IPv4 del kernel, sfruttabile da remoto senza credenziali. La seconda è php2shell, il nome dato a due vulnerabilità di esecuzione di codice remoto pre-autenticazione in PHP: CVE-2026-109618 e CVE-2026-109619.
In questo articolo spieghiamo cosa sono, perché sono pericolose e come siamo intervenuti sui server di hosting e su quelli che gestiamo per i clienti: rapidamente, ma con un metodo che protegge i servizi di chi ci ha affidato la propria infrastruttura.
CVE-2026-98432: il kernel Linux e l’handshake TCP
Il difetto è in tcp_v4_syn_recv_sock(), la funzione del kernel che completa una connessione TCP IPv4 in ingresso. Se arriva un SYN ritrasmesso mentre il socket figlio viene distrutto, le opzioni IP del pacchetto vengono liberate subito con una kfree(), senza attendere un periodo di grazia RCU. Un altro percorso del kernel può quindi leggere quella memoria già liberata, in ip_options_build().
È una classica race condition di tipo use-after-free (CWE-416). Un secondo percorso, più stretto, passa dalla migrazione delle richieste tra socket in ascolto e si attiva solo con net.ipv4.tcp_migrate_req=1 (il default è 0). Il difetto è stato introdotto dal commit 079096f103fa e il fix, scritto da Eric Dumazet, libera le opzioni con kfree_rcu().
Pubblicato: 15 ottobre 2026 dal team CVE del kernel; punteggio assegnato il 24 ottobre
Gravità: CVSS 3.1 di 9.8, vettore
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HVersioni coinvolte: dal kernel 4.4 in poi
Riferimenti: CVE record · Debian Security Tracker
Perché è grave
Si sfrutta dalla rete, senza account. Basta un pacchetto SYN con opzioni IPv4 verso una porta TCP in ascolto: nessuna autenticazione e nessuna azione da parte di un utente.
Colpisce prima delle applicazioni. Il codice gira nel kernel mentre la connessione viene stabilita, prima che web server, mail server o SSH la vedano. Hardening applicativo e WAF non sono nel percorso del difetto.
È vecchio e diffuso. Il difetto è presente dal kernel 4.4, quindi in praticamente ogni sistema Linux in produzione.
Un server di hosting espone porte TCP per definizione. Web, posta e pannelli devono essere raggiungibili da internet.
La mitigazione parziale non basta. Disattivare
tcp_migrate_reqchiude solo il percorso secondario, non la race principale. L’unica soluzione completa è il kernel corretto, in esecuzione dopo il riavvio.
Il punteggio 9.8 è quello assegnato dal CNA del kernel. Il rischio concreto dipende dall’esposizione di ogni server, ma per chi ospita servizi pubblici la valutazione sul campo è che sia da trattare come urgente.
Il fix su Debian
Debian ha rilasciato i pacchetti corretti per le release supportate, mentre al 30 ottobre altre distribuzioni diffuse come Ubuntu e RHEL erano ancora in lavorazione.
Debian 13 (trixie): linux 6.12.113-1 (DSA-6568-1)
Debian 12 (bookworm): linux 6.1.190-1 (DLA-4841-1), oppure linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1)
Upstream: corretto in 6.1.190, 6.6.159, 6.12.113, 6.18.56, 5.15.223, 5.10.272 e nelle serie 7.x; per un caso IPv6 collegato è annunciata una patch separata
Come siamo intervenuti
Il metodo è quello di ogni aggiornamento di kernel: pacchetto corretto installato, riavvio pianificato nodo per nodo con backup o snapshot recente, verifica con uname -r che giri la versione nuova. Come di consueto le nostre procedure sono automatizzate usando profili ansible quindi con basso rischio d’errore.
php2shell: due RCE nel motore PHP
Il 21 ottobre 2026 sono state rese note due vulnerabilità di esecuzione di codice remoto, pre-autenticazione, nel motore PHP, con CVSS v4.0 di 9.2. Il nome php2shell viene dallo strumento d’attacco trapelato prima dell’embargo.
CVE-2026-109618: use-after-free nel gestore dell’upload progress di sessione. Si innesca con una richiesta POST multipart/form-data che contiene il campo
PHP_SESSION_UPLOAD_PROGRESS, anche senzasession_start(): il sito non deve nemmeno usare le sessioni.CVE-2026-109619: use-after-free nel backtrace dell’errore fatale e confusione di tipo in OPcache. Si innesca dopo un fatal error, per esempio un
memory_limitesaurito, che lascia stato corrotto nel worker.
Perché è grave
Esecuzione di codice senza autenticazione. Non servono un account, una password o un plugin vulnerabile: basta raggiungere un sito PHP.
Colpisce un decennio di versioni. Le versioni interessate partono da PHP 5.4.0, compresi i rami a fine vita che molti siti usano ancora e per cui upstream non rilascia fix.
Già in corso. Cloudflare ha riportato i primi attacchi il 21 ottobre alle 07:43 UTC, più di sei ore prima che php.net pubblicasse il fix (14:00 UTC).
Il fix e perché la distro da sola non bastava
php.net ha rilasciato le correzioni il 21 ottobre alle 14:00 UTC: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti non esiste un fix ufficiale.
Aspettare Debian avrebbe significato restare scoperti: poche ore dopo il rilascio il suo security tracker non riportava ancora nulla per i due CVE. I nostri server prendono PHP dal repository Sury, che la sera stessa ha pubblicato le build corrette, con backport anche per 5.6, 7.x, 8.0 e 8.1. La conferma viene dal changelog del manutentore, non da un test dell’exploit. Il 22 ottobre Sury ha ripubblicato 5.6, 7.0 e 7.1 con in più il backport di CVE-2023-0662, e abbiamo allineato di conseguenza i nodi già aggiornati.
Come siamo intervenuti
Partiamo da un dato: il 21 ottobre gli attacchi erano già in corso prima che esistesse un fix. Per questo abbiamo agito in due tempi, contenimento immediato e patch a ondate.
Contenimento, lo stesso giorno. Abbiamo disattivato session.upload_progress.enabled con un file dedicato nella conf.d di ciascuna SAPI. È un’impostazione PHP_INI_PERDIR, quindi uno script non può riattivarla con ini_set(). Copre solo CVE-2026-109618, perciò l’abbiamo trattata come un ponte e non come una soluzione.
Abbiamo scartato di proposito le mitigazioni che avrebbero rotto i servizi dei clienti: bloccare tutti i POST multipart (upload, REST API di WordPress, WooCommerce), bloccare i cookie di sessione (login e carrelli offline) o impostare memory_limit = -1 (rischio di esaurire la memoria). Passare da fcgid/CGI a PHP-FPM non è una mitigazione: il motore e i CVE sono gli stessi.
Patch in sicurezza. Per ogni nodo lo schema è lo stesso: simulazione in sola lettura, backup o snapshot, aggiornamento dei pacchetti PHP in background senza fermare i siti, riavvio graceful dei servizi, verifica che nessun processo giri ancora con il binario vecchio. Si parte da un nodo di prova e si procede per gruppi. Le verifiche finali (siti che rispondono, nessun errore nei log, servizi attivi) sono sempre risultate pulite.
Cosa puoi verificare sul tuo server
Se gestisci un server in proprio, questi controlli richiedono pochi minuti.
# kernel in esecuzione (cambia solo dopo il riavvio)
uname -r
# migrazione delle richieste TCP: deve restituire 0
sysctl net.ipv4.tcp_migrate_req
# chiave del repository PHP valida? (nessun output = ok)
apt-get update 2>&1 | grep EXPKEYSIG
# versioni PHP installate
dpkg -l | grep -E '^ii +php[0-9.]+-common'Le versioni PHP corrette sono 8.2.35, 8.3.36, 8.4.27 e 8.5.12 (o le build di backport del tuo repository per le serie più vecchie). Attenzione: php -v e php -i da riga di comando non dicono cosa vede il web. Per il servizio web controlla la SAPI giusta, per esempio php-fpm8.3 -v, e riavvia i servizi dopo l’aggiornamento.
Conclusione
Con una vulnerabilità critica contano due cose: la velocità e il modo in cui si interviene. Su php2shell abbiamo contenuto il rischio lo stesso giorno della pubblicazione e iniziato a patchare la sera stessa, quando Debian non aveva ancora un pacchetto. Lo abbiamo fatto con un metodo costruito per non toccare i servizi dei clienti: nodo di prova, backup prima, aggiornamento senza fermare i siti, verifica dopo ogni passo.
Se hai un server in gestione con noi, gli aggiornamenti di sicurezza sono sotto la nostra assistenza e supporto: se serve un tuo via libera o una finestra di riavvio, ti contattiamo. Se hai un server in proprio, un VPS o un sistema datato e vuoi un controllo, apri un ticket dall’area clienti oppure scrivici dal sito denali.pro.