CVE-2026-87902 un mese dopo: come verificare se WordPress è stato toccato dalla falla pearcmd.php

Un mese fa WordPress ha rilasciato la versione 7.1.2 per correggere CVE-2026-87902, un path traversal non autenticato nella risoluzione dei page template, con CVSS 9.2. Le analisi in inglese (Patchstack, Equixly, CrowdSec) sono uscite subito. Qui la traduciamo in procedura: cosa guardare nei log, cosa controllare in PHP, cosa disattivare se non si può aggiornare subito.

La falla in breve

Quando WordPress deve scegliere il template di una pagina, la funzione get_page_template() costruisce il nome del file a partire dal parametro pagename. Il bug: quel percorso salta il controllo validate_file() usato altrove per lo stesso tipo di nome file, per cui una sequenza di traversal doppiamente codificata (%252e%252e o simili) sopravvive alla sanificazione e viene poi decodificata da urldecode(), puntando a un file fuori dalla cartella del tema.

Da sola questa è una local file inclusion: legge o include un file PHP esistente sul server. Diventa esecuzione di codice remoto (RCE) solo se sono vere tre condizioni insieme, secondo l'analisi di Patchstack: il tema attivo (o parent theme) ha una cartella di primo livello che inizia per page-, sul server è presente e leggibile un file PHP "utile" — nella catena dimostrata pubblicamente, pearcmd.php di PEAR — e PHP gira con register_argc_argv attivo, condizione che espone la query string allo script incluso come $argv.

Versioni interessate: da 4.7.0 a 7.1.1. Corrette: 7.1.2, 7.0.6, 6.9.9, 6.8.10, con backport fino alla 4.7.37, tutte rilasciate il 22 settembre 2026.

Chi è esposto sul lato server

Due ambienti ricorrono in tutte le analisi: le immagini Docker ufficiali di PHP, dove non viene caricato un php.ini e il default compilato lascia register_argc_argv attivo, e le configurazioni cPanel classiche con PHP precedente alla 8.5. Fra i temi con struttura di cartelle compatibile risultano citati Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney.

Come leggere i log del server web

Patchstack ha documentato tre stadi di attacco, ciascuno con una firma di log diversa.

Stadio 1 — ricognizione. Richieste che includono un file core innocuo per vedere se il sito risponde in modo anomalo. I file più usati: wp-links-opml.php, wp-includes/feed-rss2.php, wp-cron.php, wp-includes/functions.php, wp-login.php, install.php. Pattern tipico:

GET /?page_id=<id>&pagename=templates%2f<traversal>wp-links-opml

Stadio 2 — verifica di pearcmd. La richiesta punta a uno di questi tre percorsi, che coprono la maggior parte delle distribuzioni e immagini container:

/usr/local/lib/php/pearcmd.php
/usr/share/php/pearcmd.php
/usr/share/pear/pearcmd.php

con un parametro +config-show in coda alla query string.

Stadio 3 — scrittura su disco. Stesso schema, ma con +config-create+<payload>+/tmp/<nome>.php: è la scrittura di un file PHP con contenuto controllato dall'attaccante.

Per cercare nei log Apache o Nginx, i due elementi da combinare sono: il parametro pagename con sequenze codificate (%2e%2e, %252e%252e, maiuscole o minuscole) e la compresenza del parametro page_id — che secondo Patchstack compare quasi sempre insieme, perché senza un ID pagina valido la richiesta restituisce un 404 e il codice vulnerabile non viene mai raggiunto. Un comando di base:

grep -E "pagename=.*(%2e%2e|%252e%252e)" access.log | grep "page_id="

Da affiancare a una ricerca specifica su pearcmd e su config-create nello stesso file di log. Vale la pena ricordare che gran parte del traffico osservato usa anche richieste POST, non solo GET, perché WordPress legge pagename dal corpo della richiesta in via preferenziale rispetto alla query string.

Se emergono riscontri positivi, il passo successivo è cercare file PHP non attesi in /tmp e /var/tmp: nomi osservati in giro includono wp-pear-rce-flag.php, poc87902.php e varianti con prefisso luci_ o zeta_ seguito da stringa casuale.

Controllare e disattivare register_argc_argv

Per sapere se la direttiva è attiva sul proprio ambiente, due vie:

php -i | grep register_argc_argv

oppure, per verificare la configurazione realmente usata dal web server (che può differire da quella della CLI), uno script PHP minimo richiamato via browser:

<?php echo ini_get('register_argc_argv');

Secondo la documentazione ufficiale di PHP, register_argc_argv ha valore predefinito "1" ed è modificabile solo a livello INI_PERDIR — quindi va impostata in php.ini, in un file .user.ini o nella configurazione del pool PHP-FPM della vhost, non in .htaccess. La stessa documentazione segnala che la direttiva è deprecata a partire da PHP 8.5.0.

Per disattivarla, in php.ini:

register_argc_argv = Off

seguito dal riavvio del servizio PHP-FPM o del web server, a seconda della SAPI in uso. Su un pool PHP-FPM dedicato al sito, lo stesso parametro può essere impostato nel file di pool (php_admin_value[register_argc_argv] = 0) senza toccare la configurazione globale del server.

Va detto chiaramente, come ripetuto da tutte le fonti consultate: disattivare questa direttiva interrompe solo la catena dimostrata via PEAR. Non corregge la falla di file inclusion di base, che resta sfruttabile per leggere file se esistono altri bersagli validi sul server. L'unica correzione reale resta l'aggiornamento a WordPress 7.1.2 o alla release corretta del proprio branch, verificabile con wp core version da riga di comando o da Bacheca → Aggiornamenti.

La scala del problema un mese dopo

Il report di CrowdSec, basato sull'osservazione della propria rete di sensori, ha registrato 30.813 indirizzi IP univoci che hanno inviato richieste corrispondenti al pattern di CVE-2026-87902 nei cinque giorni successivi al 23 settembre 2026, con 322.680 segnali totali nello stesso periodo. Lo stesso report segnala che il numero di sorgenti distinte è cresciuto di cento volte in cinque giorni, segno che lo sfruttamento è passato da pochi operatori a strumenti di scansione automatizzati in circolazione pubblica — compreso un template Nuclei dedicato.

Per chi gestisce più installazioni WordPress su server propri o in hosting condiviso, la lista di controllo pratica resta: aggiornare a 7.1.2 o superiore su ogni ambiente, incluse le copie di staging e le immagini container che non si auto-aggiornano; controllare se il tema attivo o il parent theme hanno una cartella che inizia per page-; verificare lo stato di register_argc_argv sull'ambiente PHP realmente usato dal sito, non solo da riga di comando; e, se il server ha subito tentativi di scrittura andati a buon fine, cercare file PHP sospetti in /tmp, /var/tmp e wp-content/uploads prima di considerare l'incidente chiuso.