Da cinque giorni migliaia di siti WordPress in Europa sono sotto scansione automatica. Il bersaglio è CVE-2026-87902, una falla nel Core di WordPress che permette a un attaccante non autenticato di far includere al motore di risoluzione dei template un file PHP arbitrario presente sul server, con possibile esecuzione di codice da remoto. Il 25 settembre CISA l’ha inserita nel catalogo Known Exploited Vulnerabilities, fissando come scadenza per la correzione il 28 settembre, cioè domani. Nel frattempo i tracker di sicurezza si dividono su quanto sia davvero grave: c’è chi parla di CVSS 9,2 e chi si ferma a 8,1. In mezzo, migliaia di amministratori di siti italiani ed europei che devono decidere in fretta cosa fare.
Cos’è CVE-2026-87902: la falla nel cuore di WordPress
A differenza della stragrande maggioranza delle vulnerabilità che colpiscono WordPress ogni anno, CVE-2026-87902 non riguarda un plugin di terze parti ma il Core del CMS, il codice che gira identico su ogni installazione. Il problema si trova nella funzione get_page_template(), quella che WordPress usa per decidere quale file caricare quando un utente visita una pagina che usa un template personalizzato. Secondo l’analisi tecnica pubblicata da Patchstack, un attaccante può manipolare questo meccanismo per far includere un file PHP leggibile che si trova fuori dalla cartella del tema attivo.
La cosa che ha fatto scattare l’allarme è che l’exploit non richiede login, cookie di sessione o credenziali di alcun tipo. Basta che il sito sia raggiungibile pubblicamente e che risponda alle versioni di WordPress comprese tra la 4.7.0 e la 7.1.1, cioè una finestra che coprirebbe, sulla carta, quasi un decennio di release. Il team di WordPress ha rilasciato un avviso di sicurezza che descrive esattamente questo scenario: un attaccante senza autenticazione che fa risolvere a un percorso di file scelto da lui la generazione del template di pagina, con esecuzione di codice possibile quando si verificano determinate condizioni lato server, secondo quanto riportato da The Hacker News.
La catena d’attacco: da pearcmd.php all’esecuzione di codice
Un file di inclusione da solo non basta a compromettere un server. Serve un file PHP già presente e leggibile su cui l’inclusione possa agganciarsi, e qui entra in gioco un componente che quasi nessun amministratore ricorda di avere installato: pearcmd.php, lo script a riga di comando di PEAR, il gestore di librerie PHP che molte distribuzioni Linux e molti pannelli di hosting installano di default insieme a PHP.
Il ruolo di pearcmd.php nell’attacco
Gli attaccanti hanno cominciato a invocare direttamente pearcmd.php per scrivere sul disco un file PHP con contenuto scelto da loro. Una volta che quel file esiste, la falla in get_page_template() permette di farlo includere ed eseguire dal motore WordPress, chiudendo il cerchio tra scrittura arbitraria e esecuzione di codice. Patchstack descrive questo comportamento come particolarmente rilevante quando l’impostazione PHP register_argc_argv è attiva, una configurazione non rarissima su hosting condivisi economici, molto diffusi anche in Italia tra piccole attività commerciali e blog personali.
Le condizioni che trasformano l’inclusione in RCE
Non tutti i siti vulnerabili alla sola inclusione arrivano fino all’esecuzione di codice. Perché ciò accada, secondo la ricostruzione tecnica circolata tra i tracker, devono verificarsi due condizioni insieme: il tema attivo, o un suo tema figlio, deve avere una cartella di primo livello con un nome che comincia con “page-” (un caso comune è “page-templates”, usato da moltissimi temi commerciali), e deve esistere un file PHP leggibile che l’attaccante possa referenziare. È una combinazione che tocca una fetta consistente dei temi WordPress oggi in uso, il che spiega perché i tracker abbiano reagito così in fretta.
Cronologia: sei giorni da probing a inserimento nel KEV
La velocità con cui questa vicenda si è mossa dice molto sullo stato attuale della sicurezza WordPress. Patchstack ha pubblicato il suo primo report il 22 settembre alle 11:01 UTC, segnalando che gli attaccanti avevano già iniziato a sondare i siti poche ore dopo la diffusione della patch, un dettaglio che riduce drasticamente la finestra utile per aggiornare in sicurezza prima che qualcuno tenti lo sfruttamento.
| Data | Evento |
|---|---|
| 22 settembre 2026 | Patchstack pubblica il primo report, rilevate le prime scansioni verso pearcmd.php poche ore dopo la patch |
| 23 settembre 2026 | Aggiornamento Patchstack: gli attaccanti passano dal semplice probing a tentativi di esecuzione di codice |
| 24 settembre 2026 | SecurityWeek e The Hacker News riprendono la notizia a livello internazionale |
| 25 settembre 2026 | CISA inserisce CVE-2026-87902 nel catalogo Known Exploited Vulnerabilities (KEV) |
| 26 settembre 2026 | Security Affairs e CSO Online confermano l’inserimento nel KEV e riepilogano la vicenda |
| 27 settembre 2026 | Data di questo articolo, la scadenza CISA cade il giorno successivo |
Da segnalare che la finestra tra disclosure e primo abuso pubblico è stata, in questo caso, di poche ore, non di settimane come accade spesso con vulnerabilità meno note. È lo schema tipico delle falle che toccano software installato su un numero enorme di server: più bersagli disponibili significa più incentivo per chi scansiona in automatico Internet in cerca di installazioni non aggiornate.
CVSS 9,2 o 8,1? Il disaccordo tra i tracker di sicurezza
Uno degli aspetti più interessanti di questa vicenda, dal punto di vista di chi segue il settore, è che i principali tracker non sono d’accordo sulla gravità esatta della falla. Patchstack, SecurityWeek, Security Affairs e The Hacker News riportano tutti un punteggio CVSS di 9,2, classificato come Critico. KazaSec e Ionix, invece, citano un punteggio NVD di 8,1, classificato come Alto.
| Fonte | Punteggio CVSS | Gravità assegnata |
|---|---|---|
| Patchstack | 9,2 | Critica |
| SecurityWeek | 9,2 | Critica |
| Security Affairs | 9,2 | Critica |
| The Hacker News | 9,2 | Critica |
| KazaSec | 8,1 (fonte NVD) | Alta |
| Ionix | 8,1 (fonte NVD) | Alta |
Non è un dettaglio accademico. Molte aziende usano soglie CVSS automatiche per decidere se una patch va applicata entro 24 ore o entro un mese: se il proprio scanner di vulnerabilità legge il punteggio NVD da 8,1, un ticket rischia di finire in una coda con priorità più bassa rispetto a quanto la situazione reale richiederebbe. La spiegazione più probabile del divario è che la valutazione da 9,2 tenga conto dello scenario con esecuzione di codice completa, mentre quella da 8,1 pesi maggiormente le precondizioni necessarie (tema con cartella “page-“, file PHP leggibile presente) che non si verificano su ogni installazione.
Versioni a rischio e patch disponibili
WordPress ha risposto con un pacchetto di aggiornamenti che copre praticamente tutti i rami ancora supportati, incluso quello legacy che risale a WordPress 4.7. È una scelta che riflette quanto sia diffusa la base installata più vecchia, ancora oggi presente su un numero non trascurabile di siti che nessuno aggiorna da anni.
| Ramo WordPress | Stato prima della patch | Versione corretta |
|---|---|---|
| Ramo principale | Vulnerabile fino alla 7.1.1 | 7.1.2 |
| Ramo 7.0.x | Vulnerabile | 7.0.6 |
| Ramo 6.9.x | Vulnerabile | 6.9.9 |
| Ramo 6.8.x | Vulnerabile | 6.8.10 |
| Ramo legacy (dalla 4.7.0) | Vulnerabile | 4.7.37 |
Per chi gestisce più installazioni, il primo passo pratico non è aspettare l’aggiornamento automatico ma verificare subito lo stato reale dei siti in produzione. Alcuni comandi utili via WP-CLI o accesso SSH al server:
wp core version
wp core check-update
find / -type f -iname "pearcmd.php" 2>/dev/null
wp core update --version=7.1.2
wp core verify-checksumsSe il comando find individua un pearcmd.php raggiungibile dalla webroot o comunque eseguibile via HTTP, la prassi consigliata dai tracker è rimuoverlo o bloccarne l’accesso via regola del server web, indipendentemente dal fatto che il Core sia già stato aggiornato: è una superficie di attacco che in molti setup di hosting non serve a nulla per il funzionamento del sito.
CISA KEV e la scadenza del 28 settembre: cosa significa davvero
L’inserimento nel catalogo Known Exploited Vulnerabilities di CISA, avvenuto il 25 settembre, porta con sé un obbligo formale solo per le agenzie federali civili statunitensi, che devono applicare la correzione entro il 28 settembre. Per tutti gli altri, comprese le organizzazioni italiane ed europee, la scadenza non ha valore legale diretto, ma nella pratica funziona come un segnale molto più forte di qualunque bollettino ordinario: quando CISA inserisce una falla nel KEV, significa che ha prove di sfruttamento attivo, non solo di una possibilità teorica.
Molti team di sicurezza europei, incluse diverse società di hosting italiane, trattano comunque le scadenze KEV come riferimento operativo interno, anche in assenza di un obbligo normativo locale, semplicemente perché il catalogo è aggiornato solo su base di evidenza concreta di attacco e non su semplice teoria.
Impatto sul mercato: perché una falla nel Core pesa più delle altre
Nella maggior parte dei casi, le vulnerabilità critiche che riguardano WordPress nascono in un plugin o in un tema di terze parti, con un impatto che resta confinato a chi usa quello specifico componente. CVE-2026-87902 è diversa perché vive nel Core, il codice comune a ogni installazione indipendentemente dai plugin scelti. Questo cambia il calcolo del rischio per tre attori del settore: le agenzie che gestiscono decine o centinaia di siti clienti, i provider di hosting che offrono WordPress preinstallato, e i grandi network editoriali che usano WordPress come CMS principale.
Per le agenzie web italiane, spesso responsabili di manutenzione su portafogli di siti eterogenei con temi diversi tra loro, il problema pratico è verificare quali temi tra quelli in uso abbiano effettivamente una cartella che inizia con “page-“: non è un controllo automatico che molti pannelli di gestione offrono di default, quindi va fatto manualmente o con uno script dedicato, sito per sito.
Il contesto italiano ed europeo: PA, PMI e un avviso ancora assente
WordPress è la piattaforma di gran lunga più usata da piccole imprese, professionisti, associazioni e anche da una parte della pubblica amministrazione locale in Italia, spesso attraverso agenzie web esterne che gestiscono il sito senza un presidio di sicurezza continuo. Al momento in cui scriviamo, il 27 settembre, non risulta un avviso pubblico dedicato a CVE-2026-87902 da parte di CERT-AgID o dell’Agenzia per la Cybersicurezza Nazionale: non significa che la falla non sia rilevante per il territorio italiano, significa solo che l’informazione, per ora, circola soprattutto attraverso i canali internazionali citati in questo articolo.
È lo scenario in cui gli attacchi automatizzati colpiscono più duramente: non tanto le grandi organizzazioni con un team di sicurezza dedicato, che aggiornano in poche ore, quanto la lunga coda di siti piccoli e medi gestiti senza monitoraggio attivo, che restano vulnerabili per settimane o mesi dopo la pubblicazione della patch.
Confronto con le altre falle critiche di settembre 2026
Settembre 2026 è stato un mese affollato per chi segue le vulnerabilità critiche lato server. Solo nelle ultime settimane si sono susseguiti l’RCE su F5 BIG-IP (CVE-2026-94127, CVSS 9,8), la falla su WSO2 legata al bypass JWT (CVE-2026-5430, CVSS 10.0), il path traversal critico su GitLab (CVE-2026-85706, CVSS 10.0) e il bug su Cisco Email Gateway (CVE-2026-76461, CVSS 9,8). Rispetto a tutti questi casi, CVE-2026-87902 si distingue per un motivo semplice: quelle vulnerabilità colpiscono software enterprise, tipicamente gestito da team IT dedicati con contratti di supporto attivi. WordPress Core, invece, gira ovunque, dal sito aziendale multinazionale al blog di quartiere gestito da un solo volontario.
La differenza si vede anche nella velocità di reazione. I fornitori enterprise pubblicano spesso avvisi dettagliati con indicatori di compromissione specifici. Nel caso WordPress, la difesa reale dipende in larga parte dagli aggiornamenti automatici in background che la piattaforma stessa esegue per i rilasci di sicurezza minori, un meccanismo che esiste da anni ma che non copre tutte le configurazioni, specie quando gli amministratori li hanno disattivati per timore di conflitti con temi o plugin personalizzati.
Contesto storico: le vulnerabilità di WordPress Core nel tempo
Le falle critiche che colpiscono direttamente il Core di WordPress, e non un plugin, sono storicamente rare rispetto al volume enorme di segnalazioni che riguarda l’ecosistema di estensioni di terze parti. Quando accadono, però, tendono a essere trattate con priorità massima dal team di sicurezza del progetto, proprio perché il potenziale di impatto è per definizione più ampio: non serve che un sito abbia installato un plugin specifico, basta che esegua WordPress.
La scelta di questa volta di backportare la correzione fino al ramo 4.7, una versione che risale a diversi anni fa, racconta bene quanto lunga sia la coda di installazioni che il progetto considera ancora attive e potenzialmente esposte. È una politica di supporto insolitamente estesa nel panorama del software open source, e riflette proprio la consapevolezza che moltissimi siti WordPress non vengono mai aggiornati oltre la versione con cui sono stati creati.
Come proteggersi subito: azioni immediate per amministratori e agenzie
Le priorità operative, in ordine, sono relativamente semplici da elencare anche se richiedono tempo da eseguire su un parco siti ampio. Primo, aggiornare immediatamente al ramo corretto (7.1.2, 7.0.6, 6.9.9, 6.8.10 o 4.7.37 secondo la versione in uso). Secondo, verificare la presenza di pearcmd.php raggiungibile pubblicamente e bloccarlo o rimuoverlo. Terzo, controllare se il tema attivo ha cartelle che iniziano con “page-” e, in caso positivo, monitorare i log del server per richieste anomale verso quei percorsi nei giorni successivi alla patch. Quarto, per chi gestisce hosting condiviso, verificare se register_argc_argv è attivo a livello di configurazione PHP e valutare se disattivarlo dove non serve.
Un controllo aggiuntivo utile è confrontare i checksum dei file core con quelli ufficiali, per escludere che un attaccante abbia già scritto file PHP malevoli nei giorni tra la disclosure e l’aggiornamento effettivo.
wp core verify-checksums --url=https://iltuosito.it
grep -r "eval(" wp-content/uploads/ --include="*.php" -l
tail -n 200 /var/log/apache2/access.log | grep -i "pearcmd"Cosa aspettarsi nelle prossime settimane: cinque previsioni
Sulla base di come si sono svolte vicende simili negli anni scorsi, ci sono alcuni scenari probabili per le prossime settimane. Primo, ci aspettiamo un picco di scansioni automatizzate proprio a partire dal 29 settembre, il giorno dopo la scadenza CISA, quando gli attaccanti proveranno a colpire tutto ciò che le agenzie federali statunitensi non hanno ancora corretto e, a cascata, tutti gli altri siti rimasti indietro.
Secondo, è probabile che alcuni ricercatori indipendenti pubblichino un proof of concept più dettagliato nelle prossime due o tre settimane, il che tipicamente fa aumentare ulteriormente il volume di scansioni opportunistiche. Terzo, diversi provider di hosting che offrono WordPress gestito probabilmente accelereranno l’introduzione di aggiornamenti forzati per i clienti che non hanno mai disattivato gli update automatici, proprio per limitare il danno reputazionale di un incidente di massa sulla propria infrastruttura. Quarto, ci aspettiamo che il divario tra il punteggio CVSS da 9,2 e quello da 8,1 si riduca con il tempo, quando NVD aggiornerà la propria valutazione alla luce delle conferme di esecuzione di codice arrivate da più fonti indipendenti. Quinto, è plausibile che questa vicenda rilanci la discussione, ricorrente da anni nella comunità WordPress, sul perché PEAR e pearcmd.php restino installati di default su tanti ambienti PHP quando la stragrande maggioranza dei siti non ne ha alcun bisogno.
Perché questa storia non finisce con la patch
Anche dopo che la maggior parte dei siti avrà applicato la correzione, resterà per mesi una coda di installazioni dimenticate, gestite da chi non controlla mai il pannello di amministrazione. È lì che si concentrerà il rischio reale nel medio termine, non tanto sui siti seguiti da agenzie o hosting gestito, quanto su quelli abbandonati a loro stessi. Per il settore, il caso CVE-2026-87902 è un altro promemoria di quanto la sicurezza di un ecosistema enorme come WordPress dipenda, più che dalla qualità della singola patch, dalla velocità con cui quella patch raggiunge davvero l’ultimo miglio di installazioni dimenticate su Internet.
Domande frequenti su CVE-2026-87902
Il mio sito WordPress è vulnerabile a CVE-2026-87902?
Se la versione di WordPress installata è compresa tra la 4.7.0 e la 7.1.1 e non è stata ancora aggiornata a 7.1.2, 7.0.6, 6.9.9, 6.8.10 o 4.7.37 in base al ramo, il sito è potenzialmente vulnerabile alla componente di inclusione file. Il rischio di esecuzione di codice completa dipende inoltre dal tema attivo e dalla presenza di pearcmd.php raggiungibile.
Serve essere autenticati per essere colpiti?
No. È questo che rende la falla particolarmente pericolosa: un attaccante non ha bisogno di alcuna credenziale, cookie di sessione o account sul sito per tentare lo sfruttamento.
Perché il CVSS varia tra 9,2 e 8,1 secondo la fonte?
Patchstack, SecurityWeek, Security Affairs e The Hacker News riportano 9,2 (Critico), mentre KazaSec e Ionix citano il punteggio NVD di 8,1 (Alto). La differenza sembra derivare da come viene pesato il fatto che l’esecuzione di codice completa richieda precondizioni specifiche sul tema installato, mentre l’inclusione file di base è sfruttabile più ampiamente.
Cos’è pearcmd.php e perché è coinvolto?
È lo script a riga di comando del gestore di pacchetti PEAR per PHP, spesso installato di default da molte distribuzioni Linux e pannelli di hosting anche quando non serve al funzionamento del sito. Gli attaccanti lo usano per scrivere sul disco un file PHP malevolo che viene poi incluso ed eseguito tramite la falla in WordPress.
La scadenza CISA del 28 settembre mi riguarda se non sono un’agenzia federale USA?
Non in senso legale. L’obbligo del catalogo KEV vale formalmente solo per le agenzie federali civili statunitensi. Nella pratica, però, l’inserimento nel KEV è un segnale che CISA ha prove concrete di sfruttamento attivo, quindi molte organizzazioni europee, incluse quelle italiane, lo trattano come priorità operativa anche senza obbligo normativo.
Esiste un avviso di CERT-AgID o ACN su questa falla?
Al momento della pubblicazione di questo articolo, il 27 settembre 2026, non risulta un avviso pubblico dedicato da parte di CERT-AgID o dell’Agenzia per la Cybersicurezza Nazionale. La situazione può evolvere nei prossimi giorni.
Come verifico se il mio tema ha la cartella a rischio?
Basta controllare, nella cartella del tema attivo (o del tema figlio, se ne usi uno), se esiste una sottocartella di primo livello con un nome che inizia con “page-“, ad esempio “page-templates”. È una struttura comune a molti temi commerciali, quindi vale la pena controllare anche se non si è sicuri di averla mai notata.
Aggiornare WordPress basta a mettermi in sicurezza?
L’aggiornamento del Core risolve la falla di inclusione file alla radice, ma se pearcmd.php è già raggiungibile pubblicamente resta comunque una superficie di attacco non necessaria. La raccomandazione dei tracker è aggiornare e, in aggiunta, bloccare o rimuovere l’accesso a pearcmd.php indipendentemente dallo stato della patch.
