cve-2026-87902-detection

Toolkit di rilevamento e laboratorio riproducibile per CVE-2026-87902, un path traversal non autenticato in WordPress. Include un checker remoto, un analizzatore di IoC, regole Sigma e un banco di prova Docker.

1. Il banco di prova

Tre istanze WordPress su 127.0.0.1, che isolano ogni fattore del verdetto.

8092 è la più istruttiva : stesso core vulnerabile di 8091, ma manca il prerequisito del tema. È ciò che dimostra che un triage basato sulla sola versione sovrastima l'esposizione. Il tema è l'unica variabile tra 8091 e 8092, la correzione l'unica tra 8091 e 8093 : tutte e tre includono lo stesso tipo di contenuto personalizzato (provision/mu-plugins/00-lab-cpt.php) e la stessa sonda di stato della richiesta (10-lab-debug.php, header X-Lab-* che espongono is_page(), il valore di pagename visto dal loader e il template infine incluso).

Dove recuperare i log

L'immagine Docker ufficiale fa puntare /var/log/apache2/access.log a /dev/stdout : i log escono sullo stdout del container, non in un file.

Su un server classico : /var/log/apache2/access.log, /var/log/nginx/access.log, o /home/*/logs/ presso la maggior parte degli hosting condivisi. Il formato deve includere la query string — %r o il formato combined la includono, un LogFormat basato su %U la perde, e senza di essa nessun rilevamento è possibile.

2. Il controllore — check/wp-ghsa-7hp8-check.py

Da Internet, senza accesso al server. Nessun payload, nessun traversal, nessuna scrittura. Per ogni host : rilevamento WordPress, versione incrociata su cinque fonti (meta generator, feed RSS, wp-links-opml.php, readme.html, ?ver= delle risorse del core), tema attivo, e sondaggio della directory page-*.

« AFFETTO » significa che il codice vulnerabile è presente, non che un attaccante possa eseguire codice. Vedi docs/ANALYSIS.md.

--transport browser (predefinito) pilota il Google Chrome installato ; le sotto-richieste partono da un fetch() eseguito dentro la pagina ed ereditano il suo stack TLS, il suo ordine di header HTTP/2 e i suoi cookie, il che evita di essere filtrati da un CDN prima che l'URL venga letto. --transport direct utilizza solo la libreria standard. --scheme http|https evita il fallback https → http, che altrimenti lascia una riga 400 con un ClientHello TLS grezzo nel log del target.

Ogni richiesta è timestampata al millisecondo in un log JSONL : identificatore di sessione, numero di richiesta, fase, URL, stato, dimensione, durata, IP di uscita, marker. Il marker SECAUDIT/<nonce> parte come header X-Security-Audit e come suffisso dell'User-Agent — aggiunto, mai sostituito, per restare visibile in un access log standard senza rompere la firma del browser. Personalizzabile tramite --marker.

Nessun oracolo remoto. L'opzione --probe-inclusion effettua un confronto differenziale su target inerte (wp-includes/version.php, già caricato al bootstrap : require_once ne farebbe un no-op integrale). Su un'installazione standard restituisce NOT_REACHABLE anche su un core vulnerabile, con risposte identiche all'ottetto tra istanza corretta e non corretta. Non è un limite dello strumento : WordPress risponde 404 prima di consultare la gerarchia dei template. Dimostrazione numerica in docs/ANALYSIS.md, sezione 3.

3. Rilevamento e IoC

La regola strutturale

Una regex letterale del tipo pagename=.*%2e%2e%2f si aggira cambiando il case (%2E), codificando una volta in più (%252e), o mescolando letterale e codificato (templates/..%2f../). Qualsiasi lista di pattern è incompleta per costruzione.

Si parte quindi dal codice, non dalla scrittura dell'attaccante :

1. pagename subisce al massimo due decodifiche prima di raggiungere il disco — quella di PHP sulla query string, poi l'urldecode() esplicito di get_page_template().
2. Per uscire dalla directory del tema, il percorso passato a file_exists() deve contenere un componente ... Sotto Linux, la directory padre si scrive esattamente sui due byte 0x2E 0x2E ; non esiste nessun'altra rappresentazione a livello del filesystem.

Quindi : decodificare fino al punto fisso e testare a ogni livello. È un sovrainsieme stretto di ciò che fa WordPress — aggiungere uno strato di codifica non fa che spostare la corrispondenza di un livello, che attraversiamo comunque.

Regole Sigma in detect/sigma-wp-ghsa-7hp8.yml. Sigma non sapendo decodificare ricorsivamente, esse enumerano i livelli da 0 a 3 : è un'approssimazione assunta, per il triage di primo livello. Ripassare le corrispondenze nell'analizzatore per decidere.

Limiti — da conoscere prima di fidarsene

• POST. WP::parse_request() legge $_POST prima di $_GET. pagename può quindi arrivare in un corpo di richiesta, assente da qualsiasi access log. Copertura necessaria a livello WAF o ModSecurity, sul corpo.
• Formato del log. Senza query string registrata, nulla è rilevabile.
• Tentativo, non successo. Un 404 non attesta un fallimento su tutte le configurazioni.

Nessuna regola su access log copre il primo punto. È un limite del supporto, non della regola — ma deve essere noto prima di annunciare una copertura completa.

Validare il proprio rilevamento

offensive/generate-traces.py riproduce 12 diverse scritture dello stesso payload (letterale, codifica singola/doppia/tripla, case alto e basso, mescolanze, sovra-codifica UTF-8, punto-spazio) più 7 richieste legittime che vi assomigliano (slug con punti, wp-includes in uno slug, permalink con data, percento codificato).

Non ottiene nulla : non esiste un exploit remoto per questo vettore su un'installazione standard. Produce tracce — è tutto il suo scopo.

Atteso, e verificato da make test su log Apache reali : 12 payload rilevati su 12 (11 CRITICAL, la sovra-codifica in MEDIUM perché non è sfruttabile sotto Linux), 0 alert sulle 7 richieste legittime, e rilevamento effettivo a tre livelli di decodifica diversi.

Target limitato al banco locale ; qualsiasi altro richiede --i-have-authorization.

4. Remediation

1. Aggiornare alla versione corretta del proprio branch — 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, … fino a 4.7.37. Matrice completa nel controllore.
2. register_argc_argv = Off nel php.ini del SAPI web ; disinstallare PEAR se inutilizzato — è il pivot inclusione → esecuzione citato dall'avviso.
3. open_basedir limitato alla radice del sito : confina qualsiasi inclusione locale.
4. Distribuire le regole di cui sopra, coprendo anche il corpo delle richieste POST.

5. Affidabilità

make test è la condizione di pubblicazione : matrice dei 25 branch dell'avviso (inclusi i tranelli di confronto — 6.8.9 < 6.8.10 numericamente, pre-versioni, branch fuori matrice), controllore contro le tre istanze, e regola IoC validata su log reali. L'asserzione NOT_REACHABLE della sonda vi è fissata volontariamente : se si rompe, è il comportamento che è cambiato e l'analisi deve essere ripresa.

Quadro d'uso

Da utilizzare solo su asset di cui si è responsabili, o sotto mandato scritto. Il banco ascolta solo su 127.0.0.1 ; le istanze vulnerabili non devono mai essere esposte. La sonda 10-lab-debug.php divulga percorsi del server : è riservata al banco.