Attacchi attivi a Burst Statistics: oltre 7.400 in 24 ore
Sfruttata in massa la CVE-2026-8181 nel plugin WordPress Burst Statistics: bypass dell’autenticazione e creazione di account admin. Oltre 7.400 attacchi in 24…
Contenuto
Gli attori malevoli stanno colpendo in massa le installazioni WordPress del plugin Burst Statistics versioni 3.4.0 e 3.4.1 sfruttando la vulnerabilità CVE-2026-8181 divulgata il 14 maggio 2026. Il bug consente il bypass dell’autenticazione tramite REST API a chiunque conosca uno username amministratore, trasformando una semplice richiesta in un takeover completo del sito. Wordfence ha bloccato oltre 7.400 attacchi mirati nelle 24 ore precedenti al report, mentre circa 115.000 siti risultano ancora esposti non avendo ancora aggiornato alla versione patchata 3.4.2.
"This vulnerability allows unauthenticated attackers who know a valid administrator username to fully impersonate that administrator for the duration of any REST API request, including WordPress core endpoints such as /wp-json/wp/v2/users, by supplying any arbitrary and incorrect password in a Basic Authentication header"
— Wordfence, come riportato da BleepingComputer
- Il plugin Burst Statistics, attivo su circa 200.000 siti WordPress, ha introdotto il bug nelle versioni 3.4.0 e 3.4.1 rilasciate il 23 aprile 2026.
- La CVE-2026-8181 consente a un attaccante non autenticato di impersonare un amministratore conoscendone solo lo username, tramite header Basic Authentication su endpoint REST API.
- Wordfence ha bloccato oltre 7.400 attacchi nelle 24 ore precedenti al report del 14 maggio 2026; la patch 3.4.2 è disponibile dal 12 maggio.
- Circa 115.000 siti rimangono potenzialmente vulnerabili, assumendo che i circa 85.000 aggiornamenti registrati su WordPress.org siano tutti alla versione patchata.
Il bug di logica che converte l’errore in autenticazione valida
La vulnerabilità CVE-2026-8181 nasce da un errore di logica nel codice del plugin Burst Statistics, un analytics alternativo a Google Analytics attivo su circa 200.000 siti WordPress. Nelle versioni 3.4.0 e 3.4.1, rilasciate il 23 aprile 2026, il modulo di autenticazione interpreta in modo errato il valore di ritorno della funzione nativa WordPress wp_authenticate_application_password(). Invece di rifiutare le credenziali non valide, il codice tratta sia l’oggetto WP_Error sia il valore null come indicazione di autenticazione positiva, aprendo una breccia nel controllo degli accessi.
Questa falla consente a un attaccante esterno di invocare wp_set_current_user() con un username amministratore noto e ottenere i permessi di admin per l’intera durata della richiesta REST API. Non è richiesta alcuna password corretta né un token valido: basta un header Basic Authentication contenente una password arbitraria e incorretta. Il risultato è un bypass totale dell’autenticazione su endpoint critici del core di WordPress, tra cui la gestione degli utenti.
Dallo username al controllo totale: il meccanismo dell’impersonificazione
L’exploit pratico è lineare. L’attaccante invia una richiesta a un endpoint REST API, ad esempio /wp-json/wp/v2/users, inserendo nell’header Authorization un token Basic Authentication costruito con un username amministratore esistente e una password casuale. Il plugin, convinto che l’autenticazione sia riuscita, imposta il contesto utente su quell’amministratore. Da quel momento la richiesta viene processata con i privilegi massimi, come se fosse legittima.
In questo scenario l’attaccante può creare nuovi account con privilegi di amministratore, modificare contenuti, installare plugin malevoli o reindirizzare il traffico verso siti pericolosi. Come riporta Wordfence nel report diffuso il 14 maggio 2026: "In a worst-case scenario, an attacker could exploit this flaw to create a new administrator-level account with no prior authentication whatsoever." L’impatto è un takeover completo del sito senza alcun prerequisito tecnico avanzato, se non la conoscenza di uno username admin.
Oltre 7.400 attacchi in 24 ore: la campagna in corso
L’attività malevola è già in fase avanzata. Secondo i dati diffusi da Wordfence il 14 maggio 2026, il firewall della società ha intercettato e bloccato oltre 7.400 attacchi mirati a CVE-2026-8181 nelle sole 24 ore precedenti al report. Il picco conferma che la vulnerabilità è passata rapidamente dalla divulgazione tecnica allo sfruttamento attivo su siti reali, un arco temporale di pochi giorni dal rilascio della versione patchata 3.4.2 avvenuto il 12 maggio.
La scoperta della falla risale all’8 maggio 2026, ma il passaggio allo sfruttamento attivo è avvenuto con un tempismo che lascia poco margine agli amministratori distratti. La versione patchata 3.4.2 è stata rilasciata soltanto il 12 maggio, lasciando una finestra di quattro giorni in cui la comunità ha dovuto affrontare contemporaneamente la divulgazione e l’escalation delle offensive.
Non è possibile al momento stabilire con precisione quanti siti siano stati effettivamente compromessi al di là degli attacchi bloccati, né se gli assalti provengano da una singola campagna coordinata o da più attori indipendenti. Tuttavia la velocità di escalation suggerisce che il modulo vulnerabile sia già integrato in toolkit di attacco automatizzati o in servizi di scan di massa, amplificando il rischio per ogni installazione non aggiornata.
Chi è ancora nel mirino: circa 115.000 siti esposti
Le statistiche di adozione del plugin tracciate su WordPress.org indicano che circa 85.000 installazioni hanno effettuato un aggiornamento dopo il rilascio della versione 3.4.2. Se si assume che tutti questi aggiornamenti siano stati applicati alla release patchata, rimangono circa 115.000 siti ancora vulnerabili su un totale stimato di circa 200.000 installazioni attive. Non è verificato, però, che ogni aggiornamento abbia riguardato esclusivamente la 3.4.2, né che i siti rimasti indietro utilizzino effettivamente le versioni bacate.
La discrepanza tra patch rilasciata e diffusione effettiva evidenzia un classico problema del panorama WordPress: molti gestori di siti non applicano gli aggiornamenti in tempo reale, lasciando esposte installazioni che spesso gestiscono dati sensibili o e-commerce. Il fatto che Burst Statistics venga promosso come alternativa privacy-friendly rende il caso ancora più paradossale: un tool pensato per ridurre la superficie di tracking si è trasformato in un vector di admin takeover a causa di un singolo errore di logica introdotto in una release recente.
Il caso solleva inoltre interrogativi sul processo di review del codice per plugin che gestiscono dati statistici senza raccogliere informazioni personali. Se un tool relativamente semplice introduce un bug di autenticazione così elementare, la fiducia implicita che gli utenti ripongono nella scarsa appetibilità di un software ‘privacy-focused’ si rivela un fattore di rischio aggiuntivo.
Cosa fare adesso: verificare versione, account e log
Gli amministratori di siti WordPress che utilizzano Burst Statistics devono agire immediatamente per ridurre la superficie di attacco. La priorità assoluta è verificare se la versione installata è la 3.4.2 o successiva: se il sito è ancora su 3.4.0 o 3.4.1, l’esposizione è totale e attiva.
- Aggiornare subito alla 3.4.2. Il vendor ha rilasciato la patch il 12 maggio 2026. Ogni istante di ritardo espone il sito a takeover automatizzati.
- Controllare la lista degli utenti amministratori. Verificare se sono stati creati account admin non autorizzati, in particolare attraverso endpoint REST API come
/wp-json/wp/v2/users. - Rivoltare i log del server e del firewall. Cercare richieste anonime con header Basic Authentication verso endpoint REST API che restituiscono codici HTTP 200 invece di 401 o 403.
- Verificare file e temi. In caso di compromissione presunta, ispezionare la presenza di backdoor, redirect nascosti o plugin sospetti installati dopo la data di rilascio delle versioni vulnerabili.
L’incidente CVE-2026-8181 dimostra che anche plugin di nicchia con un profilo privacy-first possono diventare in poche settimane vector critici di compromissione totale. Il problema non è nella maturità del codice distribuito, ma nella velocità con cui un errore di logica isolato si traduce in exploit di massa quando incontra un’utenza abituata a ritardi negli aggiornamenti. Per il settore dei CMS, la lezione è che la segmentazione tra “strumento innocuo” e “superficie di attacco” è molto più sottile di quanto si preferisce ammettere.
Domande frequenti
Perché conoscere solo lo username è sufficiente per l’attacco?
La vulnerabilità bypassa completamente il controllo della password. L’attaccante invia un header Basic Authentication con username reale e password arbitraria; il plugin interpreta il fallimento dell’autenticazione come successo, impostando il contesto utente su quell’amministratore.
La versione 3.4.1.1 è vulnerabile come riportato da altri database?
Il report principale di Wordfence indica come affette le versioni 3.4.0 e 3.4.1. Alcuni database, come Patchstack, citano anche la 3.4.1.1, ma non è confermato nel testo fornito se tale release contenga effettivamente il codice vulnerabile.
Cosa rischia concretamente un sito compromesso?
In caso di exploit riuscito, l’attaccante ottiene privilegi di amministratore e può creare account nascosti, installare backdoor, alterare contenuti, reindirizzare visitatori o rubare dati sensibili memorizzati nel database WordPress.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.