dungsocool/cve-2025-7384Exploit PoC e análise de causa raiz para uma injeção de objeto PHP crítica não autenticada no WordPress Database for Contact Form 7, que leva a RCE por meio de exclusão arbitrária de arquivos.
Plugin: Database for Contact Form 7 (contact-form-entries) ≤ 1.4.3
CVSS: 9.8 (Crítico)
CWE: CWE-502 — Desserialização de Dados Não Confiáveis
Requisito de Autenticação: Nenhum (Não autenticado)
Impacto: Execução Remota de Código
O plugin "Database for Contact Form 7" (slug: contact-form-entries) versão 1.4.3 e anteriores contém uma vulnerabilidade de Injeção de Objeto PHP. Quando um administrador do WordPress visualiza um registro (entrada) de formulário no painel administrativo, o plugin chama a função maybe_unserialize() diretamente em dados enviados por um usuário não autenticado por meio do Contact Form 7, sem controlar a lista de classes permitidas para instanciar.
Um atacante não precisa fazer login — basta enviar um formulário de contato comum inserindo um objeto PHP serializado em qualquer campo do formulário. Esses dados são armazenados crus no banco de dados. Quando um administrador abre para visualizar essa entrada, a função de desserialização instancia um objeto da escolha do atacante, acionando métodos mágicos como __destruct() ou __wakeup() → executando comportamento arbitrário dependendo dos gadgets POP disponíveis no ambiente WordPress.
Nível de Severidade: Com um gadget POP adequado (por exemplo, uma classe cujo método
__destruct()chamaunlink()), um atacante pode excluir o arquivowp-config.php, revertendo o WordPress para a tela de instalação inicial → reinstalando com uma conta de administrador controlada pelo atacante → instalando um plugin contendo um webshell → alcançando Execução Remota de Código (RCE) total no servidor.
| Atributo | Valor |
|---|---|
| ID CVE | CVE-2025-7384 |
| Pontuação CVSS | 9.8 (Crítico) |
| CWE | CWE-502 — Desserialização de Dados Não Confiáveis |
| Plugin Afetado | contact-form-entries (Database for Contact Form 7) ≤ 1.4.3 |
| Requisito de Autenticação | Nenhum — qualquer pessoa que envie um formulário CF7 pode injetar payload |
| Condição de Acionamento | O administrador visualiza a entrada injetada no painel administrativo |
| Impacto Máximo | Execução Remota de Código Não Autenticada |
| Versão Corrigida | 1.4.4+ (substitui unserialize por json_decode ou allowed_classes: false) |
O PHP usa serialize() para converter um objeto em uma string de texto estruturada, e unserialize() para restaurar o objeto a partir dessa string. Quando unserialize() recebe dados de uma fonte não confiável (por exemplo, entrada do usuário), um atacante pode construir um objeto arbitrário pertencente a qualquer classe atualmente carregada na memória do PHP naquele momento.
Métodos especiais que o PHP invoca automaticamente durante o ciclo de vida de um objeto. Os mais importantes neste contexto:
__wakeup() — invocado imediatamente quando um objeto é desserializado__destruct() — invocado quando um objeto é destruído (sai do escopo ou a requisição termina)__toString() — invocado quando um objeto é convertido para stringUma técnica de encadear múltiplos métodos mágicos de classes existentes dentro da aplicação para construir uma sequência perigosa de comportamentos. O atacante não escreve novo código — ele apenas manipula as propriedades de objetos existentes para que, quando os métodos mágicos sejam executados, realizem ações não pretendidas pelos desenvolvedores.
maybe_unserialize() no WordPressUma função wrapper do núcleo do WordPress. Ela chama is_serialized() para verificar se uma string é dados serializados — se verdadeiro, chama unserialize() para restaurar o objeto. Problema: esta função não passa o parâmetro allowed_classes (disponível desde o PHP 7.0) para limitar quais classes são permitidas a instanciar.
Comece pesquisando em todo o código-fonte do plugin para localizar funções de desserialização — estas são as funções mais perigosas em PHP, pois podem levar à Injeção de Objeto:
grep -rn "unserialize" wp-src/wp-content/plugins/contact-form-entries/
A saída revela múltiplos pontos de chamada para maybe_unserialize(), mais notavelmente dentro de includes/data.php na linha 545 na função verify_val():
// data.php lines 538-548
public function verify_val($string){
if(in_array(substr(ltrim($string),0,1), array('{','['))
&& in_array(substr(rtrim($string),-1), array('}',']'))
){
$val = json_decode($string, 1);
if(is_array($val)){ $string = $val; }
} else if(is_serialized($string)){ // line 544
$string = maybe_unserialize($string); // ★ line 545 — SINK
}
return $string;
}
Pergunta-chave: De onde vem a variável $string? Se ela vem de entrada do usuário sem filtragem → isto é uma vulnerabilidade.
Descubra onde verify_val() é invocada. Rastreie retroativamente no mesmo arquivo data.php:
// data.php lines 520-535
public function get_lead_detail($lead_id){
global $wpdb;
$table = $wpdb->prefix . 'vxcf_leads_detail';
$detail_arr = $wpdb->get_results(
$wpdb->prepare("SELECT * FROM $table WHERE lead_id=%d", $lead_id),
ARRAY_A
);
foreach($detail_arr as $k => $v){
if(!empty($v['value'])){
$detail_arr[$k]['value'] = $this->verify_val($v['value']); // ← calls verify_val
}
}
return $detail_arr;
}
→ $string é exatamente $v['value'] — valores recuperados da tabela do banco de dados wp_vxcf_leads_detail. Esta função é chamada quando um administrador visualiza os detalhes de uma entrada de formulário.
Próxima pergunta: De onde vêm os dados dentro de wp_vxcf_leads_detail? Quem os escreve?
A partir do Passo 2, sabemos que os dados são puxados do banco de dados. Próxima pergunta: quem escreve dados nele? Pesquise por consultas INSERT dentro de data.php:
grep -rn "insert" wp-src/wp-content/plugins/contact-form-entries/includes/data.php
Abra o código da função create_lead() (linhas 85-103) para detalhes:
