Gli attaccanti hanno armato la RCE del core di WordPress in 90 minuti

Gli attaccanti hanno iniziato a sfruttare una catena critica di esecuzione remota di codice (RCE) nel core di WordPress appena 90 minuti dopo la pubblicazione della versione patchata, secondo una nuova ricerca di Patchstack. Il fornitore di sicurezza, che vende servizi di firewall per applicazioni web e di gestione delle vulnerabilità per WordPress, afferma di aver bloccato più di 65.000 tentativi di sfruttamento contro le due vulnerabilità sottostanti nei giorni successivi alla divulgazione. Questi tentativi provenivano da più di 1.500 indirizzi IP unici, e quasi tutti miravano a siti non patchati che eseguivano versioni vulnerabili di WordPress. La velocità con cui è iniziata la campagna di attacco mostra che i proprietari di siti web hanno quasi nessun tempo tra la pubblicazione di una correzione e il tentativo dei criminali di utilizzare il difetto.

L'incidente coinvolge due difetti separati che possono essere combinati in un'unica compromissione. Il primo, CVE-2026-60137, è un'iniezione SQL in una parte di WordPress chiamata WP_Query tramite il parametro author_exclude o author__not_in. Un'iniezione SQL si verifica quando un attaccante inserisce comandi di database in input che il sito poi esegue; in questo caso l'iniezione è di sola lettura, il che significa che può leggere informazioni dal database del sito ma non può scrivere direttamente. Questo difetto colpisce le versioni di WordPress dalla 6.8 alla 7.0.1. Il secondo difetto, CVE-2026-63030, è una confusione di route e handler nell'endpoint batch dell'API REST a /batch/v1. L'API REST è un modo per programmi esterni di comunicare con WordPress, e l'endpoint batch consente di inviare più azioni contemporaneamente. Questo difetto colpisce le versioni dalla 6.9 alla 7.0.1. Da soli, nessuno dei due difetti dà all'attaccante il controllo totale. Ma quando vengono concatenati, la confusione del batch consente a una richiesta non autenticata di far passare l'iniezione SQL oltre i controlli normali dei dati, e un exploit pubblico crea quindi un nuovo account amministratore e alla fine ottiene l'esecuzione remota di codice. Le correzioni sono state rilasciate in WordPress 7.0.2, 6.9.5 e 6.8.6. Le versioni precedenti come 6.1 e 6.2 non sono interessate, perché il codice vulnerabile è stato introdotto solo nella 6.8 e nella 6.9.

La telemetria di Patchstack mostra quanto rapidamente sia iniziata la campagna. La correzione è stata impegnata nel trunk di sviluppo di WordPress circa 1,5 ore prima che la versione 7.0.2 fosse taggata per il rilascio. Poiché chiunque può osservare le modifiche al codice, quel commit ha effettivamente agito come divulgazione pubblica. I primi tentativi di sfruttamento reali hanno raggiunto i sensori di Patchstack circa 90 minuti dopo il rilascio della 7.0.2, e tre ore dopo il commit della correzione. Nei giorni successivi, Patchstack ha bloccato più di 65.000 tentativi di sfruttamento da oltre 1.500 indirizzi IP unici. L'azienda nota che la sua funzionalità RapidMitigate attiva le regole di mitigazione solo sui siti web che eseguono effettivamente una versione vulnerabile, e rimuove tali regole dopo che il sito è stato patchato, quindi i tentativi bloccati erano tutti mirati a sistemi non patchati. Il traffico è stato anche osservato all'interno dell'applicazione stessa, il che significa che qualsiasi firewall a livello di rete o server di fronte al sito aveva già permesso il passaggio della richiesta. Nessuna singola rete dominava il traffico; la rete più trafficata rappresentava solo il 6,45 percento, e le prime dieci reti insieme costituivano circa il 22 percento. Gli IP attaccanti provenivano principalmente da provider cloud e VPS come Vultr (Choopa), M247 e HostPapa. Quasi tutto il traffico bloccato era una sonda di iniezione SQL in fase iniziale, ma su un sito non protetto la stessa richiesta sarebbe continuata fino alla creazione dell'amministratore e all'esecuzione di codice.

Il traffico ha dato un quadro chiaro di come lavoravano gli attaccanti. Quasi il 97 percento di tutto ciò che Patchstack ha bloccato mirava all'endpoint batch REST. Gli attaccanti usavano due modi principali per raggiungerlo: /?rest_route=/batch/v1 e /wp-json/batch/v1, con il primo più comune. Hanno anche sparso varianti di percorso come /index.php?rest_route=/batch/v1, /wp/?rest_route=/batch/v1, /blog/?rest_route=/batch/v1, e /wp-json?rest_route=/batch/v1 per superare semplici regole di filtraggio. Circa tre quarti delle richieste bloccate includevano un tentativo di iniezione SQL nel parametro author_exclude, e i payload usavano parole chiave con maiuscole/minuscole miste, commenti inline, commenti condizionali specifici del database e codifica URL per nascondersi. I ricercatori hanno diviso le richieste in due gruppi. Il gruppo molto più grande era di sonde di validazione, come AND (1=1), AND (1=2), o OR SLEEP(5), usate per verificare se un sito fosse vulnerabile prima di spendere più sforzo. Un gruppo molto più piccolo ma più serio trasportava l'intera catena di escalation dei privilegi pubblicata e andava direttamente alla creazione di un amministratore, con una richiesta batch che avrebbe chiamato POST /wp/v2/users e impostato i ruoli su amministratore. Quei tentativi di catena completa provenivano da soli tre indirizzi IP: 129.121.77.134, 91.202.233.61 e 125.164.233.50.

Patchstack riporta anche che le proprie regole RapidMitigate per le due vulnerabilità sono state implementate nel momento in cui è stato pubblicato l'avviso, prima che arrivassero i primi tentativi. Durante la campagna, il 99,9 percento di tutti i tentativi bloccati è stato fermato da quelle due specifiche regole di vulnerabilità del core di WordPress, mentre regole generiche aggiuntive sono appena registrate. Questo risultato mostra che le regole di causa principale hanno catturato gli attacchi prima che potessero raggiungere le barriere generiche.

Per chiunque stia ancora eseguendo WordPress dalla 6.9 alla 7.0.1 senza la patch, l'esito è grave. L'exploit pubblico, diffuso come strumento soprannominato wp2shell, usa l'iniezione SQL di sola lettura per falsificare dati su cui WordPress poi agisce. Semina post e una modifica del customizer che portano a un nuovo account amministratore. Una volta che un attaccante ha quell'account admin, può accedere, caricare un plugin che è in realtà una web shell, ed eseguire codice sul server. Patchstack afferma di aver verificato indipendentemente che le vulnerabilità combinate portano alla compromissione totale del sito, inclusa l'esecuzione remota di codice. I proprietari di siti dovrebbero controllare la presenza di account amministratore sconosciuti, plugin inattesi, file PHP casuali nella directory uploads e qualsiasi cosa inaspettata nella cartella mu-plugins, che si carica automaticamente e non appare nella schermata normale dei plugin.

C'è anche un avvertimento sulle regole di mitigazione stesse. Secondo Patchstack, quasi ogni regola di firewall per applicazioni web pubblicata nelle prime ore dopo la divulgazione condivideva un punto cieco critico. Le regole cercavano batch/v1 nell'URL della richiesta, perché è così che il codice proof of concept pubblico raggiungeva l'endpoint. Ma WordPress registra rest_route come variabile di query pubblica e legge quelle variabili dal corpo POST prima di leggerle dalla stringa di query. Pertanto, un attaccante può inviare una semplice richiesta POST alla radice del sito con rest_route=/batch/v1 nel corpo del modulo e il payload batch accanto, e WordPress instraderà l'intera cosa all'endpoint batch. L'URL non contiene mai batch/v1, quindi qualsiasi regola che ispeziona solo l'URL vede una richiesta innocua alla radice del sito e la lascia passare. Una regola che controlla solo l'URL può essere aggirata con un piccolo cambiamento nella richiesta. Patchstack ha scoperto questa lacuna e l'ha gestita come divulgazione coordinata, informando prima i fornitori di sicurezza interessati e il team di sicurezza di WordPress, così che gli host e i provider WAF a livello DNS potessero aggiornare le loro regole prima che il rapporto fosse pubblicato. Patchstack afferma che le sue stesse prime regole avevano la stessa lacuna, e ora le ha aggiornate per cercare la route batch ovunque WordPress la accetti, sia nell'URL che nel corpo POST. A partire dalle 17:00 UTC del 21 luglio, Patchstack ha iniziato a vedere tentativi di sfruttamento che usavano queste forme alternative, con rest_route e l'array di richieste annidato trasportato nel corpo POST. Altri host hanno visto lo stesso schema e hanno riportato che le loro regole originali solo URL venivano aggirate.

Gli indicatori chiave di rilevamento per questa campagna includono qualsiasi richiesta all'endpoint batch in qualsiasi forma, come /wp-json/batch/v1, ?rest_route=/batch/v1, o rest_route=/batch/v1 nel corpo POST, più le varianti di percorso. I webmaster dovrebbero anche cercare un valore author_exclude non intero, specialmente con UNION, SLEEP(, o AND/OR offuscati con commenti, e abbinare le grafie author.exclude e author exclude perché WordPress le normalizza di nuovo in author_exclude. Qualsiasi scrittura REST privilegiata annidata in un corpo batch, più comunemente POST /wp/v2/users con "roles":["administrator"], vale la pena di essere segnalata. Dopo il fatto, i segni di compromissione includono un nuovo amministratore che non hai creato, un plugin aggiunto di recente che non riconosci, un file PHP casuale sotto wp-content/uploads o wp-content/plugins, e file inaspettati in wp-content/mu-plugins.

La lezione più importante è il tempismo. Novanta minuti da una patch pubblica allo sfruttamento dal vivo non lasciano tempo per pianificare una finestra di manutenzione, testare un aggiornamento e distribuirlo in sicurezza. Ecco perché la patch virtuale e l'aggiornamento immediato contano. Aggiorna a WordPress 7.0.2, 6.9.5 o 6.8.6 appena puoi, e se ciò richiede giorni piuttosto che minuti, assicurati che qualcosa stia coprendo il gap mentre ci arrivi. Per i proprietari di siti che necessitano di hosting WordPress gestito con sicurezza integrata, AEU Hosting (https://albhosting.eu) offre hosting WordPress gestito protetto end-to-end, che può aiutare a ridurre la finestra di esposizione mentre viene applicato un aggiornamento del core.