Analisi tecnica (dal codice mirror v3.1.8.4)

1. Nonce pubblico — includes/modules/FilterPosts/FilterPosts.php:1759 crea wp_create_nonce('filter_object') e lo inietta tramite wp_localize_script (filter_ajax_object.security) nello script accodato per TUTTI i visitatori (wp_enqueue_scripts). Il nonce non è una barriera: ogni visitatore ne ha una copia.
2. Punto di ingresso non autenticato — filter_ajax.php:3406-3407 e loadmore_ajax.php:569-570 registrano gli handler con wp_ajax_nopriv_* (senza login).
3. Input senza sanitizzazione — filter_ajax.php:114-133 (loadmore: 73-91): $loop_var = json_decode(sanitize_text_field($_POST['loop_var'])), poi $custom_loop_template = $loop_var['custom_loop_template'] verbatim — senza basename(), senza whitelist, senza controllo realpath.
4. Sink — filter_ajax.php:2871-2873 (loadmore: 344-346):
   root@kitploit:~

   if ($loop_templates == 'custom-template') {
       if (file_exists(get_stylesheet_directory() . '/divi-ajax-filter/loop-templates/' . $custom_loop_template)) {
           include(get_stylesheet_directory() . '/divi-ajax-filter/loop-templates/' . $custom_loop_template);
   

   Condizione: la richiesta deve entrare nel ramo non-WooCommerce ($posttype dal JSON query è libero, nessuna allow-list) e la query deve restituire >= 1 post.
5. Profondità di traversal — dir base = <webroot>/wp-content/themes/<theme>/divi-ajax-filter/loop-templates/ → servono ../../../../../ (5×) per tornare alla webroot. NOTA IMPORTANTE: file_exists()/include() falliscono silenziosamente se il componente del percorso prefissato non esiste — la directory divi-ajax-filter/loop-templates/ dentro il tema deve esistere (questa è la struttura custom-template documentata dal plugin, quindi è comune nei siti che usano questa funzionalità; senza quella dir la traversal è di fatto bloccata).
6. RCE — se un attaccante può piazzare un .php sul server (upload utente con ruolo author, configurazione upload permissiva, altro plugin), includere il file caricato = esecuzione di codice.

Struttura delle directory

Esecuzione del laboratorio

PoC / Scanner live (senza modalità — tutti i target trattati come live)

• I domini senza scheme diventano automaticamente http://; dedupe automatico; i risultati vengono scritti in modo incrementale su results_cve-2026-11613.csv (sicuro con Ctrl-C, i risultati parziali vengono salvati).
• Stato per target: VULN: LFI / VULN: LFI+RCE (verde), not-confirmed (giallo), NO-NONCE / NO-PLUGIN (ciano), UNREACHABLE / ERROR (rosso).
• --no-color / env NO_COLOR per output semplice; i colori si disattivano automaticamente quando si usa una pipe.
• Exit code: 0 = ci sono target vulnerabili, 1 = nessuno, 130 = interrotto.

WayangXploit — one-shot (pianta canary + verifica RCE automatica)

Un solo comando: login → pianta canary WayangXploit (piccolo plugin non attivo, solo PoC: stampa marker+uid+uname poi exit, non è una webshell, nessun parametro cmd) → verifica → sweep LFI non autenticato → verdetto RCE. Auto: https-upgrade, SSL bypass, POST che preserva i redirect. Cleanup: rimuove il plugin "WayangXploit Canary" + "Divi Compat Shim" in wp-admin dopo il test.

poc_http.py ora ha come default --upload-marker WayangXploit-RCE-CONFIRMED (quindi basta --upload-rel / --upload-name).

Risultati della verifica in laboratorio (reali, dalle risposte HTTP)

Requisiti di sfruttabilità su target live (controllati da live_scan.py):

1. Plugin Divi Ajax Filter <= 5.1.2 attivo (recon: accesso diretto al file principale del plugin).
2. Nonce filter_object esposto su pagine pubbliche (script del modulo accodato).
3. Esiste <theme>/divi-ajax-filter/loop-templates/ (la traversal con prefisso lo richiede).
4. Per RCE: c'è un file .php raggiungibile dall'attaccante (es. risultato di upload) — anche solo LFI ha impatto (info disclosure / bypass auth su qualsiasi file .php).