Análise técnica (do código do mirror v3.1.8.4)

1. Nonce público — includes/modules/FilterPosts/FilterPosts.php:1759 cria wp_create_nonce('filter_object') e o anexa via wp_localize_script (filter_ajax_object.security) ao script enfileirado para TODOS os visitantes (wp_enqueue_scripts). O nonce não é uma barreira: cada visitante tem uma cópia dele.
2. Ponto de entrada não autenticado — filter_ajax.php:3406-3407 e loadmore_ajax.php:569-570 registram handlers com wp_ajax_nopriv_* (sem login).
3. Entrada sem sanitização — filter_ajax.php:114-133 (loadmore: 73-91): $loop_var = json_decode(sanitize_text_field($_POST['loop_var'])), depois $custom_loop_template = $loop_var['custom_loop_template'] verbatim — sem basename(), sem whitelist, sem verificação de 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);
   

   Condição: a requisição deve entrar no ramo não-WooCommerce ($posttype do JSON query é livre, sem allow-list) e a query deve retornar >= 1 post.
5. Profundidade do traversal — diretório base = <webroot>/wp-content/themes/<theme>/divi-ajax-filter/loop-templates/ → precisa de ../../../../../ (5×) para voltar ao webroot. NOTA IMPORTANTE: file_exists()/include() falham silenciosamente se o componente do prefixo do caminho não existir — o diretório divi-ajax-filter/loop-templates/ dentro do tema deve existir (essa é a estrutura de custom-template documentada do plugin, então é comum em sites que usam esse recurso; sem esse diretório o traversal é efetivamente bloqueado).
6. RCE — se um atacante conseguir colocar um .php no servidor (upload de usuário com papel de author, configuração de upload permissiva, outro plugin), incluir o arquivo enviado = execução de código.

Estrutura de diretórios

Executando o laboratório

PoC / Scanner ao vivo (sem modo — todos os alvos tratados como ao vivo)

• Domínio sem scheme vira automaticamente http://; dedupe automático; resultados são gravados incrementalmente em results_cve-2026-11613.csv (seguro com Ctrl-C, resultados parciais salvos).
• Status por alvo: VULN: LFI / VULN: LFI+RCE (verde), not-confirmed (amarelo), NO-NONCE / NO-PLUGIN (ciano), UNREACHABLE / ERROR (vermelho).
• --no-color / env NO_COLOR para saída simples; cores desativadas automaticamente quando há pipe.
• Código de saída: 0 = há alvo vulnerável, 1 = não há, 130 = interrompido.

WayangXploit — one-shot (planta canary + verificação automática de RCE)

Um único comando: login → planta canary WayangXploit (plugin pequeno não ativo, somente PoC: imprime marker+uid+uname e sai, não é webshell, sem parâmetro cmd) → verificação → varredura LFI não autenticada → veredito RCE. Auto: upgrade https, bypass SSL, POST preservando redirect. Cleanup: remove o plugin "WayangXploit Canary" + "Divi Compat Shim" no wp-admin após o teste.

poc_http.py agora tem como padrão --upload-marker WayangXploit-RCE-CONFIRMED (então basta --upload-rel / --upload-name).

Resultados da verificação no laboratório (reais, da resposta HTTP)

Condições de explorabilidade em alvos ao vivo (verificadas pelo live_scan.py):

1. Plugin Divi Ajax Filter <= 5.1.2 ativo (recon: acesso direto ao arquivo principal do plugin).
2. Nonce filter_object exposto em página pública (script do módulo enfileirado).
3. Existência de <theme>/divi-ajax-filter/loop-templates/ (o traversal prefixado precisa disso).
4. Para RCE: existe um arquivo .php acessível ao atacante (ex.: resultado de upload) — somente LFI ainda tem impacto (divulgação de informações / bypass de autenticação em qualquer arquivo .php).