Il probing di WordPress CVE-2026-87902 è iniziato poche ore dopo la correzione

Gli attaccanti hanno iniziato a sondare i siti WordPress per una vulnerabilità critica nota come CVE-2026-87902 meno di cinque ore dopo la pubblicazione della versione corretta, secondo un nuovo rapporto di Patchstack. Il difetto è un problema di local file inclusion non autenticato nel modo in cui WordPress risolve i template delle pagine, e riguarda le versioni core di WordPress dalla 4.7.0 alla 7.1.1. Una vulnerabilità di local file inclusion consente a un attaccante remoto di far leggere a un sito web un file che non dovrebbe, il che in questo caso può portare all'esecuzione di codice remoto in alcune condizioni. WordPress ha risolto il problema nella versione 7.1.2, con patch retroportate per i rami precedenti tra cui 7.0.6, 6.9.9, 6.8.10 e fino alla 4.7.37. La vulnerabilità ha un punteggio di 9.2 sulla scala CVSS, è non autenticata e Patchstack indica il suo stato di sfruttamento come probing attivo osservato.

La vulnerabilità risiede nel modo in cui WordPress costruisce un candidato di template di pagina da un parametro URL chiamato pagename. Dave Jong, responsabile della ricerca sulla sicurezza di Patchstack, spiega che il problema principale è un path traversal che porta a local file inclusion. Nel traffico normale, un URL come /?page_id=1&pagename=about indica a WordPress quale pagina mostrare. Un attaccante può invece usare un valore pagename appositamente creato che inizia con templates%252f seguito da sequenze codificate di dot-dot-slash. La doppia codifica è importante: WordPress esegue prima lo slug attraverso un sanitizzatore che rimuove i punti letterali e taglia in corrispondenza delle barre letterali, ma conserva gli ottetti codificati in percentuale. Successivamente, get_page_template() decodifica quegli ottetti e il traversal risale fuori dalla directory del tema per includere un file arbitrario. L'attaccante deve anche fornire un page_id valido che corrisponda a una pagina reale, perché altrimenti WordPress restituisce un 404 prima che venga raggiunto il percorso di codice vulnerabile.

Patchstack afferma che il primo tentativo di probing è arrivato nei suoi log alle 17:44 UTC del 22 settembre 2026, meno di cinque ore dopo il rilascio di WordPress 7.1.2. I payload corrispondono esattamente alla codifica che la patch affronta, il che suggerisce che chi li ha creati stesse lavorando dal diff piuttosto che da una scoperta indipendente. Finora, ogni richiesta osservata punta l'inclusione verso un normale file core di WordPress: wp-links-opml.php, wp-includes/functions.php o wp-cron.php. Nessuno di questi file dà qualcosa a un attaccante da solo, ma funzionano come un test economico sì-o-no. Ad esempio, wp-links-opml.php emette un documento OPML distintivo, quindi vedere quell'output da un normale URL di pagina conferma che l'inclusione è riuscita. Patchstack descrive questo come ricognizione, non consegna di payload: qualcuno sta costruendo una lista di host sfruttabili. Il passo più pericoloso, puntare lo stesso trucco a un file come pearcmd.php su un server con register_argc_argv abilitato, non è ancora apparso nei dati di Patchstack, ma l'azienda si aspetta che segua una volta che i risultati della scansione saranno disponibili.

Le richieste osservate condividono due dettagli rivelatori. Primo, sono doppiamente codificate a livello HTTP, motivo per cui nei log appare %252e%252e invece di una semplice sequenza ../. Patchstack afferma che questo rende %252e%252e una stringa a basso rumore da cercare. Secondo, ogni richiesta abbina pagename a page_id, perché il traversal da solo non basta a raggiungere il codice vulnerabile. Il valore pagename inizia con templates%252f, continuando una directory reale che inizia con page- prima di risalire fuori dal tema. Patchstack ha visto la profondità del traversal variare da tre a sette livelli, probabilmente per adattarsi a diverse configurazioni di installazione, e sia codifiche esadecimali maiuscole che minuscole. Le richieste arrivano tramite GET e POST, perché WordPress legge pagename dal corpo POST con preferenza rispetto alla query string. Vanno anche direttamente a /index.php oltre che alla radice del sito. L'attività proveniva da un piccolo cluster di indirizzi di origine che colpivano più siti protetti, con la maggior parte del volume concentrata in due indirizzi IPv4 vicini, 169.58.48.193 e 169.58.48.195, e un po' di traffico IPv6 da 2001:df1:e8c0::106b. La maggior parte delle richieste portava uno user agent Go-http-client/1.1, con una quota minore che usava stringhe di browser falsificate. L'attività ha raggiunto il picco nella prima ora e poi è diminuita, il che secondo Patchstack è la forma tipica di una scansione opportunistica attraverso una lista di host preparata piuttosto che di una campagna mirata.

Patchstack afferma che i suoi clienti sono protetti da una regola RapidMitigate, una regola di sicurezza che blocca automaticamente i pattern di attacco noti per i siti protetti, ma per tutti gli altri la soluzione è aggiornare a WordPress 7.1.2 o alla versione corretta del proprio ramo. WordPress ha retroportato la correzione fino alla 4.7.37, quindi ogni ramo interessato ha una versione corretta e un sito più vecchio può adottarla senza un salto di versione principale. I proprietari dei siti possono verificare due precondizioni dal write-up originale prima di aggiornare: se il tema attivo ha una directory page- di primo livello e se PHP ha register_argc_argv abilitato. Se non è possibile aggiornare immediatamente, rifiutare le sequenze di traversal nel parametro pagename è un rimedio temporaneo efficace perché uno slug di pagina reale non ne contiene mai una. Per cercare nei log esistenti, Patchstack elenca gli indicatori a più alto segnale: un parametro pagename contenente %252e%252e nella query string o nel corpo POST, un valore pagename che inizia con templates%252f o un altro nome di directory page-, pagename e page_id che appaiono insieme sulla radice del sito o su /index.php, e output OPML o qualsiasi altro output inatteso di file core restituito da un normale URL di pagina. L'ultimo indica se una sonda ha avuto successo: una risposta 200 che trasporta OPML dove ci sarebbe dovuta essere una pagina significa che l'inclusione ha funzionato su quell'host, e il sito dovrebbe trattarlo come una finestra di vulnerabilità confermata piuttosto che come un tentativo bloccato. I siti esposti prima della patch o della mitigazione dovrebbero rivedere i log storici su questa base e controllare file inattesi o modificati.

La cronologia di Patchstack mostra che WordPress 7.1.2 e l'advisory GHSA-7hp8-65ch-5whp sono stati pubblicati il 22 settembre 2026. La vulnerabilità è stata aggiunta al database di Patchstack e una regola RapidMitigate è stata distribuita ai siti protetti lo stesso giorno. Il primo tentativo di sfruttamento è stato osservato e bloccato alle 17:44 UTC, e l'attività più recente al momento della scrittura era alle 19:51 UTC. Patchstack continua a monitorare un passaggio dalle sonde su file core a obiettivi di inclusione che facciano effettivamente qualcosa, e afferma che aggiornerà se ciò cambia. Per i proprietari di siti su hosting WordPress gestito come AEU Hosting, gli aggiornamenti core e il monitoraggio di sicurezza a livello di server possono accorciare la finestra tra il rilascio di una patch e la sua applicazione, che è esattamente ciò che riduce l'esposizione a sonde rapide come questa.