A vulnerabilidade CVE-2026-3300 afeta versões até 1.9.12 do plugin e já foi explorada contra formulários com o recurso de cálculo complexo habilitado.
| Componente | Plugin Everest Forms Pro para WordPress, especificamente o Calculation Addon e a função process_filter() quando o recurso Complex Calculation está em uso. |
| Vetor | Envio não autenticado de valores manipulados em campos de formulário do tipo texto, e-mail, URL, seleção ou rádio em formulários que usam cálculo complexo. |
| Impacto | Execução remota de código PHP no servidor, com possibilidade de comprometimento completo do site, criação de administradores indevidos, implantação de web shells e persistência. |
| Prioridade | Atualizar imediatamente para a versão 1.9.13 ou posterior e procurar tentativas de criação de contas administrativas não autorizadas. |
| Versões | Todas as versões do Everest Forms Pro até 1.9.12 estão afetadas; a correção foi publicada em 18 de março de 2026 na versão 1.9.13. |
| Artefatos | Explorações observadas desde 13 de abril de 2026; mais de 29.300 tentativas foram bloqueadas, incluindo tentativas recentes de criar um administrador chamado diksimarina. |
A vulnerabilidade CVE-2026-3300 é uma falha crítica de execução remota de código no Everest Forms Pro, plugin de formulários para WordPress com cerca de 4.000 instalações ativas. O defeito recebeu pontuação CVSS 9.8 e afeta todas as versões até 1.9.12. A condição vulnerável está ligada ao Calculation Addon, quando um formulário usa o recurso de cálculo complexo e processa valores fornecidos por usuários sem isolar corretamente esses dados do contexto de código PHP.
O problema ocorre porque a função process_filter() concatena valores enviados em campos do formulário dentro de uma string de código PHP e depois encaminha esse conteúdo para eval(). A sanitização aplicada não remove nem escapa adequadamente caracteres relevantes para o contexto de execução PHP, como aspas simples e outros elementos capazes de alterar a estrutura do código avaliado. Como consequência, um usuário não autenticado pode enviar um valor especialmente construído em campos de string e fazer com que o servidor execute PHP arbitrário.
A exploração bem-sucedida permite um nível de impacto alto para sites WordPress afetados. O atacante não precisa de conta prévia no site, desde que consiga alcançar um formulário vulnerável configurado com cálculo complexo. A partir da execução de PHP no servidor, o comprometimento pode evoluir para criação de contas administrativas indevidas, implantação de web shells e manutenção de acesso persistente. Há exploração ativa observada desde 13 de abril de 2026, com mais de 29.300 tentativas bloqueadas e atividade ainda registrada nas 24 horas anteriores ao material analisado.
O fluxo vulnerável depende de três condições principais: o site precisa executar uma versão afetada do Everest Forms Pro, o Calculation Addon precisa estar presente na lógica do formulário e o formulário precisa usar o recurso Complex Calculation. Nesse cenário, campos de entrada comuns, como texto, e-mail, URL, seleção e rádio, tornam-se relevantes porque seus valores podem ser incorporados ao cálculo. O risco não está no tipo visual do campo, mas no fato de o valor submetido ser tratado como parte de uma expressão que termina avaliada no servidor.
A função vulnerável tenta limpar o conteúdo recebido com sanitize_text_field(), mas essa limpeza é insuficiente para uma string que será montada como código PHP. A função pode reduzir ruído de entrada típico de formulário, mas não transforma dados não confiáveis em conteúdo seguro para avaliação dinâmica. Quando esses valores são concatenados sem escape adequado e entregues a eval(), a fronteira entre dado e instrução deixa de existir. Esse padrão é especialmente perigoso em plugins de CMS porque combina entrada pública, lógica extensível e execução dentro do mesmo processo que tem acesso ao ambiente do site.
As tentativas observadas procuram transformar a execução de código em controle administrativo do WordPress. O payload mais comum identificado no contexto tenta criar uma conta de administrador chamada diksimarina. Esse comportamento é consistente com uma estratégia de persistência simples: em vez de depender apenas da execução momentânea obtida pela vulnerabilidade, o operador tenta estabelecer uma identidade privilegiada no próprio painel do WordPress. Outras consequências confirmadas para a classe de exploração incluem implantação de web shells e abertura de caminhos adicionais para aprofundar o acesso no servidor.
O artigo original também trouxe, no mesmo contexto, campanhas de skimmer contra comércio eletrônico que abusam de serviços confiáveis como canais de comando, hospedagem de código e exfiltração. Esses casos são distintos da falha no Everest Forms Pro, mas reforçam um padrão defensivo útil: invasores procuram se apoiar em componentes já autorizados pelo ambiente, seja um plugin WordPress com lógica vulnerável, seja um domínio de serviço amplamente permitido por políticas de conteúdo e filtros de rede. Para a vulnerabilidade principal, a defesa deve tratar formulários públicos com cálculo dinâmico como superfície crítica até que a correção seja confirmada.
A superfície afetada é composta por sites WordPress que usam Everest Forms Pro em versões até 1.9.12 e expõem formulários com cálculo complexo. A estimativa informada para o plugin é de cerca de 4.000 instalações ativas, mas a presença do plugin por si só não confirma exploração: a condição crítica depende da combinação entre versão vulnerável, Calculation Addon e formulários que aceitam valores de string usados no cálculo. Ambientes com formulários públicos, páginas de contato avançadas, cotações, pedidos, inscrições ou qualquer fluxo que calcule valores com base em entrada do usuário merecem verificação prioritária.
A correção foi publicada em 18 de março de 2026 na versão 1.9.13. Como a exploração foi observada a partir de 13 de abril de 2026, existe uma janela clara entre a disponibilização do patch e o início da atividade maliciosa registrada. Sites que permaneceram em versões vulneráveis após essa data devem ser avaliados como potencialmente expostos, principalmente se aceitavam submissões anônimas. O risco é maior quando o servidor permite escrita em diretórios usados pelo WordPress, quando contas administrativas antigas não são revisadas e quando não há registro centralizado de alterações em usuários, plugins e arquivos PHP.
O impacto deve ser entendido no limite técnico confirmado: execução arbitrária de PHP no servidor e comprometimento do site. Isso não significa automaticamente vazamento de dados de usuários, movimentação lateral ou comprometimento de infraestrutura externa, a menos que a investigação local encontre evidências adicionais. Ainda assim, a execução de PHP dentro de uma aplicação WordPress pode dar ao invasor acesso a segredos de configuração, banco de dados usado pelo site e mecanismos internos de administração, dependendo das permissões do processo web e da configuração do ambiente.
- Everest Forms Pro em versões até 1.9.12.
- Formulários que usam
Complex Calculationno Calculation Addon. - Campos públicos de texto, e-mail, URL, seleção ou rádio usados como entrada para cálculo.
- Sites sem atualização para 1.9.13 após 18 de março de 2026.
- Ambientes WordPress nos quais criação de administradores e alteração de arquivos PHP não geram alerta.
A busca deve começar por inventário e linha do tempo. Equipes responsáveis por WordPress precisam confirmar a versão instalada do Everest Forms Pro, identificar formulários com cálculo complexo e comparar submissões recebidas desde 13 de abril de 2026 com eventos administrativos. A presença de uma versão corrigida hoje não elimina a necessidade de investigação se o site ficou vulnerável durante a janela de exploração. A prioridade é reconstruir se houve submissões suspeitas, criação de usuários privilegiados, alteração de arquivos ou instalação de componentes persistentes.
Nos logs da aplicação e do servidor web, procure picos de submissões para endpoints associados a formulários do Everest Forms, especialmente quando partirem de clientes não autenticados e precederem mudanças administrativas. Como os IPs de origem não foram fornecidos no contexto, não é possível depender de uma lista estática de indicadores. A detecção deve se apoiar em comportamento: campos de formulário com caracteres incomuns para o tipo esperado, sequência de submissão seguida de criação de usuário, respostas anômalas do servidor e modificações em arquivos PHP próximos ao momento da requisição.
No WordPress, revise contas com privilégio de administrador criadas após 13 de abril de 2026, com atenção especial a nomes inesperados e à tentativa citada de criação do usuário diksimarina. Também é necessário revisar plugins, temas, arquivos alterados recentemente, uploads com extensão PHP e entradas que possam funcionar como web shell. Em ambientes com EDR ou monitoramento de integridade, correlacione processos do servidor web executando ações incomuns, escrita em diretórios sensíveis do WordPress e conexões de saída que não existiam antes do evento.
- Eventos de criação de usuários administradores após submissões anônimas de formulário.
- Submissões a formulários com cálculo complexo contendo caracteres incompatíveis com valores esperados.
- Arquivos PHP novos ou modificados em diretórios de plugins, temas ou uploads.
- Instalação ou ativação de plugins desconhecidos após 13 de abril de 2026.
- Registros de tentativas de criação do administrador
diksimarina. - Mudanças em permissões, chaves de configuração ou comportamento de saída do processo web.
A ação principal é atualizar o Everest Forms Pro para a versão 1.9.13 ou posterior, publicada em 18 de março de 2026. A atualização deve ser acompanhada de validação efetiva da versão em produção, não apenas de agendamento de manutenção. Quando não for possível atualizar imediatamente, a exposição deve ser reduzida removendo ou desabilitando formulários que usem cálculo complexo, restringindo acesso a páginas afetadas e monitorando agressivamente submissões anônimas. Essa contenção temporária não substitui o patch, porque a raiz do problema está no tratamento inseguro de entrada dentro do componente.
Depois da correção, trate qualquer site que ficou vulnerável durante a janela de exploração como candidato a comprometimento. A resposta deve incluir revisão de usuários administrativos, rotação de credenciais de administração, auditoria de plugins e temas, verificação de integridade de arquivos e análise de logs desde 13 de abril de 2026. Se houver sinal de execução de PHP arbitrário, web shell ou administrador indevido, a limpeza precisa considerar persistência em múltiplos pontos do WordPress, inclusive banco de dados, arquivos de tema, plugins adicionados e tarefas agendadas.
Para reduzir recorrência, formulários que processam cálculos devem ser tratados como código sensível. Dados de usuários não devem ser concatenados em expressões executáveis; quando cálculo dinâmico for necessário, a implementação deve usar parsers restritos, listas de operadores permitidos e separação clara entre dados e instruções. No nível operacional, mantenha inventário de plugins pagos e gratuitos, acompanhe atualizações de segurança, monitore criação de administradores e configure alertas para alteração de arquivos PHP em diretórios onde o WordPress normalmente não deveria receber código novo.
- Atualizar Everest Forms Pro para 1.9.13 ou posterior e confirmar a versão em produção.
- Identificar e revisar todos os formulários que usam
Complex Calculation. - Desabilitar temporariamente formulários vulneráveis se a atualização imediata não for possível.
- Auditar contas administrativas criadas desde 13 de abril de 2026.
- Procurar web shells, arquivos PHP recém-criados e alterações suspeitas em plugins e temas.
- Rotacionar credenciais administrativas se houver qualquer indício de exploração bem-sucedida.
- Ativar alertas para criação de administradores, instalação de plugins e modificação de arquivos executáveis.
0 Comentários