WordPress sotto attacco: file PHP malevoli in /tmp in meno di 5 ore

Il 22 settembre 2026, alle 17:44 UTC, meno di cinque ore dopo il rilascio di WordPress 7.1.2, sono arrivate le prime richieste malevole contro installazioni vulnerabili. CVE-2026-87902, una falla di path traversal nel core con punteggio CVSS 4.0 di 9.2 secondo l'advisory ufficiale GitHub Security Lab, ha già generato file PHP dannosi su server esposti. La gravità non sta solo nella velocità di exploitation, ma in una catena tecnica che sfrutta configurazioni PHP diffuse su hosting condivisi: il parametro register_argc_argv, attivo di default fino alla versione 8.5, trasforma un'inclusione di file locale in esecuzione di codice remoto.

Il meccanismo: quando la sanitizzazione arriva tardi

La falla risiede nella risoluzione del template di pagina. Quando WordPress elabora una richiesta, get_page_template() chiama santize_title_with_dashes() e poi urldecode() sul parametro pagename. Il ricercatore Robert Ressl ha dimostrato che un double-encoding del separatore di directory — %252f invece di %2f — attraversa questa sequenza indenne: wp_basename() non interpreta %2f come slash, la sanitizzazione preserva gli octet validi, e il secondo urldecode() attiva il traversal dopo che i controlli sono già stati superati.

Il risultato è un Local File Inclusion non autenticato. Da solo, il LFI non esegue codice arbitrario: richiede un file PHP leggibile e un percorso prevedibile. Qui entra la catena PEAR. Nelle configurazioni PHP con register_argc_argv=On — il default fino alla 8.5, inclusa l'immagine ufficiale Docker wordpress:php8.3-apache verificata nel PoC di Ressl — il file pearcmd.php interpreta gli argomenti della query come comandi PEAR. L'attaccante usa config-show per verificare la presenza, poi config-create per scrivere un file PHP controllato in /tmp. Una seconda richiesta include quel file, completando la RCE.

Il GitHub Security Advisory descrive le condizioni con precisione: "An unauthenticated attacker can make get_page_template() page-template resolution include a chosen readable local .php file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to RCE." La condizionalità non è rassicurante: molti hosting condivisi, inclusi ambienti cPanel con PHP precedente alla 8.5, soddisfano tutti i prerequisiti.

La corsa degli attaccanti: sonde, poi armi

Patchstack ha osservato un pattern classico di weaponization accelerata. Le prime richieste, alle 17:44 UTC del 22 settembre, erano probabilmente sonde di verifica. In 24 ore il traffico è decuplicato, con passaggio diretto alla scrittura di payload permanenti. Secondo Patchstack via BleepingComputer: "The third stage swaps config-show for config-create, which pearcmd will happily use to write a file wherever it is told, with content the attacker controls."

I nomi file osservati — wp-pear-rce-flag.php, poc87902.php, luci_<casuale>.php, zeta_<casuale>.php — suggeriscono una campagna coordinata piuttosto che exploit isolati. La presenza di flag con l'acronimo RCE nel nome indica che gli attaccanti stanno tracciando le installazioni vulnerabili, probabilmente per accessi successivi o per rivendita di accesso.

Il record NVD assegna CVE-2026-87902 un CVSS 3.1 di 8.1 HIGH, con vettore AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Il punteggio più alto di 9.2 Critical con CVSS 4.0 proviene dall'advisory GitHub Security Lab ufficiale di WordPress. CISA ha inserito la vulnerabilità nel catalogo KEV il 25 settembre 2026, con richiesta di azione entro il 28 settembre.

"Come cortesia, la correzione di sicurezza è stata riportata su tutti i rami idonei a ricevere aggiornamenti di sicurezza (attualmente fino alla 4.7). Ricordiamo che solo la versione più recente di WordPress è supportata attivamente."
— WordPress, citato da TurboLab.it

Il paradosso del backport: sicurezza apparente

La politica di backport di WordPress è tecnicamente corretta e politicamente rischiosa. Ventiquattro rami precedenti ricevono la patch, dalla 7.0.6 fino alla 4.7.37. Chi gestisce un sito sulla 5.8 o sulla 6.2 vede un aggiornamento di sicurezza disponibile e aggiorna, credendo di essere protetto. Il problema è che WordPress non rilascia più aggiornamenti funzionali per quelle versioni, non verifica la compatibilità con PHP futuri, non garantisce che il backport funzioni con plugin di terze parti.

L'articolo di IlSoftware.it mette in guarda proprio su questo: "Non è corretto dire che ogni installazione di WordPress vulnerabile permette una RCE." La cautela è necessaria nella descrizione tecnica, ma diventa pericolosa nella comunicazione operativa. Un amministratore che legge che la RCE è "condizionale" potrebbe ritardare la verifica, senza comprendere che le condizioni — tema con directory page-*, PHP con register_argc_argv=On, pearcmd.php presente — sono comuni nell'ecosistema hosting condiviso.

La superficie di attacco specifica per temi italiani o europei tra quelli elencati non è documentata. Il dossier non specifica quanti siti in Italia usino Neve, Hestia o Sydney, né quanti provider di hosting condiviso mantengano register_argc_argv=On su PHP 8.3 o 8.4.

Cosa fare adesso

Per gli amministratori con accesso al server, quattro azioni prioritarie:

• Aggiornare immediatamente a WordPress 7.1.2 se si usa una versione dalla 4.7.0 alla 7.1.1; verificare che l'aggiornamento sia completato su tutti i siti in multisite.
• Ispezire /tmp, /var/tmp e le directory scrivibili dal processo web per la presenza di file PHP con nomi che corrispondono agli indicatori osservati: wp-pear-rce-flag.php, poc87902.php, o pattern luci_*.php e zeta_*.php.
• Verificare i log di accesso per richieste POST con pagename contenente sequenze double-encoded, in particolare tra le 17:44 UTC del 22 settembre e le 24 ore successive.
• Controllare lo stato di register_argc_argv in php.ini: se è On e non è strettamente necessario, disattivarlo come misura di riduzione della superficie di attacco, indipendentemente dalla versione WordPress.

L'aggiornamento non cancella file già scritti né rimuove backdoor eventualmente installate. Chi aggiorna senza verificare il filesystem assume un rischio che il dossier non può quantificare, perché il numero esatto di siti con RCE riuscita non è documentato dalle fonti.

Perché cinque ore rendono impraticabile la difesa manuale

La finestra di exploitation, compressa tra il rilascio della patch e il primo attacco osservato, rende irrealistica la risposta per molte realtà. Un'agenzia con centinaia di siti WordPress su hosting condiviso non può aggiornarli tutti manualmente in cinque ore, specialmente se deve coordinarsi con provider che controllano l'accesso SSH o cPanel. L'automazione dell'aggiornamento, se configurata, risolve il problema per le installazioni future ma non per quelle già compromesse.

Il vero interrogativo riguarda la longevità del backport. WordPress ha corretto la 4.7.37 "come cortesia". Quella cortesia non si ripeterà indefinitamente, e ogni sito che rimane su un ramo unsupported accumula debito tecnico che trasforma un aggiornamento di sicurezza in decisione di migrazione. Per molti gestori di siti italiani, specialmente su hosting economici con PHP preconfigurato, la sicurezza del codice si scontra con la rigidità dell'infrastruttura.

Domande e risposte

La mia versione WordPress è precedente alla 4.7. Non ricevo aggiornamenti. Sono a rischio?
Sì. Le versioni precedenti alla 4.7 non ricevono alcun backport. L'unica mitigazione documentata è la migrazione a una versione supportata.

Ho aggiornato a 7.1.2. Devo comunque controllare i log?
Sì. L'aggiornamento corregge la vulnerabilità ma non rimuove file malevoli eventualmente già scritti. La verifica del filesystem e dei log è necessaria per escludere compromissioni pregresse.

Il mio hosting usa PHP 8.3. register_argc_argv è pericoloso anche dopo la patch?
Il parametro register_argc_argv è uno dei prerequisiti della catena RCE documentata. La sua disattivazione riduce la superficie di attacco per vulnerabilità future che potrebbero sfruttare meccanismi simili, anche se la patch di WordPress elimina questo vettore specifico.

Fonti

• https://turbolab.it/server-1224/wordpress-exploit-attivo-falla-critica-file-php-malevoli-gia-sui-server-aggiornamento-7-1-2-gia-disponibile-4873
• https://www.giapox.it/wordpress-segnalato-lo-sfruttamento-di-una-falla-critica/
• https://www.ilsoftware.it/wordpress-falla-critica-rce-cve-2026-87902-senza-login/
• https://nvd.nist.gov/vuln/detail/cve-2026-87902
• https://www.bleepingcomputer.com/news/security/hackers-start-exploiting-critical-wordpress-flaw-for-code-execution/
• https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp
• https://github.com/ressl/cve-2026-87902-poc

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti