Una vulnerabilità di Brotli può consentire la code execution in WordPress
La vulnerabilità di Brotli identificata come CVE-2026-111497 può consentire a un attaccante non autenticato di eseguire codice tramite WordPress quando coincidono diverse condizioni relative al server e al sito. Google ha pubblicato la vulnerabilità il 22 ottobre 2026, un giorno dopo che il progetto Brotli aveva distribuito release corrette. Ha un punteggio CVSS v4.0 di 9,2 su 10, una valutazione standard della gravità che la classifica come critica. La falla è anche chiamata informalmente HTTP2Shell, Node2Shell e Brotli2Shell, sebbene non coinvolga il protocollo HTTP/2.
Brotli è un formato di compressione e una software library che riduce le dimensioni dei contenuti web durante il trasferimento. Di solito viene fornito da una piattaforma di hosting, un sistema operativo, una container image, un web server o un altro componente server, quindi il proprietario di un sito WordPress potrebbe non vederne mai il nome nella dashboard. La vulnerabilità non si trova in WordPress Core, in un plugin o in un theme. L'aggiornamento di questi componenti non sostituirà la software library Brotli interessata.
CVE-2026-111497 è un out-of-bounds write, ossia dati compressi dannosi possono indurre Brotli a scrivere oltre l'area di memoria assegnata. Questa corruzione può provocare il crash di un processo, rivelare informazioni conservate in memoria o consentire la remote code execution, facendo sì che un attaccante esegua comandi senza essere fisicamente presente. Tuttavia, la semplice presenza di Brotli su un server non dimostra che un sito web sia sfruttabile. Dati compressi controllati dall'attaccante devono raggiungere un decoder vulnerabile tramite un sito web o un altro servizio esposto.
Le prime release upstream corrette sono Brotli 1.0.10 per le versioni dalla 1.0.3 alla 1.0.9, 1.1.1 per la versione 1.1.0 e 1.2.1 per la versione 1.2.0. I fornitori Linux e di hosting possono applicare un backport, aggiungendo cioè la correzione di sicurezza a un package meno recente. Debian 13, per esempio, ha corretto il problema in libbrotli1 1.1.0-2+deb13u1, anche se il nome del package inizia ancora con 1.1.0. Gli amministratori devono quindi confrontare la revisione completa del package con l'avviso di sicurezza del fornitore, anziché basarsi sui primi tre numeri della versione.
Il proof of concept pubblico per WordPress usa XML-RPC, un'interfaccia di WordPress tramite la quale altri sistemi possono richiamare funzioni del sito. Una richiesta non autenticata invoca pingback.ping in xmlrpc.php e fornisce un indirizzo web controllato dall'attaccante. WordPress recupera tale indirizzo per verificare che contenga un link a un post autentico. Il server dell'attaccante risponde quindi con dati appositamente preparati e contrassegnati come compressi con Brotli. Se il decoder, la build PHP e la disposizione della memoria corrispondono al payload, l'attaccante può eseguire codice con i permessi assegnati al processo PHP del sito web.
Questa modalità richiede diversi prerequisiti. xmlrpc.php deve essere raggiungibile, pingback.ping deve essere registrato, il post deve accettare i ping, il server deve essere autorizzato a effettuare la richiesta in uscita e l'HTTP client del sito, ossia il software che recupera i contenuti web, deve utilizzare il decoder interessato. L'exploit pubblicato deve inoltre corrispondere strettamente alla build PHP, al runtime environment e al memory layout. XML-RPC è soltanto il trigger scelto per questa dimostrazione, non un requisito intrinseco della falla di Brotli. Altri software potrebbero esporre lo stesso decoder, mentre plugin e theme potrebbero creare ulteriori percorsi di attacco in WordPress.
Wordfence Threat Intelligence ha riprodotto la code execution senza autenticazione in ambienti container isolati, ossia ambienti software confezionati, utilizzando WordPress 7.1.3 su Debian 13.7, Apache 2.4.69, PHP 8.3.36 eseguito all'interno di Apache come mod_php e il package vulnerabile Debian libbrotli1 1.1.0-2+b7. La memory randomization standard del sistema operativo era abilitata. Dopo aver aggiornato soltanto Brotli al package corretto di Debian, la stessa sequenza non ha eseguito codice e il server è rimasto operativo.
Lo stesso payload non ha eseguito codice contro PHP 8.3.35. In un ambiente WordPress vulnerabile, ha invece provocato il crash del PHP worker. Wordfence afferma che ciò dimostra come la versione PHP, da sola, non determini il risultato. La build e il runtime esatti possono stabilire se un payload esegue codice, provoca un crash o non ha alcun effetto. Gli attaccanti possono identificare da remoto WordPress, PHP, il web server, la disponibilità di XML-RPC e alcuni comportamenti delle richieste in uscita, il che potrebbe aiutarli a selezionare payload per server image riutilizzate comunemente. Le normali richieste web non rivelano in genere la build compilata o il memory layout esatti necessari per adattare questo payload a un server qualsiasi, e Wordfence non ha dimostrato un simile adattamento da remoto.
Esistono prove di attività mirate, ma gli esiti documentati pubblicamente rimangono limitati. La US Cybersecurity and Infrastructure Security Agency ha aggiunto CVE-2026-111497 al proprio Known Exploited Vulnerabilities catalog il 27 ottobre 2026, senza identificare l'applicazione interessata, la vittima, il percorso di attacco o l'esito. ELLIO ha rilevato un tentativo diretto contro una build ufficiale di Node.js, che però non ha prodotto accesso ai comandi in 50 repliche contro un target vulnerabile corrispondente. Previdian ha continuato a rilevare tentativi fino al 2 novembre, precisando però che la sua telemetria non consentiva di stabilire se i target fossero vulnerabili o se gli attacchi avessero avuto successo. Check Point ha segnalato scanning automatizzato e payload sospetti, ma nessuna compromissione confermata. Imperva ed ELLIO hanno ottenuto separatamente la code execution contro build vulnerabili di Node.js in laboratori controllati.
Questi test dimostrano che lo sfruttamento è possibile al di fuori di WordPress, ma non documentano una violazione in produzione. Al 2 novembre 2026, Wordfence non aveva trovato alcuna segnalazione pubblica verificabile in modo indipendente di una compromissione riuscita in produzione o di una compromissione tramite il percorso XML-RPC di WordPress. Le limitate informazioni pubbliche fornite da CISA fanno sì che questa assenza non costituisca una prova che lo sfruttamento non abbia mai avuto successo.
La versione di WordPress mostrata in Strumenti e Salute del sito non permette di stabilire se il server sia protetto. I clienti di servizi di hosting gestito dovrebbero chiedere se ogni decoder Brotli utilizzato dal loro sito contenga la correzione per CVE-2026-111497 e se tutti i servizi interessati siano stati riavviati o sottoposti nuovamente a deployment. La funzione XML-RPC system.listMethods, accessibile senza autenticazione, può mostrare se pingback.ping è registrato, ma questo controllo sicuro dimostra soltanto che il metodo esiste, non che lo sfruttamento sia possibile. Disabilitare i pingback futuri in Impostazioni e Discussione potrebbe non modificare i post meno recenti, che possono conservare le impostazioni precedenti.
L'opzione Disable XML-RPC authentication di Wordfence non disattiva i pingback non autenticati. Anche il filter di WordPress denominato xmlrpc_enabled si applica soltanto ai metodi che richiedono autenticazione e non disabilita pingback.ping. Modificare il comportamento di XML-RPC o dei pingback può interrompere integrazioni legittime e blocca soltanto il percorso WordPress dimostrato. Non corregge Brotli.
Gli amministratori che gestiscono autonomamente i propri sistemi dovrebbero installare l'aggiornamento del sistema operativo o della piattaforma, verificare la revisione completa del package e riavviare Apache, PHP-FPM, che esegue PHP come servizio separato, o qualsiasi altro processo che abbia caricato la vecchia software library.