HTTP2Shell: la vulnerabilità di Brotli che colpisce anche WordPress

A due settimane da PHP2Shell, un altro bug “2Shell” preoccupa chi gestisce siti WordPress. Si chiama HTTP2Shell (anche Node2Shell o Brotli2Shell), è tracciato come CVE-2026-111497 con punteggio CVSS v4.0 9.2 e non sta né in WordPress né in PHP: sta in Brotli, la libreria di compressione di Google che mezzo stack web usa per decodificare le risposte HTTP compresse.

Il 2 novembre 2026 Alex Thomas del team Threat Intelligence di Wordfence ha pubblicato un’analisi di cosa significa per WordPress: in un laboratorio isolato ha ottenuto l’esecuzione di codice senza autenticazione su un sito WordPress sfruttando i pingback XML-RPC, su un server con PHP 8.3.36, cioè la release che corregge già PHP2Shell.

⛔ Aggiornare PHP non basta

La falla è nella libreria Brotli di sistema, non in PHP o in WordPress. Un WordPress aggiornato su un PHP corretto può essere comunque esposto se il server carica una libbrotli vulnerabile. La correzione è aggiornare Brotli e riavviare i processi che la usano.

In sintesi


Nome	HTTP2Shell, anche Node2Shell / Brotli2Shell (HTTP/2 non c’entra)
CVE	CVE-2026-111497 (pubblicata da Google)
Gravità	CVSS v4.0 9.2
Tipo	Scrittura fuori dai limiti nel decoder Brotli: crash, fuga di memoria o RCE
Versioni vulnerabili	Brotli 1.0.3 – 1.0.9, 1.1.0, 1.2.0
Versioni corrette	Brotli 1.0.10, 1.1.1, 1.2.1 (e backport delle distribuzioni)
Percorso in WordPress	`pingback.ping` non autenticato via `xmlrpc.php`, riprodotto in laboratorio da Wordfence
Sfruttamento	Nel catalogo CISA KEV dal 27 ottobre 2026; scansioni e tentativi osservati, nessuna compromissione in produzione via WordPress documentata in modo verificabile

Qual è il bug

Brotli è un formato di compressione usato da browser e server come alternativa a gzip (Content-Encoding: br). Il bug è in DecodeBlockTypeAndLength() nel decoder C: un valore di ritorno non viene controllato (CWE-252), quindi il decoder non distingue “dati malformati” da “servono altri dati” e finisce per scrivere fuori dai limiti del buffer (CWE-787). Un flusso compresso costruito ad arte può corrompere la memoria del processo che lo decodifica.

Secondo Upwind, il bug è stato segnalato da OpenAI a febbraio 2026 e corretto nel codice già allora, ma nessuna release ha incluso la correzione fino a ottobre. È emerso il 21 ottobre come bug di Node.js (da qui “Node2Shell”) e si è capito presto che il problema sta nella libreria C condivisa: sono coinvolti Node.js, i pacchetti Python (Brotli, brotlicffi), Bun, Envoy e ogni programma collegato a una libbrotli vulnerabile, curl compreso.

Cosa c’entra WordPress

WordPress non decomprime Brotli da solo. Però fa richieste HTTP in uscita, e il client HTTP sottostante (sulla maggior parte dei server l’estensione curl di PHP, cioè libcurl) può passare una risposta compressa br al decoder Brotli di sistema. Se un attaccante riesce a far scaricare a WordPress un URL che controlla, può servire una risposta compressa malevola e raggiungere il codice vulnerabile dall’interno del worker PHP.

Nel WordPress standard, Wordfence ha trovato un solo percorso chiaro senza autenticazione: i pingback. Quando qualcuno chiama pingback.ping su xmlrpc.php, WordPress scarica la pagina sorgente per verificare che contenga davvero un link al tuo articolo. Quell’URL sorgente lo sceglie l’attaccante.

Perché l’attacco funzioni devono essere vere tutte queste condizioni:

xmlrpc.php è raggiungibile;
il metodo pingback.ping è registrato;
l’articolo bersaglio accetta i ping;
il server può fare richieste in uscita;
il client HTTP usa il decoder Brotli vulnerabile;
il payload corrisponde alla build di PHP e alla disposizione della memoria del server.

Le altre funzioni del core che scaricano URL richiedono autenticazione, permessi aggiuntivi o controllo sui contenuti. Plugin e temi possono però aggiungere nuovi percorsi: qualunque funzione che scarica un URL fornito da un visitatore è un candidato.

⚠ 'Disable XML-RPC authentication' non blocca i pingback

Wordfence sottolinea che la sua opzione Disable XML-RPC authentication blocca i tentativi di login via XML-RPC, ma non disattiva i pingback non autenticati. Non darti per protetto solo perché quella casella è spuntata.

Cosa ha dimostrato Wordfence in laboratorio

L’ambiente di test era volutamente realistico: container isolati con WordPress 7.1.3, Debian 13.7, Apache 2.4.69, PHP 8.3.36 (mod_php) e libbrotli1 1.1.0-2+b7, con ASLR attivo.

Brotli vulnerabile: il proof of concept pubblico ha eseguito codice senza autenticazione.
Brotli aggiornato al pacchetto corretto di Debian, senza cambiare altro: la stessa sequenza non ha eseguito codice e il server è rimasto in salute.
PHP 8.3.35: il payload non ha eseguito codice; in un ambiente ha mandato in crash il worker PHP.

La conclusione: il payload pubblico non è universale, dipende dalla build esatta. Ma i server costruiti dalle stesse immagini (stessa base Docker, stessi pacchetti della distribuzione) condividono la stessa disposizione della memoria, quindi un payload funzionante può essere riutilizzato su molti di loro.

Wordfence fa notare anche che dall’esterno un attaccante di solito riesce a capire che il sito usa WordPress, quale PHP e quale web server, se XML-RPC è aperto e come fa le richieste in uscita: abbastanza per scegliere un payload preparato per un’immagine server diffusa. Quello che le normali richieste non rivelano è la build binaria esatta e la disposizione della memoria necessarie per adattare il payload a un server qualsiasi, e Wordfence non ha dimostrato di poterlo fare. Gli attacchi indiscriminati sono quindi meno affidabili, quelli mirati contro immagini standard restano plausibili.

Viene sfruttata?

Il quadro al 2 novembre 2026, secondo Wordfence:

CISA ha aggiunto CVE-2026-111497 al catalogo Known Exploited Vulnerabilities il 27 ottobre, senza indicare applicazione, percorso o esito.
Check Point segnala scansioni automatiche e payload sospetti, nessuna compromissione confermata. Previdian continua a osservare tentativi, ma non può dire se i bersagli fossero vulnerabili.
ELLIO ha catturato un tentativo contro Node.js il cui payload non ha prodotto una shell in 50 ripetizioni su un bersaglio vulnerabile equivalente. Imperva ed ELLIO hanno dimostrato una RCE su build vulnerabili di Node.js, in laboratorio.
Nessuna segnalazione verificabile in modo indipendente di una compromissione in produzione, e nessuna tramite i pingback di WordPress.

Dato che la scheda CISA non dà dettagli, l’assenza di un caso pubblico non significa che nessuno sia stato compromesso. In breve: i tentativi ci sono, compromissioni di massa non sono documentate. Non è un buon motivo per aspettare.

Sono esposto?

La versione di WordPress non dice nulla: conta la libreria Brotli caricata dal processo che serve il sito.

Hosting gestito o condiviso

Fai al provider due domande precise: il processo che serve il mio sito usa un decoder Brotli corretto? I servizi sono stati riavviati o rideployati dopo l’aggiornamento?

Server tuo

Controlla il pacchetto Brotli installato. Le distribuzioni fanno backport della correzione senza cambiare la versione base, quindi confronta la revisione completa con il bollettino del tuo vendor (per esempio su Debian 13 la correzione è in libbrotli1 1.1.0-2+deb13u1; vedi anche Ubuntu USN-8956-1 e Amazon Linux ALAS2023-2026-3334):

# Debian/Ubuntu
dpkg -l 'libbrotli*'

# RHEL, Alma, Rocky, Amazon Linux
rpm -qa 'brotli*' 'libbrotli*'

# curl (e quindi l'estensione curl di PHP) supporta brotli?
curl -V | grep -io brotli

Per verificare se pingback.ping è disponibile sul tuo sito, usa la chiamata non autenticata system.listMethods. Ti dice solo che il metodo esiste, non che il sito sia sfruttabile:

curl -s https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' \
  | grep -o 'pingback.ping'

Come correggere

1. Aggiorna Brotli e riavvia

Installa il pacchetto corretto del tuo vendor, poi riavvia ogni processo che aveva caricato la vecchia libreria: Apache, PHP-FPM e qualunque altro. Finché non riavvii, il vecchio codice resta in memoria.

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade 'libbrotli*'
sudo systemctl restart apache2        # se usi mod_php
sudo systemctl restart php8.3-fpm     # adatta alle tue versioni

# processi che usano ancora la vecchia libreria cancellata
sudo lsof 2>/dev/null | grep -i 'libbrotli.*deleted'

Container: ricostruisci e rideploya da un’immagine base aggiornata. Riavviare il container esistente non basta.
CloudLinux e stack simili: possono esserci più copie di Brotli (sistema, web server, PHP incluso nel pannello). Aggiornale tutte; CloudLinux ha una lista dedicata dei pacchetti.
Agenzie e hosting provider: controlla ogni ambiente, produzione, staging e vecchie installazioni. Un solo controllo dei pacchetti non copre tutti i pool PHP, i container o le immagini server.
Node.js sullo stesso server: corretto in 22.23.4, 24.22.1 e 26.12.1. Le linee 20, 23 e 25 sono a fine vita e non riceveranno correzioni.

2. Chiudi il percorso di WordPress (come tampone)

Se non usi i pingback (e quasi nessuno li usa), disattivarli elimina il percorso dimostrato da Wordfence. Non corregge la libreria, toglie solo una strada per arrivarci. Il modo più rapido è un mu-plugin:

<?php
// wp-content/mu-plugins/disable-pingbacks.php
add_filter('xmlrpc_methods', function (array $methods): array {
    unset($methods['pingback.ping'], $methods['pingback.extensions.getPingbacks']);
    return $methods;
});

Attenzione: il filtro xmlrpc_enabled, spesso consigliato per “spegnere XML-RPC”, agisce solo sui metodi che richiedono autenticazione e, come dice la documentazione di WordPress, non disattiva pingback.ping. Per questo lo snippet qui sopra rimuove il metodo in modo esplicito.

Se XML-RPC non ti serve affatto (niente Jetpack, niente vecchie app mobile), puoi bloccare xmlrpc.php a livello di web server. Ricorda che Impostazioni → Discussione vale solo per i nuovi articoli: quelli esistenti mantengono la propria impostazione sui ping. E verifica prima di spegnere qualcosa: cambiare il comportamento di XML-RPC o dei pingback può rompere integrazioni legittime.

3. Cerca segni di compromissione

Conserva i log (web server, PHP, processi, firewall, traffico in uscita) dal periodo precedente alla divulgazione fino all’aggiornamento e al riavvio.
Cerca richieste di pingback inattese, connessioni in uscita insolite dall’utente PHP e crash o riavvii dei worker PHP o Apache. La loro assenza non dimostra che non sia successo nulla.
Se sospetti una compromissione, isola prima il sistema, poi ruota credenziali, chiavi e salt. Nell’ordine inverso, un attaccante ancora dentro vede i nuovi segreti.

⚠ Non eseguire PoC trovati su GitHub

Come per PHP2Shell, esiste un proof of concept pubblico per WordPress, e parecchi finti. Non eseguirli in produzione: se vuoi fare test, usa un ambiente isolato e codice che hai letto riga per riga.

Cronologia

Febbraio 2026 — OpenAI segnala il bug; Brotli corregge il codice, ma senza una release.
21 ottobre 2026 — Node.js divulga e corregge il bug (“Node2Shell”); escono Brotli 1.0.10, 1.1.1 e 1.2.1.
22 ottobre 2026 — Google pubblica CVE-2026-111497; un advisory GitHub conferma che sono coinvolti i pacchetti Python Brotli e brotlicffi.
23 ottobre 2026 — Il bug viene soprannominato HTTP2Shell.
27 ottobre 2026 — CISA lo aggiunge al catalogo KEV.
2 novembre 2026 — Wordfence pubblica l’analisi per WordPress e i risultati di laboratorio.

Fonti

Se non l’hai ancora fatto, ripassa anche la mia checklist di sicurezza WordPress e verifica che il server sia su una release di PHP che corregge PHP2Shell: i due bug sono indipendenti e servono entrambe le correzioni.