HTTP2Shell e WordPress: come verificare se il tuo sito è esposto alla falla Brotli

Nel giro di pochi giorni la stessa vulnerabilità ha cambiato nome tre volte: Node2Shell, Python2Shell e infine HTTP2Shell. Il nome inganna, perché il difetto sta nel decoder Brotli e non nel protocollo HTTP/2. Il suo identificativo è CVE-2026-111497, ed è una scrittura fuori dai limiti del buffer nel decoder di Google, versioni dalla 1.0.3 alla 1.2.0.

Se gestisci siti WordPress, la domanda è una sola: mi riguarda? La risposta onesta è “dipende dal tuo stack”, e qui sotto trovi i comandi per scoprirlo in pochi minuti.

Cos’è Brotli e perché fa paura questa falla

Brotli è un algoritmo di compressione di Google, usato ovunque per ridurre il peso di pagine e risorse. Il bug scatta quando un software decomprime dati Brotli costruiti ad arte. Secondo Tanium, un attaccante remoto non autenticato può far crashare il processo, leggere memoria o potenzialmente eseguire codice. Il punteggio è alto: 9.2 su CVSS 4.0.

Il meccanismo, in breve: uno stream Brotli malformato contiene un block switch non valido, e il decoder lo interpreta come una semplice richiesta di altro input invece che come un errore definitivo.

WordPress è davvero a rischio?

Qui serve cautela. Le analisi che ho letto dicono che nelle advisory esaminate non risulta alcuna vulnerabilità confermata nel core di WordPress o di PHP. Il rischio indiretto però esiste, ed è questo:

• un’estensione PHP che include codice Brotli vulnerabile andrebbe verificata;
• un’applicazione PHP che usa libcurl potrebbe arrivare a un decoder Brotli di sistema vulnerabile, se il client HTTP decomprime risposte Brotli non fidate.

Quindi il core non è il problema, ma il server su cui gira sì, potenzialmente. Se hai anche un frontend Node.js, un Next.js headless, script Python o microservizi accanto a WordPress, quella è la parte più esposta. Per Next.js, per esempio, l’ottimizzazione immagini non esclude le risposte Brotli.

Sul fronte sfruttamento le fonti non sono allineate. WinFuture riporta che la CISA avverte di un uso attivo della falla e che i ricercatori hanno registrato i primi tentativi di attacco, mentre Tanium, al 24 ottobre, scriveva che la falla non era nel catalogo KEV della CISA e non c’erano indicatori di compromissione pubblici. La situazione è evoluta, quindi tratta il tutto come urgente senza farti prendere dal panico.

Passo 1: scopri cosa gira sul tuo server

Collegati in SSH e parti dal sistema operativo.

# Versione del binario brotli (se installato)
brotli --version

# Pacchetti Brotli su Debian/Ubuntu
dpkg -l | grep -i brotli

# Pacchetti Brotli su RHEL/AlmaLinux/Rocky
rpm -qa | grep -i brotli

# Librerie condivise presenti
ldconfig -p | grep -i brotli

Poi controlla se curl, che PHP usa spesso per le chiamate HTTP, è compilato con Brotli:

curl -V | grep -i brotli

Se compare brotli/x.x.x nell’elenco delle librerie, curl può decodificare Brotli.

Passo 2: PHP e la sua estensione Brotli

L’estensione PECL esiste ed era vulnerabile. Controlla se l’hai installata:

php -m | grep -i brotli
php --ri brotli
pecl list | grep -i brotli

Se risulta presente, la versione sicura è la 0.21.1, che include Brotli 1.2.1. Per aggiornare:

sudo pecl upgrade brotli
sudo systemctl restart php8.3-fpm   # adatta al tuo servizio

Se non compare nulla, l’estensione non c’è e puoi passare oltre.

Passo 3: Node.js, Python e compagnia

Se sullo stesso server (o nello stesso stack) c’è altro oltre a PHP:

# Node.js: versione e versione di Brotli inclusa
node -v
node -p "process.versions.brotli"

# Python
pip show brotli brotlicffi
pip list 2>/dev/null | grep -i brotli

Le versioni corrette sono queste: Node.js 22.23.4, 24.22.1 e 26.12.1; Python Brotli 1.2.1 e brotlicffi 1.2.1.0. Per Bun serve la 1.4.4.

Per aggiornare in Python:

pip install --upgrade "brotli>=1.2.1" "brotlicffi>=1.2.1.0"
pip install pip-audit && pip-audit

Se non ti serve Brotli, la strada più pulita è toglierlo: disinstalla i pacchetti Brotli e brotlicffi e rimuovi dipendenze opzionali come httpx[brotli]. Attenzione però, perché il fallback a gzip/deflate non è garantito se un server invia comunque Brotli.

Passo 4: chi sta usando davvero la libreria?

Avere il pacchetto installato non significa essere vulnerabili. Quello che conta è cosa è caricato in memoria dai processi in esecuzione:

sudo lsof 2>/dev/null | grep -i libbrotli | awk '{print $1}' | sort -u

Ti restituisce i nomi dei processi che hanno la libreria aperta. Se compaiono php-fpm, node o altri servizi esposti, quelli sono i candidati da aggiornare e riavviare per primi.

Sulle distribuzioni Debian c’è un’altra cosa da sapere. Al 23 ottobre, uno strumento di audit riportava che Debian 12 e 13 risultavano affette, senza una versione corretta del pacchetto ancora registrata. Controlla se nel frattempo è arrivato l’aggiornamento:

sudo apt update
apt-cache policy libbrotli1
sudo apt upgrade
sudo needrestart -r a   # riavvia i servizi che usano librerie aggiornate

Passo 5: cerca Brotli dentro i plugin

Alcuni plugin o librerie PHP includono una propria copia del decoder, che l’aggiornamento di sistema non toccherà mai. Da WP-CLI o dalla shell:

Leggi anche: Cosa fare se un aggiornamento di WordPress rompe il sito: guida alla diagnostica

cd /var/www/html   # radice del tuo WordPress

wp core version
wp plugin list --status=active

# Cerca riferimenti a Brotli nel codice di plugin e temi
grep -rIl --include="*.php" -i "brotli" wp-content/plugins wp-content/themes | head -50

# Cerca client HTTP che abilitano la decompressione automatica
grep -rIl --include="*.php" "CURLOPT_ACCEPT_ENCODING" wp-content | head -50

Non tutto quello che esce è un problema (molti plugin di cache citano Brotli solo per comprimere), ma ti dà una lista breve da guardare a mano. Il tema vale anche per Docker: una copia vulnerabile può nascondersi dentro un’immagine, quindi ricostruisci le immagini dopo aver aggiornato i pacchetti base.

Leggi anche: Plugin WordPress vulnerabili o abbandonati: come riconoscerli ed eliminarli prima che bucano il sito

Passo 6: mitigazione temporanea sul web server

Se non puoi aggiornare subito, una delle indicazioni circolate è di bloccare a livello di proxy o middleware le richieste con codifica Brotli e impedire ai client di decodificare risposte Brotli non fidate, verificando di non rompere il traffico legittimo.

Su Nginx, per le richieste in ingresso:

# dentro il blocco server { }
if ($http_content_encoding ~* "\bbr\b") {
    return 415;
}

sudo nginx -t && sudo systemctl reload nginx

Un chiarimento: moduli come ngx_brotli o mod_brotli di Apache servono soprattutto a comprimere le risposte verso i visitatori. Non sono il vettore principale di questa falla, ma controllare non costa nulla:

nginx -V 2>&1 | grep -i brotli
apachectl -M 2>/dev/null | grep -i brotli

È una toppa, non una soluzione. Vale giusto per guadagnare tempo.

Checklist veloce

Se hai un classico WordPress su PHP senza estensione Brotli, probabilmente stai già meglio di molti altri. Ma “probabilmente” non basta quando la falla è in una libreria che si annida in posti inattesi. Dieci minuti di verifica oggi valgono più di una notte a ripulire un server compromesso.

Leggi anche: PHP2Shell: come limitare i danni di una falla PHP con disable_functions e blocco dei file in uploads

Fonte: Wordfence, HTTP2Shell e Brotli per WordPress