Gli attacchi a WordPress CVE-2026-87902 arrivano all’esecuzione di codice
WordPress CVE-2026-87902, una falla critica in WordPress Core, è ora sfruttata attivamente oltre il semplice probing, secondo Patchstack. La vulnerabilità interessa le versioni di WordPress dalla 4.7.0 alla 7.1.1 ed è stata corretta in WordPress 7.1.2, con release corrette indicate anche come 7.0.6, 6.9.9, 6.8.10 e backport fino alla 4.7.37. Patchstack segnala un punteggio CVSS di 9.2, che la colloca nella fascia critica, e afferma che lo sfruttamento non richiede accesso autenticato.
Il problema è un path traversal che porta a local file inclusion e, in determinate condizioni, a remote code execution. Path traversal significa che un aggressore tenta di fare in modo che un sito web apra file al di fuori della cartella che avrebbe dovuto usare. Local file inclusion significa che il sito viene indotto a caricare un file già presente sul server. Remote code execution, spesso abbreviato in RCE, significa che un aggressore può fare eseguire al server comandi o codice scelti da lui. In questo caso, Patchstack afferma che la falla si trova nella risoluzione dei template di pagina di WordPress, e che il primo tentativo di sfruttamento osservato è arrivato alle 11:49 UTC del 22 settembre 2026, lo stesso giorno in cui è stato pubblicato WordPress 7.1.2.
Patchstack afferma che la campagna è cambiata rapidamente. All’inizio, le richieste erano ricognizioni contro file innocui del core di WordPress, il che significa che gli aggressori stavano verificando se i siti fossero vulnerabili. Entro il 23 settembre, il volume di traffico era cresciuto fino a oltre dieci volte il livello della prima sera, aveva raggiunto una distribuzione più ampia di siti ed era passato attraverso tre fasi: verificare se l’inclusione funzionasse, verificare se il pearcmd.php di PEAR fosse raggiungibile, e poi tentare di scrivere file su disco.
La prima fase puntava l’inclusione vulnerabile del template verso normali file del core. Patchstack afferma che wp-links-opml.php è rimasto il bersaglio più comune, con wp-includes/feed-rss2.php anch’esso presente in volume, insieme a wp-cron.php, wp-includes/functions.php, wp-login.php e install.php. Una risposta riuscita da uno di questi file indica a un aggressore che il percorso di codice vulnerabile è raggiungibile.
La seconda fase prendeva di mira il pearcmd.php di PEAR. PEAR è un sistema di pacchetti PHP, e pearcmd.php è uno script di comando associato a esso. Patchstack afferma che gli aggressori hanno usato richieste contenenti un page_id valido, un valore pagename con codifica di traversal, e +config-show nella query string. Quando PHP viene eseguito con register_argc_argv abilitato, la query string può essere esposta allo script incluso come argomenti in stile riga di comando, quindi +config-show viene passato a pearcmd. Questo conferma sia che PEAR esiste sull’host sia che il trucco degli argomenti funziona. Patchstack afferma che gli aggressori hanno provato tre posizioni: /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php e /usr/share/pear/pearcmd.php.
La terza fase ha sostituito config-show con config-create. Patchstack afferma che pearcmd può usarlo per scrivere un file nel punto indicato, con contenuto controllato dall’aggressore. Le richieste osservate tentavano di scrivere file PHP, trasformando il problema in esecuzione di codice quando la catena riesce. Patchstack descrive due grandi gruppi di payload: alcuni scrivono stringhe marcatore come CVE-2026-87902-POC-OK o un LUCIFER-RCE-OK offuscato costruito con chiamate chr(), comportamento coerente con la creazione di liste di host vulnerabili; altri scrivono un breve tag PHP che esegue un comando shell quando viene acceduto. Patchstack afferma che il secondo gruppo non è ricerca.
I file osservati da Patchstack sono stati depositati in /tmp e /var/tmp. I nomi dei file includevano wp-pear-rce-flag.php, poc87902.php, luci_.php e zeta_.php. Un file PHP in /tmp di solito non è direttamente raggiungibile via web, quindi Patchstack lo descrive come prova di esecuzione piuttosto che come backdoor persistente di per sé. Anche così, la stessa capacità di scrivere un file può essere usata in posizioni più utili, e un host su cui questo riesce dovrebbe essere considerato compromesso.
Patchstack afferma inoltre che lo sfruttamento è stato mercificato. Ha osservato gli user agent cve-2026-87902-poc/1.0 e nuclei-cve-2026-87902/1.0, incluso un template Nuclei nominato. Nuclei è uno strumento di scansione usato per testare molti bersagli con template. Patchstack afferma che ciò significa che l’attività non è più limitata a pochi operatori che lavorano a partire dal diff della patch. Avverte inoltre che la maggior parte del traffico rimanente usa user agent di browser falsificati, quindi filtrare solo per user agent non è affidabile.
Le prime richieste rivelano perché questa non è una scansione generica. Patchstack afferma che i payload corrispondono alla codifica affrontata dalla patch, indicando che i primi operatori stavano lavorando sulla differenza nel codice invece che su una scoperta indipendente. La sanificazione di WordPress preservava gli ottetti con escape mentre riscriveva i punti letterali e tagliava in corrispondenza degli slash letterali, quindi una semplice stringa di traversal non sarebbe sopravvissuta, ma il traversal codificato sì. Questo rende %2e%2e e %252e%252e indicatori utili nei log. Le richieste includevano inoltre di solito page_id insieme a pagename. Patchstack afferma che è necessario un ID di pagina reale perché altrimenti WordPress restituisce un 404 e il percorso del template di pagina non viene raggiunto.
La campagna non è limitata a un unico schema esatto di richiesta. Patchstack ha osservato profondità di traversal da uno a dodici livelli, caratteri codificati maiuscoli e minuscoli, codifica singola e doppia, richieste GET e POST, e traffico inviato sia alla root del sito sia a /index.php. In seguito POST è diventato più comune di GET, e questo conta perché WordPress legge pagename dal corpo POST prima della query string. Molti payload iniziavano con templates%2f perché il traversal deve proseguire da una directory reale che inizia con page- prima di risalire fuori dal tema. Patchstack ha visto anche template e un prefisso page-templates malformato.
È improbabile che il blocco degli IP sorgente sia sufficiente. Patchstack afferma che la prima sera proveniva da un piccolo cluster di indirizzi, ma il traffico si è poi distribuito su alcune centinaia. Gli indirizzi più attivi elencati erano 43.250.53.42, 180.251.159.243, 195.178.110.247, 107.189.14.87, 45.61.184.170 e 92.246.130.76. Afferma che i tentativi di scrittura di file provenivano da un sottoinsieme più piccolo, un modello che descrive come pochi operatori che agiscono sui risultati prodotti da una popolazione di scansione più ampia.
La priorità pratica è applicare la patch. Patchstack afferma che WordPress 7.1.2, o la release corretta per il ramo pertinente, resta la soluzione, e l’esistenza di tentativi di scrittura di file nella terza fase rende urgente l’aggiornamento. Poiché la correzione è stata backportata fino alla 4.7.37, i siti interessati possono ricevere una release corretta senza effettuare un salto di versione principale. Patchstack afferma che i proprietari di siti che valutano l’esposizione dovrebbero considerare se il tema attivo ha una directory page- di primo livello e se PHP ha register_argc_argv abilitato.
Se un aggiornamento immediato non è possibile, Patchstack afferma che rifiutare le sequenze di traversal nel parametro pagename è una misura temporanea efficace, perché uno slug di pagina normale non le contiene. Disabilitare register_argc_argv non corregge l’inclusione di file in sé, ma interrompe la catena pearcmd, che secondo Patchstack può fare la differenza tra una fuga di informazioni e l’esecuzione di codice.