Cos’è MPTCP e perché riguarda anche chi non lo usa

Multipath TCP (MPTCP) è lo standard RFC 8684. Estende il TCP classico per far viaggiare una singola connessione su più percorsi di rete insieme. Un telefono può usare WiFi e rete cellulare nello stesso momento, per la stessa connessione. Un server con più interfacce può fare lo stesso, per ridondanza o per somma di banda. Apple lo usa in produzione fin da iOS 7, nel 2013, per Siri: è il caso d’uso reale più noto. Alcuni operatori mobili, per esempio in Corea del Sud, lo sfruttano per il bonding WiFi/LTE. Diversi data center lo adottano per il multi-homing tra uplink diversi. Nel kernel Linux mainline c’è dal 5.6.

Il punto che mi ha fatto alzare un sopracciglio è un altro. Dalla versione 1.24, i programmi scritti in Go richiedono MPTCP di default per i socket in ascolto. Il Go Security Team l’ha confermato il 29 ottobre. Insieme, ha dato un avviso scomodo: il bug di cui parliamo oggi non è specifico di MPTCP. Un sistema senza listener MPTCP attivi può restare comunque esposto ad attacchi simili. Il codice vulnerabile è nel path TCP IPv4 generico, non in un modulo opzionale. Si può disattivare MPTCP programma per programma, con la variabile GODEBUG=multipathtcp=0 a runtime. Ma il Go Security Team definisce questa mitigazione “fragile”: basta un solo listener MPTCP rimasto esposto per vanificarla. Nessuno ha dimostrato che ogni exploit funzionante dipenda davvero da MPTCP. Ecco perché il codice MPTCP resta superficie di attacco, anche se nel tuo stack non lo attivi mai consapevolmente: basta che sia compilato nel kernel e raggiungibile.

Il progetto MPTCP stesso dichiara, sulla propria pagina, che le principali distribuzioni Linux correnti spediscono il kernel con il supporto MPTCP compilato di default (CONFIG_MPTCP=y). Nomina esplicitamente Debian, Ubuntu, RHEL e Fedora. È una dichiarazione del progetto stesso, non una verifica indipendente distro per distro, ma il concetto resta valido: il supporto è acceso a livello di kernel, non “opt-in” a livello di sistema operativo. Solo la negoziazione per singola connessione resta a carico dell’applicazione.

La vulnerabilità kernel Linux CVE-2026-98432 in breve

Il CVE team del kernel Linux ha pubblicato la CVE-2026-98432 il 15 ottobre 2026. Il fix upstream era già stato applicato dieci giorni prima, il 5 ottobre. Capita spesso che la pubblicazione segua il commit con un certo ritardo. Il punteggio CVSS di 9,8 (critico) è arrivato solo il 24 ottobre, nove giorni dopo la pubblicazione della CVE.

Il problema sta nella gestione dell’handshake TCP per IPv4, in particolare nella funzione tcp_v4_syn_recv_sock(). Quando una connessione viene creata, le opzioni IP del pacchetto SYN vengono passate dal request socket in attesa al nuovo socket. Per esempio Record Route o Timestamp, se il client le include in un SYN costruito ad arte. Il problema è che vengono passate per riferimento, non per copia, e senza il lock del listener. Secondo l’analisi tecnica della patch, le strutture coinvolte si chiamano inet_opt e ireq_opt. Una seconda CPU può liberare quel buffer con kfree(), chiamato da inet_sock_destruct() o da tcp_v4_reqsk_destructor(). Nel frattempo una prima CPU lo sta ancora leggendo in ip_options_build(), per costruire il SYNACK. È un classico use-after-free causato da una race condition. Il percorso IPv6 equivalente, tcp_v6_syn_recv_sock(), copia le opzioni invece di passarle per riferimento: non è vulnerabile alla race principale. Esiste anche una seconda via d’attacco, tramite la migrazione dei request-socket: net.ipv4.tcp_migrate_req=1 oppure un programma eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Entrambe sono disattivate di default.

Il bug è remoto e non richiede autenticazione né interazione dell’utente, secondo la valutazione del kernel team. È presente dalla versione 4.4 del kernel. Il fix è firmato da Eric Dumazet, segnalato da Xinyang Ge di Anthropic. Sposta la liberazione della memoria a dopo un grace period RCU, con kfree_rcu(): così nessuna CPU può più leggere un buffer già liberato. Le versioni stabili corrette sono 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e la mainline dalla 7.3-rc7.

Punteggi CVSS discordanti: non tutti i vendor sono d’accordo

Qui la storia si complica. Il kernel CVE team e Ubuntu valutano la complessità di attacco come bassa, e danno 9,8 (critico). Oracle e SUSE danno invece 8,1 (importante): stesso vettore CVSS, ma complessità di attacco alta. Red Hat, curiosamente, ha due valutazioni che non coincidono tra loro. La pagina CVE pubblica mostra “Moderate, 5.9”. Il file di advisory leggibile da macchina, aggiornato il 29 ottobre, mostra invece “Important, 8.1”, con impatto alto su confidenzialità e integrità. Lo stesso giorno il bug tracker interno di Red Hat ha alzato la severità da medium a high. Amazon, dal suo lato, assegna 7,0. Al momento in cui scrivo, l’NVD non ha ancora pubblicato un punteggio proprio.

Vale la pena dirlo con onestà. Questa incongruenza interna a Red Hat non è un dettaglio che ho dedotto io: è riportata così dall’articolo originale di The Hacker News, la mia fonte principale per questi dati. Non è la prima volta che un vendor pubblica due numeri diversi per lo stesso bug, su canali diversi. Ma qui il salto da “moderato” a “importante” nello stesso giorno dice molto. Anche per chi scrive il codice, stimare con certezza lo sfruttabilità reale di una race condition nel kernel è difficile.

Stato delle patch: Debian già corretto, altri ancora no

Questo è il punto che mi riguarda più da vicino: gli hosting che gestisco girano su Debian stable. E qui i fatti parlano chiaro, senza bisogno di aggiungere enfasi: Debian ha già corretto questa vulnerabilità kernel Linux, sia su trixie che su bookworm. Debian trixie (stable) è stata corretta il 16 ottobre 2026, con il pacchetto linux 6.12.113-1, avviso DSA-6568-1. Debian 12 (bookworm) è stata corretta in due passaggi: il 17 e il 22 ottobre 2026, con linux 6.1.190-1 (avviso DLA-4841-1) e linux-6.12 6.12.113-1~deb12u1 (avviso DLA-4850-1). Nella propria tabella di tracciamento, Debian non elenca un punteggio CVSS separato per questa CVE. Si limita a segnare lo stato di fix per ogni release: è l’informazione che conta davvero, per chi deve decidere se riavviare un server.

Confrontare questo con lo stato di altre distribuzioni molto diffuse aiuta a dare peso alla cosa. Al 30 ottobre, Red Hat ha aggiornato lo stato di RHEL 8, 9, 10 e OpenShift 4. Prima era “fix deferred” (segnato il 29 ottobre), ora è “affected”. Nessuna data di rilascio è stata comunicata. Ubuntu, su tutte le versioni supportate (22.04, 24.04, 26.04, 26.10), risulta ancora “in lavorazione”, senza una data. Ubuntu 16.04, 18.04 e 20.04 risultano vulnerabili, senza nemmeno un fix elencato. SUSE Linux Enterprise Server, dalla SP4 alla SP7 più la 16.0, è nella stessa situazione. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 e Amazon Linux 2023 risultano invece già corretti. RHEL 7 non è affetto: il percorso di codice vulnerabile non è mai stato distribuito su quella release.

Non lo dico per fare concorrenza a Ubuntu o RHEL. Restano distribuzioni serie, con processi di sicurezza robusti. Lo dico perché su questo singolo bug, in questa finestra temporale, i fatti sono questi: chi si affida a hosting basati su Debian stable ha già il fix installato. Su altre distribuzioni molto usate, invece, il server resta esposto per un periodo indefinito. È un vantaggio concreto, verificabile guardando le date. Non è un’opinione sul progetto Debian in generale.

L’exploit (riportato, non verificato in modo indipendente) di Anthropic

La parte più insolita di questa storia riguarda Anthropic, l’azienda che per prima ha segnalato il bug tramite Xinyang Ge. Secondo i report di settore, uno dei suoi modelli AI interni, non rilasciato pubblicamente, ha costruito da solo un exploit root funzionante. Partendo solo dalla patch e dal report come prompt. L’attacco in due fasi funzionerebbe così. Nella prima fase, la race fa inviare all’attaccante byte extra dalla risposta del kernel. Da lì recupera un indirizzo kernel, per disinnescare KASLR. Nella seconda fase, lo stesso bug causerebbe un overflow di buffer. Sovrascrive un puntatore di callback con l’indirizzo di un payload già piazzato in memoria kernel dall’attaccante. Quando il kernel chiama quel puntatore, il payload esegue un comando shell a scelta come root. Una race persa farebbe fallire solo quel singolo tentativo di connessione, senza crashare il sistema: quindi sarebbero possibili tentativi ripetuti. Nel test descritto da Anthropic: 48 minuti per rubare l’indirizzo kernel, altri 5 minuti per arrivare all’esecuzione di comandi.

Red Hat dice che un attaccante remoto che raggiunge un servizio TCP esposto può in generale innescare la race. L’exploit root descritto da Anthropic, però, avrebbe preso di mira specificamente server con un listener multipath TCP attivo. Il post di Anthropic non chiarisce se un server senza MPTCP sia sfruttabile allo stesso modo. Né il record CVE né il fix upstream menzionano MPTCP in nessun punto. È la stampa di settore, non una fonte primaria, a riportare questo legame: lo scrivo quindi con lo scetticismo che merita, non come un fatto accertato al cento per cento. Anthropic non ha pubblicato il codice dell’exploit, né la versione esatta del kernel usata, né la configurazione del server target. Un’altra società, Innora, ha pubblicato un’analisi della causa radice, con un ambiente di riproduzione QEMU. Ha dichiarato che non rilascerà un exploit armato nel breve termine. Al momento non ci sono prove di sfruttamento reale da parte di vendor o CERT. Il bug non è nel catalogo CISA KEV, secondo la copia aggiornata da CIRCL del Lussemburgo al 28 ottobre.

Cosa fare adesso sui tuoi server

Nessun vendor ha pubblicato un workaround ufficialmente sanzionato per questa vulnerabilità kernel Linux. Red Hat dice esplicitamente che nessuna delle misure circolate finora raggiunge il suo standard di facilità di deploy e di stabilità. La mitigazione primaria resta applicare il kernel corretto e riavviare, quando la patch è disponibile per la tua distribuzione. Su Debian lo è già. Su RHEL e Ubuntu ancora no, al momento in cui scrivo.

Come difesa in profondità, non come soluzione definitiva, ha senso fare alcune cose. Verificare che net.ipv4.tcp_migrate_req sia impostato a 0. Controllare che non ci siano programmi eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE caricati. Valutare un filtraggio dei pacchetti IPv4 in ingresso con opzioni Record Route o Timestamp. Monitorare eventuali crash che citano ip_options_build, ip_build_and_send_pkt o skb_under_panic. Fare l’inventario di eventuali listener MPTCP esposti, evitando di lasciarli raggiungibili senza motivo. Se gestisci anche servizi contro attacchi applicativi più comuni, su come ho protetto i server in attesa della patch per PHP2Shell trovi lo stesso approccio: mitigare quello che si può, mentre si aspetta il fix definitivo, senza promettere protezioni che non esistono.

Per chi mi chiede se aggiornare subito: se usi Debian stable, il kernel corretto è già nei repository di sicurezza. L’aggiornamento è semplice, e la finestra di esposizione è già chiusa. Se usi altre distribuzioni, oggi non c’è ancora una patch da installare. Vale la pena seguire da vicino gli avvisi del tuo vendor nei prossimi giorni: la situazione cambia rapidamente.

Fonti: The Hacker News, Debian Security Tracker e il commit del fix. Debian, Red Hat, Ubuntu e gli altri nomi citati sono marchi dei rispettivi proprietari.

The post Vulnerabilità kernel Linux: un use-after-free nel TCP IPv4 first appeared on Matteo Cisilino.

In questo articolo spiego cosa sono e quali versioni di PHP sono coinvolte. Racconto come ho messo in sicurezza i server che gestisco mentre la patch non c’era, e come sono arrivato all’aggiornamento definitivo. Trovi anche lo script che ho usato e i comandi per lanciarlo.

Cos’è PHP2Shell

Il problema sta nel modo in cui PHP legge le richieste di tipo multipart/form-data. È il formato che il browser usa per inviare i file. PHP lo interpreta prima che parta qualsiasi script.

Per questo non serve un modulo di upload. Può bastare una sola richiesta a un qualsiasi file PHP del sito.

Le due falle, in sintesi:

• CVE-2026-109618. Se la memoria si esaurisce mentre PHP legge la richiesta, alcuni dati si corrompono. La corruzione emerge nella pulizia finale della richiesta e può portare a eseguire codice.
• CVE-2026-109619. Parte dello stato di una richiesta resta in memoria. Una richiesta successiva, sullo stesso processo, lo riusa.

Questi dettagli tecnici vengono dall’analisi del NCSC olandese e da altre fonti pubbliche. Non ho provato a sfruttare le falle sui miei server.

Quali versioni di PHP sono coinvolte

Le versioni corrette sono uscite il 21 ottobre 2026: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Ogni versione precedente a queste è colpita.

I rami 8.1 e più vecchi non hanno una versione corretta ufficiale, perché sono fuori supporto. PHP ha pubblicato solo dei backport minimi del codice sorgente per 7.4, 8.0 e 8.1. Per rami ancora più vecchi non risulta nulla.

Il rischio riguarda ogni modo di eseguire PHP. Il più esposto è mod_php. Contano anche PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. Riguarda poi ogni applicazione che gira sopra: WordPress, Joomla, Drupal, Nextcloud, phpMyAdmin, Roundcube e il pannello ISPConfig.

Su Debian c’è un dettaglio da conoscere. Debian applica le correzioni come backport e non cambia il numero di versione di PHP. Un server può mostrare un numero basso ed essere già corretto. Per questo lo script non confronta le versioni. Controlla se il changelog del pacchetto installato cita le due CVE.

La mitigazione, in attesa della patch

Quando le falle sono diventate pubbliche, le patch non erano ancora disponibili per le distribuzioni. Non volevo lasciare i server scoperti, quindi ho ridotto il rischio con uno script.

La mitigazione non è una patch. Disattivare session.upload_progress chiude solo uno dei percorsi noti della CVE-2026-109619 e non fa nulla contro la CVE-2026-109618. Serviva a restringere il margine di attacco fino all’aggiornamento, non a sostituirlo.

Cosa fa lo script

Lo script è pensato per Debian 12 e 13. Funziona con Apache (mod_php, FastCGI, suPHP, PHP-FPM) e con Nginx (PHP-FPM). Riconosce i server gestiti con ISPConfig, sia Apache sia Nginx.

Le opzioni:

• Senza opzioni controlla e basta. Per ogni pacchetto PHP verifica che il changelog citi le due CVE. Segnala i processi che usano ancora un binario vecchio, legge le impostazioni attive e le porte web in ascolto.
• --update aggiorna prima l’indice dei pacchetti.
• --logs cerca indicatori sospetti: file PHP recenti nelle cartelle di upload o cache, pattern tipici delle webshell, riferimenti a php2shell nei log. È un’euristica e non prova una compromissione.
• --harden applica la messa in sicurezza descritta qui sotto.
• --dry-run, insieme a --harden, mostra cosa farebbe senza modificare nulla.
• --skip-disable-functions, insieme a --harden, non tocca disable_functions.
• --rollback toglie quanto applicato da --harden.

Cosa cambia con –harden

Per ogni versione di PHP presente in /etc/php, lo script crea il file mods-available/cve-hardening.ini. Lo abilita con phpenmod per i SAPI fpm, apache2 e cgi. Così la protezione vale per tutti i siti in una volta.

I php.ini originali restano intatti. La CLI non viene toccata, quindi composer, artisan e wp-cli continuano a funzionare.

Il file imposta tre cose:

• session.upload_progress.enabled = Off
• expose_php = Off
• disable_functions con exec, passthru, shell_exec, system, proc_open, popen e pcntl_exec, aggiunte a quelle già presenti.

Poi lo script testa la configurazione e ricarica PHP-FPM e Apache solo se il test passa. Prima di scrivere fa un backup in /var/backups/php-cve-hardening/.

I limiti da conoscere

• disable_functions può rompere alcune applicazioni, per esempio WordPress con certi plugin o Magento. Se succede, usa --rollback oppure rilancia con --skip-disable-functions.
• Le direttive php_admin_value nei pool PHP-FPM hanno la precedenza sul file globale. Lo script le segnala ma non le modifica.
• Con ISPConfig i file in pool.d sono rigenerati dal pannello. Gli override vanno corretti dal pannello, in Sites, Website, Options, Custom php.ini settings, non a mano.
• I php.ini per singolo sito (modalità FastCGI o suPHP di ISPConfig) e le versioni PHP in /opt non sono gestiti. Vanno controllati a parte.

Come lanciare lo script

Lo script è qui: https://cisilino.com/mscripts/php20261.sh

Prima di eseguire qualsiasi cosa da internet, leggila. Puoi scaricarlo e aprirlo:

wget -qO php20261.sh https://cisilino.com/mscripts/php20261.sh
less php20261.sh

Se vuoi lanciarlo direttamente da remoto, servono i privilegi di root. Questi sono i comandi, nell’ordine che consiglio.

1. Solo controllo, con aggiornamento dell’indice dei pacchetti:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --update

2. Simulazione della messa in sicurezza, senza modifiche:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --harden --dry-run

3. Applicazione:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --harden

4. Rimozione, se qualcosa si rompe:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --rollback

Dopo --harden e dopo --rollback non serve riavviare nulla a mano: lo script ricarica da solo PHP-FPM e Apache, dopo aver testato la configurazione. Il riavvio serve invece dopo l’aggiornamento del pacchetto PHP, perché i processi in esecuzione tengono in memoria il binario vecchio:

sudo systemctl restart 'php*-fpm' apache2

Gli apici attorno a php*-fpm servono. Senza, è la shell a espandere l’asterisco, non systemctl. Se il server usa solo Nginx, togli apache2.

L’esito dello script è anche un codice di uscita: 0 se è tutto a posto, 1 se ci sono avvisi, 2 se il sistema è vulnerabile o serve un’azione.

Sui server con ISPConfig: ispconfig-multipart-guard

Chi usa ISPConfig ha un’arma in più. Il progetto ha rilasciato lo script ispconfig-multipart-guard, descritto nell’avviso ufficiale di ISPConfig.

Il principio è semplice. Se il problema è nelle richieste multipart, il web server le ferma prima che arrivino a PHP:

• blocca le richieste Content-Type: multipart/... per tutti i siti, per alcuni siti scelti o per il pannello di controllo;
• con Nginx risponde 415 alle richieste PHP dei siti bloccati e i file statici non cambiano. Con Apache risponde 403, anche per i file statici;
• di default blocca solo il pannello ISPConfig. I siti vanno bloccati con comandi come block all o block esempio.it;
• crea un cron che ogni 5 minuti ripristina i suoi hook, se ISPConfig riscrive la configurazione;
• ha una lista di IP autorizzati che possono ancora caricare file.

Funziona con Debian e Ubuntu, con ISPConfig 3.2 o 3.3 (e anche senza ISPConfig), con Nginx o con Apache 2.4 e successivi.

Il prezzo è che sui siti bloccati gli upload non funzionano. Valgono anche i media dei CMS, gli allegati dei moduli e quelli del webmail, e gli import di phpMyAdmin. Le pagine normali e i moduli urlencoded continuano a funzionare. Anche questa è una misura provvisoria e non una correzione.

Questo script e il mio non sono alternativi. Il mio agisce sulla configurazione di PHP, quello di ISPConfig sul web server. Non li ho confrontati sul campo e non posso dirti come si comportano insieme su ogni configurazione.

L’aggiornamento definitivo, in due passaggi

Le mitigazioni dovevano durare poco. Ho aggiornato i server non appena gli aggiornamenti sono stati disponibili, in due passaggi:

1. Compilazione diretta. In attesa che la distribuzione in uso sul singolo server rilasciasse il suo pacchetto, ho compilato PHP dai sorgenti nelle versioni corrette.
2. Pacchetto ufficiale. Quando il pacchetto ufficiale della distribuzione è stato rilasciato per quel server, ho sostituito la compilazione con il pacchetto.

Il secondo passaggio conta. Un PHP compilato a mano non si aggiorna da solo con il resto del sistema. Il pacchetto della distribuzione sì, e lo script può verificarlo leggendo il changelog.

Cosa fare adesso

1. Aggiorna PHP alla 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Su Debian puoi anche usare il pacchetto della distribuzione quando il changelog cita le due CVE.
2. Riavvia PHP-FPM e Apache, poi rilancia lo script senza opzioni. Non deve più segnalare problemi.
3. Se usi PHP 8.1 o precedente, pianifica il passaggio a un ramo supportato. Per quei rami non c’è una versione ufficiale corretta.
4. Tieni disattivato session.upload_progress fino al prossimo rilascio di correzioni, se la tua applicazione non lo usa.
5. Controlla i log e i file recenti, con --logs o a mano, cercando file PHP comparsi nelle cartelle di upload.
6. Non dimenticare PHP dentro container, immagini e appliance di terzi. Vanno aggiornati a parte.
7. Se il tuo sito usa WordPress, il plugin Cisilino Site Defense Network non risolve PHP2Shell. Protegge però il login e tiene un registro delle attività, utile per capire cosa succede sul sito.

Fonti

• ISPConfig: PHP2Shell, vulnerabilità critiche di PHP (CVE-2026-109618, CVE-2026-109619)
• NCSC-NL: wiki su PHP2Shell

ISPConfig, PHP, Debian e gli altri nomi citati sono marchi dei rispettivi proprietari. Sono indicati solo per identificare i prodotti.

The post PHP2Shell: come ho protetto i server in attesa della patch first appeared on Matteo Cisilino.