CVE-2026-104269: bypass del WAF ModSecurity, come verificare e aggiornare alla 3.0.17

Se usi ModSecurity come web application firewall davanti a un'applicazione scritta in Go, Python, Node.js o Java che accetta upload di file, la vulnerabilità CVE-2026-104269 ti riguarda. Il parser multipart di ModSecurity, dalla versione 3.0.0 fino alla 3.0.16, legge il nome del file dal parametro filename e ignora filename*, mentre il backend fa il contrario. Un attaccante può così far controllare al WAF un nome innocuo e far salvare all'applicazione un nome diverso. La correzione è nella versione 3.0.17.

Cosa è successo: la vulnerabilità CVE-2026-104269 in ModSecurity

ModSecurity è un motore WAF open source per Apache, IIS e Nginx. Quando un browser invia un modulo con allegato, la parte del corpo della richiesta che contiene il file ha un header Content-Disposition. Lo standard RFC 2231 prevede che, se nell'header compaiono sia filename sia filename* (la variante codificata, con charset), il secondo abbia la precedenza. I parser multipart più diffusi in Go, Python, Node.js e Java seguono questa regola. ModSecurity, fino alla 3.0.16, no: usa solo filename.

Il risultato è che le regole basate sulla variabile MULTIPART_FILENAME prendono una decisione su un nome, e l'applicazione dietro al WAF prende la sua decisione su un altro nome. Il parser multipart nativo di PHP non è interessato da questa discrepanza.

Chi è colpito: versioni vulnerabili di ModSecurity

• ModSecurity (libmodsecurity) dalla 3.0.0 alla 3.0.16 inclusa, come indicato nella descrizione ufficiale.
• Versione corretta: 3.0.17.

Tra i riferimenti pubblicati compare anche la release 2.9.15 del ramo 2.x, con un commit sullo stesso tema nel modulo Apache. Se usi ModSecurity 2.x con Apache, non dare per scontato di essere al sicuro: verifica sull'advisory ufficiale se e quali versioni del ramo 2.x sono coinvolte.

La vulnerabilità ha effetto concreto solo in questa combinazione: ModSecurity in una versione vulnerabile, regole che filtrano gli upload sul nome o sull'estensione del file, e un backend che preferisce filename*. Con un backend PHP che usa il parser nativo il problema non si presenta.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il punteggio CVSS 3.1 è 8.6, gravità alta. Il vettore è AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N: attacco via rete, bassa complessità, nessun privilegio e nessuna interazione dell'utente. Lo scope è cambiato perché la falla sta nel WAF ma il danno si produce nell'applicazione protetta. L'impatto è sull'integrità, alto; non su riservatezza o disponibilità.

Al momento la vulnerabilità non risulta nel catalogo CISA KEV, quindi non c'è evidenza pubblica di sfruttamento attivo. Cosa ottiene un attaccante: un bypass del WAF sul nome del file caricato. Non è di per sé un'esecuzione di codice remoto. Diventa pericolosa quando l'applicazione usa il nome scelto dal backend per salvare il file, per controllare l'estensione o per dedurre il content-type: in quel caso un file con estensione vietata può passare l'ispezione. Ho già descritto a cosa porta un upload non controllato nell'articolo sulla falla di upload file in BuddyBoss App.

Come capire se sei esposto: verifica versione, esposizione e log

Verifica della versione di ModSecurity

• Su Debian e Ubuntu: dpkg -l | grep -i modsecurity. Su RHEL, Rocky e AlmaLinux: rpm -qa | grep -i modsecurity.
• Se la libreria è compilata dai sorgenti: pkg-config --modversion modsecurity, oppure controlla il nome del file in /usr/local/modsecurity/lib/ (ad esempio libmodsecurity.so.3.0.x).
• Con Nginx controlla che il connettore sia presente: nginx -V 2>&1 | grep -i modsecurity. Con Apache: apachectl -M | grep -i security.
• Dentro container o immagini pronte (reverse proxy con WAF integrato, distribuzioni di Core Rule Set) leggi il changelog dell'immagine: spesso la versione di libmodsecurity non è visibile dall'esterno.

Verifica dell'esposizione

• Elenca gli endpoint che accettano upload multipart raggiungibili da internet: moduli di contatto con allegato, aree clienti, API di caricamento documenti.
• Per ciascuno annota il linguaggio del backend. Go, Python, Node.js e Java sono quelli citati nell'advisory; PHP con parser nativo no.
• Controlla se le tue regole (comprese quelle del Core Rule Set) decidono qualcosa in base a MULTIPART_FILENAME. Se sì, quel controllo è aggirabile.

Log e indicatori

• Nell'audit log di ModSecurity (di solito /var/log/modsec_audit.log) cerca richieste multipart con header Content-Disposition che contengono filename*=. È un parametro legittimo ma raro nei form comuni; la presenza di filename e filename* con valori diversi è un segnale da guardare.
• Confronta i nomi dei file effettivamente salvati dall'applicazione con quelli registrati dal WAF. Discrepanze di estensione sono l'indicatore più diretto.
• Controlla nelle cartelle di upload la presenza di file con estensioni eseguibili o doppie estensioni, e le date di creazione.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

La patch è disponibile: aggiorna ModSecurity alla 3.0.17. Le modifiche sono nei commit indicati nelle fonti e cambiano il parser in multipart.cc perché filename* venga letto e, se presente, sostituisca filename nella variabile MULTIPART_FILENAME. Dopo l'aggiornamento il WAF valuta lo stesso nome che vedrà il backend.

1. Scarica la 3.0.17 dalla pagina release su GitHub o aspetta il pacchetto della tua distribuzione, verificando che includa il fix.
2. Se compili dai sorgenti, ricompila anche il connettore (Nginx o Apache) contro la nuova libreria.
3. Riavvia il web server e verifica la versione con i comandi della sezione precedente.
4. Prova un upload di test con filename* impostato: il nome visto nel log del WAF deve coincidere con quello ricevuto dall'applicazione.

Per il ramo 2.x esiste la release 2.9.15 con un commit analogo: se la usi, verifica sull'advisory se il tuo caso è coperto e aggiorna di conseguenza.

Cosa fare subito: mitigazioni e hardening

1. Non affidarti al solo WAF per gli upload. L'applicazione deve validare da sola estensione, dimensione e tipo reale del file (magic bytes), e rinominare i file salvati con un nome generato dal server.
2. Blocca l'esecuzione nelle cartelle di upload: nessun handler per script, nessun permesso di esecuzione, possibilmente storage separato dal document root.
3. Regola temporanea nel WAF: finché non aggiorni, puoi valutare una regola che ispezioni l'header Content-Disposition grezzo e segnali o blocchi le richieste che contengono filename* insieme a filename. Testala in modalità di solo rilevamento prima di metterla in blocco, perché alcuni client legittimi usano filename*.
4. Segmenta: il server che riceve gli upload non deve avere accesso diretto a database e condivisioni interne oltre lo stretto necessario.
5. Monitora le cartelle di upload con controlli di integrità e tieni gli audit log del WAF per un periodo sufficiente.

Se sospetti una compromissione: incident response e analisi forense

Se trovi file sospetti nelle cartelle di upload o richieste anomale nei log, non spegnere la macchina e non cancellare nulla. Isola il server dalla rete, conserva memoria e log, e fai una copia forense del disco prima di intervenire. Solo dopo si ricostruisce cosa è entrato, quando e cosa ha fatto. Se sono coinvolti dati personali, valuta la notifica al Garante entro i termini del GDPR. Le prime ore contano: ho raccolto i passaggi essenziali nell'articolo su cosa fare nelle prime 24 ore in caso di malware in azienda. Per un intervento di incident response il mio listino va da 1.500 a 6.000 €, con preventivo a prezzo fisso.

Fonti ufficiali

• Advisory GHSA-5pww-8rfg-9crf su GitHub
• Release ModSecurity v3.0.17
• Release ModSecurity v2.9.15
• Commit di correzione per il ramo 3.x
• Commit di correzione per il ramo 2.x

Se non sai quale versione di ModSecurity gira davanti ai tuoi server, o vuoi un controllo indipendente su come la tua applicazione gestisce gli upload, scrivimi dalla pagina contatti oppure chiedi un preventivo gratuito: rispondo entro 24 ore.