BrunoP.Blog

Um plugin com eval() está invadindo sites WordPress: o caso Everest Forms e como se proteger

Uma falha crítica (CVSS 9.8) no plugin Everest Forms Pro deixa qualquer um rodar PHP no seu servidor — e os ataques explodiram em maio. O erro é de manual: input do usuário caindo direto num eval(). Te mostro como funciona e um checklist de 5 minutos pra blindar seu WordPress.

Uma vulnerabilidade crítica no plugin Everest Forms (WordPress, +100 mil instalações) permitia a qualquer visitante executar código arbitrário no servidor via um campo de formulário não sanitizado. A causa é o clássico eval() em input do usuário. Este post analisa o caso e mostra como blindar seu WordPress em cinco minutos.

De vez em quando cai na minha caixa a mesma mensagem, em pânico: "Bruno, meu site WordPress tá estranho — apareceu um usuário admin que não sou eu". Quase sempre a raiz é a mesma: um plugin desatualizado. Essa semana o caso da vez tem nome e sobrenome — e uma lição que vale pra qualquer um que roda um site.

O que aconteceu com o plugin Everest Forms?

O Everest Forms Pro, um plugin de formulários com centenas de milhares de instalações, recebeu uma falha crítica: a CVE-2026-3300, nota 9.8 de 10. Ela permite que qualquer visitante, sem login, execute código PHP no servidor — o que basicamente entrega o site.

A correção saiu em março (versão 1.9.13; afeta tudo até a 1.9.12). Mesmo assim, os ataques começaram em 13 de abril e explodiram: a Wordfence registrou mais de 29 mil tentativas bloqueadas, com um pico de ~17.900 num único dia (16 de maio). A assinatura do ataque: criar um usuário administrador pirata (apelidado de diksimarina) e assumir o painel.

Por que usar eval() em input do usuário é tão perigoso?

O complemento de cálculo do plugin pega o que a pessoa digita num campo do formulário, monta uma string de PHP e executa com eval(). O sanitize_text_field() do WordPress até "limpa" o texto — mas não escapa aspas. Ou seja: o atacante fecha a string e injeta o próprio código.

// ERRADO — dado do usuário virando código
$expr = sanitize_text_field($_POST['campo']); // não escapa aspas
eval('$total = ' . $expr . ';');
// entrada maliciosa:  1; system($_GET['c']); //
// vira:  $total = 1; system($_GET['c']); //';

Resultado: um campo de formulário inofensivo vira um terminal aberto pra internet inteira.

Por que esse tipo de falha ainda acontece em 2026?

O eval() é o pecado original do PHP: poderoso, conveniente — e por isso ainda aparece em código que roda em milhares de sites. A regra é antiga e simples, e eu repito pra todo cliente: dado de usuário nunca vira código. Nem com eval(), nem com system(), nem concatenado num SQL.

Como eu faria (e como deveria ser)

Pra somar dois números você não precisa de um interpretador de código. Você valida a entrada e calcula com operações normais:

// CERTO — valida e calcula, sem executar código do usuário
$n = filter_var($_POST['campo'], FILTER_VALIDATE_FLOAT);
$total = ($n !== false) ? $n * 2 : 0;

É menos "esperto" e infinitamente mais seguro. No banco, a mesma lógica: prepared statements (PDO), nunca concatenar. É assim que eu escrevo PHP — e é o tipo de revisão que faço quando assumo a manutenção de um sistema.

Blinde seu WordPress em 5 minutos

  • Atualize todos os plugins e ligue a atualização automática. Se você usa o Everest Forms, vá pra 1.9.13+ agora.
  • Remova plugins e temas que você não usa — cada um é uma porta a mais.
  • Cheque os administradores (Usuários > Todos os usuários): tem algum que você não criou? Apague e troque todas as senhas.
  • Use um WAF (Wordfence e similares) — ele bloqueia a maioria dessas tentativas automaticamente.
  • Tenha backup automático fora do servidor, pra restaurar rápido se o pior acontecer.

Quero uma auditoria do meu site

Achou um admin estranho, ou quer revisar a segurança do seu site antes que vire problema? É exatamente o tipo de coisa que eu resolvo — bora conversar.

Fontes

The Hacker News · Infosecurity Magazine · SentinelOne (CVE-2026-3300)