Uma vulnerabilidade crítica no Avada Builder, um dos plugins e temas premium mais usados do WordPress, deixou cerca de 1 milhão de sites expostos a um ataque que pode apagar arquivos essenciais do servidor — inclusive o wp-config.php — e abrir caminho para invasão total sem precisar de login. A falha, catalogada como CVE-2026-8713 com nota CVSS 9.1 (crítica), já tem correção na versão 3.15.4, lançada em 2 de junho de 2026, mas qualquer site desatualizado continua vulnerável. Quem usa Avada precisa atualizar já.

O resumo da falha

Pontos-chave

  • A falha afeta o Avada (Fusion) Builder até a versão 3.15.3; a correção saiu na 3.15.4.
  • Atacante não autenticado consegue apagar arquivos arbitrários via path traversal.
  • Apagar o wp-config.php reinicia o WordPress e permite sequestrar o site.
  • Cerca de 1 milhão de instalações ativas estão no escopo, segundo a Wordfence.
  • Quem usa o firewall do Wordfence já está protegido contra o vetor conhecido.

Como o ataque ao Avada funciona

O problema mora numa função chamada maybe_delete_files(), dentro da classe Fusion_Form_DB_Entries. O Avada tem um construtor de formulários que pode salvar as respostas no banco de dados. Para cumprir regras de privacidade (como a LGPD no Brasil), o plugin limpa automaticamente arquivos enviados junto com essas respostas depois de um período definido pelo administrador.

A falha é que essa rotina de limpeza não valida o caminho dos arquivos antes de apagá-los. Não há checagem com realpath() nem confirmação de que o arquivo está dentro do diretório de uploads. Conforme explicou a Cyber Press, “sequências de path traversal embutidas nos dados enviados pelo formulário são preservadas e processadas quando a rotina de limpeza executa”.

Em termos práticos: o atacante envia, num campo de formulário público, um endereço malicioso como /wp-content/uploads/fusion-forms/../../../wp-config.php. Os ../ fazem o servidor “subir” na árvore de diretórios até chegar ao arquivo mais sensível do WordPress. O plugin então chama a função nativa wp_delete_file() e apaga o alvo.

Do clique à invasão total

Aqui está o detalhe que torna a falha perigosa de verdade. Não basta apagar um arquivo qualquer — apagar o wp-config.php tem consequências devastadoras. Esse arquivo guarda as credenciais de banco de dados, as chaves de segurança e a configuração base do site. Sem ele, o WordPress “esquece” que já foi instalado e volta ao assistente de configuração inicial.

O atacante então redireciona esse assistente para um banco de dados controlado por ele. A partir daí, consegue instalar plugins ou temas maliciosos com código PHP arbitrário, alcançando execução remota de código (RCE) e controle completo do servidor. Uma cadeia simples, sem necessidade de credenciais, que parte de um único formulário público.

Etapa O que acontece
1. Submissão Atacante envia payload com path traversal num formulário Avada público
2. Disparo Manipula parâmetros de privacidade para forçar limpeza imediata
3. Deleção A rotina apaga o wp-config.php via wp_delete_file()
4. Reset WordPress volta ao estado de instalação inicial
5. Sequestro Atacante reaponta o site para um banco malicioso e instala backdoor

Por que afeta tanto o Brasil

O WordPress alimenta mais de 40% de todos os sites do planeta, e o Brasil tem um dos maiores ecossistemas WordPress do mundo: lojas virtuais, blogs, sites institucionais de pequenas empresas, portais de notícias regionais. O Avada, por sua vez, é historicamente um dos temas premium mais vendidos da ThemeForest, com presença forte em agências e freelancers que atendem o mercado brasileiro.

O requisito para o ataque é específico, mas não raro: precisa existir um formulário Avada publicado e configurado para salvar respostas no banco. Formulários de contato, cadastro de newsletter, solicitação de orçamento — todos são candidatos. Um site de e-commerce que coleta dados de clientes via formulário Avada está no perfil ideal do alvo.

A boa notícia é que a exploração exige essa condição. A má notícia é que muitos administradores não sabem sequer quais formulários estão publicados, especialmente em sites antigos gerenciados por agências terceirizadas.

A linha do tempo da correção

A divulgação seguiu o processo responsável. O pesquisador de segurança conhecido como daroo reportou a falha pelo programa de recompensas da Wordfence em 13 de maio de 2026. A equipe da Wordfence validou e repassou ao fabricante do Avada em 15 de maio. A correção foi desenvolvida e lançada na versão 3.15.4 em 2 de junho de 2026, conforme detalharam a Cybersecurity News e o GBHackers. O pesquisador recebeu US$ 3.600 de recompensa.

Data Evento
13/05/2026 Reporte do pesquisador daroo à Wordfence
15/05/2026 Validação e disclosure ao fabricante do Avada
02/06/2026 Correção lançada na versão 3.15.4
19/06/2026 Detalhes técnicos publicados publicamente

O que você deve fazer agora

A ação é direta e não admite procrastinação. Se o seu site usa Avada, a checagem leva menos de dois minutos:

  1. Atualize o Avada Builder para 3.15.4 ou superior. É a única proteção definitiva. Versões anteriores continuam vulneráveis.
  2. Verifique se há formulários públicos com salvamento em banco ativo. Se houver formulários obsoletos ou não usados, desative ou remova.
  3. Ative um web application firewall (WAF). O firewall do Wordfence, inclusive na versão gratuita, bloqueia o payload de path traversal antes que ele chegue à função vulnerável.
  4. Faça backup do wp-config.php e do banco. Se o arquivo for apagado num ataque, você precisa conseguir restaurá-lo em minutos, não em horas.
  5. Monitore logs de acesso. Procure requisições para wp_ajax_nopriv_fusion_form_submit_ajax com sequências ../ — é a assinatura do ataque.

Por que o WordPress é visado

O WordPress é alvo preferencial não por ser inseguro em si, mas pela sua escala e pelo ecossistema de plugins. Cada plugin premium adiciona superfície de ataque, e muitos sites rodam dezenas deles simultaneamente. Falhas de validação de entrada em funções que manipulam arquivos são uma classe de vulnerabilidade recorrente — a mesma família de bugs que aparece no OWASP Top 10 de riscos em aplicações web.

O episódio do Avada reforça uma lição que vale para qualquer site WordPress: a segurança não depende só do núcleo, mas da cadeia inteira de plugins e temas. Um único formulário mal configurado pode virar a porta de entrada para o sequestro completo — da mesma família de falhas de validação de entrada que também sustenta ataques de SQL injection. Para quem gerencia lojas virtuais ou sites institucionais no Brasil, a regra é simples — mantenha tudo atualizado, use WAF e audite formulários públicos com a mesma seriedade com que audita senhas de administrador.

Referências