Hackers estão explorando uma falha crítica no plugin Everest Forms Pro, utilizado em cerca de 4 mil sites WordPress, para executar código arbitrário no servidor e, em muitos casos, obter controle total dos ambientes comprometidos. A vulnerabilidade, catalogada como CVE-2026-3300, recebeu pontuação 9,8 no sistema CVSS, nível considerado crítico.
O problema atinge todas as versões do Everest Forms Pro até a 1.9.12, inclusive. A correção foi liberada em 18 de março de 2026, na versão 1.9.13 do plugin, mas muitos administradores ainda não aplicaram a atualização, o que mantém milhares de sites expostos a ataques automatizados.
De acordo com pesquisadores da Wordfence, a falha está ligada ao recurso Calculation Addon, mais especificamente à função `process_filter()`. Essa função concatena dados enviados pelos usuários em campos de formulário dentro de uma string de código PHP e, em seguida, passa esse conteúdo para a função `eval()` sem realizar a sanitização adequada. Na prática, o servidor acaba tratando parte da entrada do usuário como se fosse código PHP legítimo.
Embora o plugin aplique a função `sanitize_text_field()` aos dados recebidos, essa rotina não foi projetada para proteger contra injeção de código no contexto de PHP: ela não escapa aspas simples nem outros caracteres críticos que podem quebrar a estrutura do código e permitir a inclusão de trechos maliciosos. Com isso, um atacante consegue manipular campos aparentemente inofensivos para inserir comandos que serão avaliados pelo servidor.
O cenário fica ainda mais grave porque a exploração não exige autenticação. Ou seja, qualquer visitante pode enviar um formulário com valores especialmente preparados em campos de texto, e-mail, URL, seleção ou radio button, desde que o formulário use o recurso de “Complex Calculation”. Se o plugin estiver vulnerável, esses valores podem ser transformados em código executável no backend sem qualquer aviso ao administrador.
Uma exploração bem-sucedida da CVE-2026-3300 permite que o invasor execute comandos PHP diretamente no servidor. A partir daí, é possível criar contas administrativas falsas, instalar web shells, alterar arquivos do WordPress, injetar backdoors e estabelecer mecanismos de persistência para manter o acesso mesmo após tentativas de limpeza superficial do ambiente.
Em um site WordPress, esse tipo de falha costuma resultar em controle amplo da aplicação: modificação de páginas e posts, inserção de scripts maliciosos em temas e plugins, roubo de dados de usuários cadastrados, redirecionamentos para páginas de phishing e utilização da infraestrutura comprometida para espalhar malware ou realizar outros ataques em cadeia.
Os ataques começaram a ser observados em 13 de abril de 2026. Em um curto espaço de tempo, a Wordfence registrou mais de 29.300 tentativas de exploração da vulnerabilidade em seus sistemas de proteção, sendo 16 delas apenas nas últimas 24 horas analisadas. Esse volume indica que a falha já foi integrada a ferramentas automatizadas de varredura e exploração em massa, focadas em sites que ainda não foram atualizados.
O payload mais recorrente identificado nas tentativas de ataque tinha como objetivo criar uma conta de administrador com o usuário “diksimarina”, vinculada ao e-mail “[email protected]”. Criar um administrador oculto ou com nome genérico é uma técnica bastante usada em ataques a WordPress, porque garante ao criminoso um acesso persistente ao painel, mesmo que a vulnerabilidade original seja corrigida posteriormente.
Segundo os dados divulgados, as tentativas de exploração se originaram de, entre outros, os endereços IP 202.56.2.126, 209.146.60.26, 15.235.166.18, 2402:1f00:8000:800::40db e 185.78.165.153. Embora endereços IP possam ser trocados ou falsificados com relativa facilidade, eles servem como indicador de comprometimento para correlação em sistemas de monitoramento e análise de logs.
Diante desse cenário, administradores que utilizam o Everest Forms Pro devem tomar medidas imediatas. O primeiro passo é garantir que o plugin esteja atualizado, no mínimo, para a versão 1.9.13, em que a falha foi corrigida. Em seguida, é fundamental revisar o painel de usuários em busca de contas administrativas recém-criadas ou suspeitas, especialmente logins que o responsável pelo site não reconhece.
Também é recomendável analisar os logs de acesso do servidor e do WordPress em busca de requisições incomuns, picos de envio de formulários ou tentativas de login vindas dos IPs associados às campanhas maliciosas. Caso seja identificada atividade suspeita, deve-se considerar a redefinição de senhas de administradores, a invalidação de sessões ativas e uma varredura completa nos arquivos do site em busca de alterações não autorizadas.
A divulgação desse ataque coincide com novos alertas sobre campanhas de skimmers digitais voltadas a lojas online. A Sansec identificou diversas operações focadas no roubo de dados de cartão de crédito, entre elas uma campanha particularmente sofisticada que abusa da infraestrutura da Stripe tanto como servidor de comando e controle quanto como canal de exfiltração dos dados roubados.
Nesse esquema, os invasores tratam a Stripe como uma espécie de armazenamento gratuito para as informações coletadas e para partes do código do skimmer, explorando a boa reputação do domínio para escapar de controles de segurança. Em muitos ambientes de comércio eletrônico, domínios como o da Stripe e o do Google Tag Manager são implicitamente confiáveis, o que facilita a passagem de scripts maliciosos e tráfego suspeito sem despertar alertas imediatos de Content Security Policy ou filtros de rede.
A campanha descrita utiliza um contêiner no Google Tag Manager para carregar o código malicioso em todas as páginas que incluem aquele container, com foco especial em páginas de checkout de plataformas como Magento e Adobe Commerce. Nesses ambientes, um loader executado via GTM busca um skimmer ofuscado armazenado no campo de metadados de uma conta de cliente na Stripe, identificada pela Sansec com um identificador específico.
Uma vez carregado no navegador da vítima, o skimmer passa a interceptar informações inseridas durante o processo de pagamento: dados de cartão, endereços de cobrança, e-mails e números de telefone. Esses dados são primeiramente armazenados no localStorage do navegador, como passo intermediário, e depois enviados de forma discreta para a conta Stripe controlada pelo atacante.
De acordo com a análise da Sansec, cada cartão roubado é registrado como se fosse um “cliente” na conta do criminoso. Assim que a exfiltração é concluída, o loader remove as informações correspondentes do localStorage para evitar duplicação de registros e minimizar rastros visíveis. Em um momento posterior, o invasor utiliza a própria API e as mesmas chaves da Stripe para listar esses “clientes”, transformando a base da plataforma em um repositório estável de cartões e dados capturados. O registro da conta utilizada na Stripe para armazenar o skimmer teria sido criado em 24 de dezembro, indicando que a campanha estava planejada para aproveitar o pico de compras de fim de ano.
—
O que administradores de WordPress devem fazer agora
Diante da exploração ativa da falha no Everest Forms Pro e do crescimento de campanhas contra e-commerces, donos de sites e lojas virtuais precisam adotar uma postura mais preventiva do que reativa. Algumas ações práticas:
1. Atualizar imediatamente o Everest Forms Pro
– Verificar a versão instalada do plugin.
– Atualizar pelo painel do WordPress ou manualmente via FTP/SSH para, no mínimo, a versão corrigida.
– Após a atualização, revalidar formulários que usem “Complex Calculation”.
2. Auditar usuários e permissões
– Revisar todas as contas com perfil de administrador.
– Remover usuários desconhecidos ou que não deveriam ter privilégios elevados.
– Ativar notificações de criação de novas contas, quando possível.
– Habilitar autenticação em dois fatores para administradores.
3. Reforçar a segurança do WordPress
– Manter núcleo, temas e plugins sempre atualizados.
– Remover plugins e temas que não são mais usados.
– Utilizar um WAF (firewall de aplicação web) voltado a WordPress para bloquear tentativas de exploração conhecidas.
– Restringir acesso ao painel de administração por IP ou por camada adicional de senha no servidor, quando possível.
4. Monitorar logs e sinais de comprometimento
– Verificar logs de acesso e de erro do servidor web.
– Procurar por POSTs frequentes em páginas de formulário com parâmetros incomuns.
– Monitorar integridade de arquivos (comparando com versões oficiais de temas e plugins).
– Ficar atento a mudanças inesperadas em configurações de redirecionamento, anúncios estranhos no site e queixas de usuários.
5. Planejar resposta a incidentes
– Ter rotina definida para backup diário e testes de restauração.
– Documentar contatos e procedimentos em caso de detecção de invasão.
– Em um cenário de comprometimento confirmado, avaliar reinstalação completa do WordPress a partir de backups limpos, com troca de todas as senhas (painel, FTP, banco de dados, e-mail).
—
Cuidados extras para lojas virtuais e ambientes de pagamento
No contexto das campanhas de skimming citadas, lojas virtuais e qualquer negócio que processe pagamentos online precisam de camadas adicionais de proteção:
1. Revisar scripts de terceiros
– Mapear todos os scripts carregados via Google Tag Manager e outras tags.
– Remover tags antigas, não documentadas ou que não tenham um responsável claramente identificado.
– Minimizar a quantidade de provedores de script externos.
2. Endurecer Content Security Policy (CSP)
– Restringir domínios autorizados a carregar scripts.
– Evitar permissões amplas que liberem qualquer script inline ou de domínios genéricos.
– Revisar regularmente políticas para se adequar a mudanças na infraestrutura de marketing e análise.
3. Monitorar código de checkout
– Fazer auditorias periódicas em páginas de pagamento para identificar scripts injetados ou modificações suspeitas.
– Utilizar ferramentas de varredura de skimmers que analisem o front-end e o comportamento dos formulários de pagamento.
4. Segregar ambientes
– Separar o ambiente de pagamento do restante do site, sempre que possível.
– Reduzir o número de integrações ativas no fluxo de checkout, diminuindo a superfície de ataque.
5. Treinar equipes técnicas e de marketing
– Garantir que quem gerencia tags, campanhas e integrações entenda os riscos de adicionar código de terceiros sem validação.
– Implementar um fluxo de aprovação para qualquer novo script em páginas sensíveis, como checkout e login.
—
A exploração da vulnerabilidade no Everest Forms Pro e o uso criativo de serviços legítimos, como Stripe e Google Tag Manager, por grupos maliciosos ilustram uma tendência clara: atacantes se aproveitam tanto de falhas técnicas quanto de brechas operacionais e de confiança em serviços de terceiros. Para reduzir o risco, não basta instalar um plugin de segurança; é necessário encarar a gestão de atualizações, a revisão de acessos e o controle de scripts externos como partes essenciais da operação diária de qualquer site profissional ou loja virtual.