Gli attaccanti trasformano una falla nei template di WordPress in esecuzione di codice da remoto in poche ore

Una vulnerabilità critica nella gestione dei template di pagina di WordPress è già sfruttata contro siti esposti. La vulnerabilità, tracciata come CVE-2026-87902, consente ad attaccanti non autenticati di includere file PHP leggibili situati al di fuori delle directory del tema attivo, in determinate condizioni di distribuzione.

La vulnerabilità può essere sfruttata per passare dall’inclusione di file locali all’esecuzione di codice da remoto. Gli attacchi osservati utilizzano l’utility PEAR pearcmd.php per scrivere contenuti PHP controllati dagli attaccanti sui server vulnerabili.

Patchstack ha rilevato tentativi di sfruttamento entro poche ore dalla divulgazione pubblica. Secondo quanto riportato, entro il 23 settembre la campagna è passata dalla ricognizione alla compromissione attiva; in seguito, il traffico degli attacchi è aumentato fino a superare di oltre dieci volte il volume iniziale e si è esteso a un numero molto maggiore di siti.

La risoluzione dei template esce dalle directory del tema attivo

CVE-2026-87902 è una vulnerabilità di attraversamento dei percorsi nella logica utilizzata da WordPress per selezionare i template di pagina. Un attaccante esterno può influenzare get_page_template() in modo da farlo puntare a un file .php locale scelto dall’attaccante e leggibile, situato al di fuori delle directory previste per il tema child o parent.

L’attacco non funziona contro tutte le installazioni di WordPress. Devono verificarsi diverse condizioni:

• La directory di livello superiore del tema parent o child attivo deve iniziare con page-.
• Deve esistere un file PHP locale adatto, leggibile dall’account del server web.
• Il percorso vulnerabile di risoluzione dei template deve essere raggiungibile.
• Il server e il tema devono soddisfare ulteriori prerequisiti di WordPress affinché l’inclusione vada a buon fine.

Il requisito relativo al nome della directory spiega perché la struttura del tema sia importante. Tra i temi potenzialmente interessati figurano Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney. La loro sola presenza non dimostra che un sito sia sfruttabile: gli amministratori devono valutare anche la struttura delle directory attive, l’ambiente PHP, i permessi e i file locali disponibili.

Alla vulnerabilità sono stati assegnati due diversi livelli di gravità nei dati disponibili. SecurityWeek riporta un punteggio CVSS di 9,2, citando WordPress e Patchstack. Un record verificato separato assegna un punteggio CVSS di 8,1 con il vettore CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

Entrambe le valutazioni riflettono conseguenze potenzialmente gravi per la riservatezza, l’integrità e la disponibilità. Il vettore 8.1 tiene inoltre conto dell’elevata complessità dell’attacco: lo sfruttamento non richiede autenticazione ed è accessibile dalla rete, ma dipende da molteplici condizioni ambientali.

PEAR fa da ponte tra l’inclusione di file e l’esecuzione di codice

Gli attacchi osservati finora prendono di mira pearcmd.php, un componente a riga di comando associato al sistema di gestione dei pacchetti PEAR di PHP. La sua disponibilità può offrire agli attaccanti un percorso dall’inclusione locale di file PHP all’esecuzione di comandi.

Quando l’opzione PHP register_argc_argv è abilitata, i dati forniti nella richiesta possono essere esposti tramite variabili relative agli argomenti. Gli attaccanti possono combinare questo comportamento con l’inclusione di pearcmd.php, abusando dell’utility per scrivere contenuti PHP sul server. L’esecuzione del file appena creato completa la catena che porta all’RCE.

L’operazione descritta si articola in tre fasi:

1. Gli attaccanti verificano se un’installazione di WordPress è vulnerabile all’attraversamento dei percorsi dei template.
2. Cercano pearcmd.php o tentano di includerlo.
3. Se sono presenti le condizioni necessarie, utilizzano le funzionalità di PEAR per creare codice PHP ed eseguirlo.

Questa distinzione è importante durante la risposta agli incidenti. Una richiesta che verifica i percorsi dei template può indicare attività di scansione, mentre la creazione riuscita di un file o la successiva esecuzione di codice PHP segnalano una probabile compromissione.

Secondo quanto riportato, l’immagine Docker ufficiale di PHP è interessata dalle condizioni ambientali rilevanti. Anche le configurazioni predefinite di cPanel risultano interessate quando utilizzano versioni di PHP precedenti alla 8.5. In entrambi i casi, l’esposizione effettiva dipende comunque dai prerequisiti del tema WordPress e del server.

L’analisi pubblica della patch potrebbe aver accelerato lo sfruttamento

Patchstack ha valutato che la codifica utilizzata nei primi payload corrispondesse strettamente alla modifica del codice introdotta per correggere la vulnerabilità. Questo fa pensare che gli attaccanti abbiano analizzato pubblicamente le differenze della patch e le abbiano rapidamente trasformate in traffico di exploit funzionante.

Non è stato identificato alcun attore specifico. Le prime richieste provenivano da un piccolo gruppo di indirizzi IP, ma non sono stati resi disponibili indirizzi, domini, hash di file, campioni di payload o altri indicatori atomici.

L’attività iniziale si è concentrata soprattutto sull’individuazione delle installazioni vulnerabili. Entro il 23 settembre, Patchstack osservava compromissioni attive, non più soltanto attività di ricognizione. In seguito, il traffico ha superato di oltre dieci volte il volume della prima serata e ha raggiunto un insieme di siti molto più ampio.

Sono inoltre disponibili strumenti di scansione pubblici, che riducono l’impegno necessario per individuare installazioni con configurazioni potenzialmente vulnerabili. I difensori non possono quindi contare sul numero di prerequisiti per mantenere il problema poco visibile.

WordPress 7.1.2 chiude il percorso vulnerabile

WordPress ha corretto il problema nella versione 7.1.2 e ha distribuito la correzione anche nei rami supportati fino alla versione 4.7.x. Non è disponibile il numero esatto di versione di ogni backport corretto.

Gli amministratori dovrebbero eseguire l’aggiornamento a WordPress 7.1.2 oppure installare la release corretta relativa al ramo attualmente utilizzato. Le modifiche alla configurazione possono ridurre l’esposizione, ma non sostituiscono l’applicazione della patch di WordPress.

I controlli prioritari dovrebbero includere:

• Individuazione dei temi parent e child attivi i cui nomi di directory di livello superiore iniziano con page-.
• Verifica dei siti che utilizzano Twenty Twelve, Twenty Fourteen, Neve, Hestia o Sydney.
• Verifica dell’esistenza di pearcmd.php e della sua leggibilità da parte dell’account del server web.
• Controllo dell’abilitazione di register_argc_argv e sua disabilitazione o limitazione, quando possibile a livello operativo.
• Verifica dei permessi sui file PHP locali, compresi quelli situati al di fuori delle directory dei temi.
• Verifica delle distribuzioni ufficiali di PHP basate su Docker e dei sistemi cPanel che eseguono versioni di PHP precedenti alla 8.5.

La rimozione dell’esposizione di PEAR o la modifica di register_argc_argv può interrompere la catena di sfruttamento descritta. Queste misure non correggono il problema di fondo relativo all’attraversamento dei percorsi dei template di pagina.

I log devono distinguere la scansione dalla compromissione riuscita

Nei log del server web e di WordPress è necessario cercare richieste insolite che coinvolgano l’attraversamento dei percorsi dei template di pagina, tentativi di risoluzione di file al di fuori delle directory dei temi e riferimenti a pearcmd.php.

I difensori dovrebbero inoltre cercare la sequenza descritta nella campagna osservata: un test iniziale della vulnerabilità, un tentativo di inclusione di PEAR e una richiesta successiva che esegue il codice PHP appena scritto. I file PHP imprevisti richiedono un’indagine immediata, soprattutto quando la loro creazione segue richieste sospette di risoluzione dei template.

Se gli elementi raccolti indicano che la catena ha raggiunto la fase finale, gli amministratori dovrebbero considerare l’host compromesso. La risposta dovrebbe includere la conservazione dei log pertinenti, l’isolamento del sistema interessato quando appropriato e l’analisi della presenza di:

• File PHP appena scritti o modificati.
• Web shell o altri meccanismi di persistenza.
• Comandi eseguiti con i privilegi dell’account del server web.
• Accesso a segreti o credenziali di WordPress.
• Connessioni ad altri servizi interni.
• Segnali di furto di credenziali o movimento laterale.

La semplice reinstallazione di un core WordPress pulito potrebbe non rimuovere i file creati altrove sull’host.

Lo stato nella CISA KEV resta sconosciuto

Non è disponibile alcuna conferma della presenza di CVE-2026-87902 nel catalogo CISA Known Exploited Vulnerabilities né di una scadenza federale per la correzione. Non è stato segnalato nemmeno alcun indicatore di utilizzo da parte di ransomware.

L’assenza di informazioni nel catalogo non cambia gli elementi operativi disponibili: lo sfruttamento è stato osservato entro poche ore dalla divulgazione e le compromissioni attive sono state segnalate entro il 23 settembre. Gli amministratori dovrebbero dare priorità all’applicazione delle patch sulla base di questa attività, senza attendere l’inserimento nel catalogo KEV.