Riepilogo

WordPress risolve un template di Pagina attraverso una catena che non dimostra mai che il file selezionato rimanga all'interno di una root del tema:

1. pagename e page_id sono variabili di query pubbliche che WP::parse_request() accetta da un corpo POST anonimo.
2. Un traversal con doppia codifica in pagename sopravvive alla sanitizzazione iniziale della query come ottetti %xx con escape (wp_basename() non riesce a vedere %2f come separatore, e sanitize_title_with_dashes() mantiene deliberatamente gli ottetti validi).
3. Un page_id valido seleziona poi una Pagina pubblicata reale, mentre il pagename malevolo rimane nell'oggetto query.
4. get_page_template() chiama successivamente urldecode() su quel valore e aggiunge un candidato come page-templates/../../../../../../../usr/local/lib/php/pearcmd.php alla gerarchia dei template.
5. locate_template() e il loader finale del template controllano solo l'esistenza, la leggibilità e il suffisso .php/.html — mai che il percorso canonico sia ancora all'interno di una root del tema consentita — e poi lo include.

Questo è una primitiva di inclusione locale di file remota non autenticata in WordPress Core. Sul runtime ufficiale testato (wordpress:php8.3-apache, che include PEAR e non carica alcun php.ini, quindi register_argc_argv è On), l'inclusione è stata concatenata attraverso pearcmd.php di PEAR: una prima richiesta anonima fa sì che config-create scriva PHP controllato dall'attaccante in /tmp, una seconda richiesta anonima include quel file e lo esegue come www-data.

La mancata contenimento del percorso in Core è la vulnerabilità. PEAR è solo una via dipendente dall'ambiente dall'inclusione all'esecuzione di codice — non è una dipendenza di WordPress e non è presente o utilizzabile in ogni deployment.

Causa principale

Posizioni del codice verificate (WordPress 7.0.2):

Precondizioni

La primitiva di inclusione standalone necessita di:

La fase PEAR dimostrata necessita inoltre di un pearcmd.php leggibile (più le sue dipendenze), register_argc_argv=On per il SAPI web, e una directory di output scrivibile. I file php.ini di produzione impostano register_argc_argv=Off; l'immagine testata non carica alcun php.ini, quindi si è applicato il default compilato (On). Questo è un limite importante sulla prevalenza della catena di esecuzione di codice dimostrata.

I temi inclusi Twenty Twenty-Three/Four/Five non forniscono nessuna directory page-* di primo livello, quindi il lab stock necessita del fixture descritto di seguito. I temi personalizzati possono legittimamente usare un layout page-templates/ (documentazione WordPress).

L'avviso registra dove queste condizioni si verificano nel software distribuito: la condizione del tema è soddisfatta dai temi legacy Twenty Twelve e Twenty Fourteen e da temi di terze parti come Neve, Hestia e Sydney, mentre la transizione PEAR si applica all'immagine Docker ufficiale di PHP e alle configurazioni cPanel predefinite che eseguono PHP precedente alla 8.5. (Twenty Twelve e Twenty Fourteen includono entrambi una directory page-templates/ di primo livello; le restanti affermazioni sono dell'avviso.) Questo repository non misura quanto spesso si applichi la catena completa.

Avvio rapido

cve-2026-87902.py richiede Python 3.6+ (solo libreria standard) e raggiunge il lab su http://127.0.0.1:8091 per impostazione predefinita. Output atteso:

Il codice di uscita è 0 in caso di successo e 1 altrimenti, quindi il PoC funziona anche come controllo di regressione/rilevamento.

Teardown: docker compose down -v.

Risultati verificati

Eseguito il 2026-09-22 contro questo lab (Docker 29.4, OrbStack, Apple silicon):

L'artefatto di prova è /flag, di proprietà di root e leggibile da tutti (root:root, mode 0444) all'interno del container. Dimostra l'esecuzione di PHP e l'accesso ai file come l'account del web server; non è un obiettivo di privilege escalation.

Come funziona la catena

Due POST anonimi. I valori di routing di WordPress viaggiano nel corpo del form, gli argomenti PEAR nella query string grezza (PHP divide la query string grezza sul carattere letterale + in argv e non decodifica URL i singoli argomenti):

Fase 1 — include pearcmd.php e scrive il payload:

Fase 2 — include il file generato ed esegue il suo PHP:

Dettagli che contano:

• Due livelli di codifica. Il corpo viene decodificato una volta da PHP in templates%2f%2e%2e%2f...; il sanitizer mantiene quegli ottetti, e solo la urldecode() tardiva di get_page_template() li trasforma in / e ...
• Prefisso page-. WordPress antepone page- al valore, quindi la directory fixture page-templates/ corrisponde al segmento iniziale templates.
• Suffisso .php forzato. Il candidato è page-<decoded>.php, motivo per cui il target è indicato senza suffisso (.../pearcmd, /tmp/wp-pear-rce-flag).
• POST, non GET. redirect_canonical() salta le richieste non-GET/HEAD, e il corpo del form consente alla query string di trasportare solo gli argomenti PEAR.
• Payload senza virgolette. wp_magic_quotes() viene eseguito anche su $_SERVER, quindi l'argv costruito dal server viene sottoposto a escape e PEAR normalizza successivamente i backslash. Il payload verificato usa chr() e non contiene caratteri di virgoletta. (Si riduce a <?=file_get_contents('/flag')?>.)
• Percorso root di config-create. PEAR rifiuta una root relativa (Root directory must be an absolute path beginning with "/"), quindi il payload viene iniettato come la root path stessa.
• Profondità. cve-2026-87902.py percorre i segmenti .. finché il traversal raggiunge il target (7 per il layout di questo lab, --depth per fissarlo).

Lab

lab/up.sh esegue tre passaggi ed è sicuro da rieseguire:

1. docker compose up -d --build --wait — wordpress:7.0.2-php8.3-apache fissato più mysql:8.4, porta 127.0.0.1:8091 (solo loopback).
2. Esegue l'installer di WordPress (admin / adminadmin) se il sito non è ancora installato.
3. Crea il fixture all'interno del tema attivo e lo stampa: wp-content/themes/twentytwentyfive/page-templates/, root:root, mode 0755, vuoto.

L'immagine del lab aggiunge esplicitamente register_argc_argv=On (lab/Dockerfile) invece di affidarsi al default compilato, e include /flag (root:root, mode 0444, contenuto CVE-2026-87902-POC-OK).

Il tag rolling wordpress:php8.3-apache non è utilizzabile per questo lab: il bug è corretto nella 7.1.2 e un tag non fissato trasforma silenziosamente il lab in uno patchato.

Controlli negativi e limitazioni

Controlli verificati o documentati:

• Nessuna directory page-* di primo livello nel tema → il prefisso fisso non può essere rimosso e il traversal non inizia mai (verificato: fixture rimosso → nessun marker).
• register_argc_argv=Off → nessun writer PEAR, ma la primitiva di inclusione rimane.
• PEAR o le sue dipendenze assenti → nessun writer.
• Numero errato di segmenti .. → target non raggiunto (verificato: le profondità 1-6 e 8-12 non producono alcun marker nel lab).
• Un template di pagina personalizzato assegnato alla Pagina → ordinato prima del candidato malevolo e vince.
• Un file senza suffisso (ad es. /flag) non può essere letto direttamente — al candidato viene aggiunto .php.
• Un WAF/CDN/reverse proxy che rifiuta byte grezzi <, >, = nel request target rompe il canale degli argomenti PEAR (specifico del deployment).
• Il confinamento open_basedir/MAC o una directory di output non scrivibile rompono la catena; noexec su /tmp no (PHP legge e interpreta il file).

Questo PoC riproduce una configurazione verificata. Non afferma che ogni installazione WordPress sia sfruttabile, e non misura la prevalenza.

Remediation

• Aggiornare a WordPress 7.1.2 o successivo (o al backport del proprio branch).
• Difesa in profondità per la gestione dei template: dopo la decodifica, rifiutare candidati con traversal e assoluti (ad es. validate_file()), e prima di includere un template localizzato, confrontare realpath() del candidato e della root del tema con un separatore di directory finale.
• Mitigazioni per gli operatori: impostare register_argc_argv=Off per i SAPI web, rimuovere dalle immagini di produzione i punti di ingresso PEAR inutilizzati e leggibili dal web, verificare i temi child e parent per directory page-* di primo livello, e limitare l'accesso in scrittura per l'account PHP.

File

Cronologia della divulgazione

Il report è stato accettato come finding di sicurezza valido dopo che la sua classificazione iniziale è stata rivista; la corrispondenza non data tale accettazione.

Disclaimer

Questo repository è pubblicato per scopi difensivi e di ricerca. Usalo solo contro sistemi che possiedi o che sei esplicitamente autorizzato a testare. Il lab è vincolato a 127.0.0.1 e non deve essere esposto a reti non attendibili.

Licenza

MIT — vedi LICENSE. I metadati di citazione si trovano in CITATION.cff:

Ressl, Robert (2026). CVE-2026-87902 PoC: unauthenticated path traversal in WordPress page-template resolution (v1.0.0). https://ressl.ch

Il report della vulnerabilità e questo PoC sono stati preparati con l'assistenza dell'IA per l'organizzazione e la revisione della coerenza; il ricercatore è responsabile delle affermazioni tecniche.