Uma vulnerabilidade crítica em um plugin usado na criação de sites WordPress já está sendo explorada por atacantes: a vulnerabilidade no Bricksforge permite enviar e executar arquivos PHP sem precisar de login, abrindo caminho para controle do servidor.
A falha CVE-2026-85097 recebeu pontuação CVSS 10,0 da Patchstack. Ela afeta versões do Bricksforge até 3.1.8.9 e foi corrigida na 3.1.8.10. Tentativas reais de exploração começaram a ser observadas em 7 de outubro.
Resumo
- Bricksforge possui uma vulnerabilidade crítica de upload arbitrário de arquivos.
- O atacante não precisa estar autenticado no WordPress.
- A falha permite executar PHP e pode levar ao controle completo do site.
- Exploração ativa já foi observada; a correção está no Bricksforge 3.1.8.10.
Como funciona a vulnerabilidade no Bricksforge?
O problema está no processo utilizado pelo plugin para tratar arquivos temporários enviados por formulários.
O Bricksforge valida inicialmente o tipo MIME do arquivo. Em uma etapa posterior, porém, passa a confiar em metadados enviados pelo cliente, incluindo a URL de destino.
Segundo a análise técnica da Patchstack, isso permite construir uma sequência em que um arquivo aparentemente válido como imagem também contém código PHP.
Depois, o atacante manipula o destino para que o conteúdo seja gravado como arquivo PHP.
Quando esse arquivo é acessado pelo servidor, o código pode ser executado.
| Ponto | Situação |
|---|---|
| CVE | CVE-2026-85097 |
| CVSS | 10,0 |
| Autenticação necessária | Não |
| Versões afetadas | Até 3.1.8.9 |
| Versão corrigida | 3.1.8.10 |
| Exploração ativa | Sim |
O que um atacante pode fazer depois de executar PHP?
Executar PHP arbitrário no servidor muda completamente a gravidade da situação.
O atacante pode instalar web shells, alterar conteúdo, acessar informações sensíveis e criar mecanismos de persistência.
Em outras palavras, não estamos diante apenas de uma falha que exibe um script no navegador ou altera determinada configuração.
Existe potencial para comprometimento real da instalação.
É justamente por isso que uma auditoria WordPress precisa incluir plugins, arquivos, versões, usuários e servidor.
A falha já está sendo usada em ataques?
Sim.
A Patchstack registrou as primeiras tentativas em 7 de outubro, às 21h47 UTC.
A telemetria mostra padrões de automação, incluindo grupos de endereços IP enviando cargas idênticas em poucos segundos e outras origens testando diferentes extensões e codificações PHP.
Isso não permite atribuir os ataques a um grupo específico, mas indica que a exploração não está acontecendo apenas manualmente contra um único alvo.
A falha recente do Elementor já havia mostrado como plugins populares criam superfícies adicionais de risco. No Bricksforge, a diferença é que já existe exploração observada e não é necessário enganar um administrador para clicar num link.
Confira também estes conteúdos relacionados:
- Entenda a vulnerabilidade recente divulgada no Elementor.
- Veja a falha crítica corrigida no WordPress 7.1.2.
- Saiba o que analisar numa auditoria completa de site.
Quem atualizou agora precisa fazer algo além de instalar o patch?
Se o site ficou exposto numa versão vulnerável enquanto ataques já estavam acontecendo, vale ir além da atualização.
A Patchstack recomenda revisar logs históricos e procurar sinais como:
- requisições ao endpoint de formulário do Bricksforge;
- uso suspeito do parâmetro temporaryFileUploads;
- arquivos PHP inesperados em pastas de uploads;
- arquivos com nomes estranhos em diretórios temporários do plugin;
- requisições a PHP recém-criado nesses diretórios.
Atualizar fecha a vulnerabilidade. Não remove automaticamente algo que já tenha sido colocado no servidor antes da correção.
Esse é um dos motivos para manter backups e logs em uma infraestrutura de hospedagem adequada.
Plugins ampliam funções e também ampliam responsabilidade
Quando expliquei o funcionamento do WordPress, um dos pontos centrais era justamente a possibilidade de adicionar funcionalidades por meio de plugins.
Essa modularidade é uma das razões para a força do CMS. Mas cada componente adicional também precisa receber manutenção.
Não basta verificar o WordPress Core e esquecer plugins durante meses.
Uma auditoria técnica precisa tratar atualização, backup e segurança como parte da operação, assim como performance, UX e conversão.
Eu também já destaquei que o site precisa funcionar para que SEO e anúncios consigam produzir resultado. Segurança é parte dessa condição básica.
Sites desatualizados precisam tratar o Bricksforge como prioridade
A vulnerabilidade no Bricksforge não está mais na categoria de risco puramente teórico. Existem tentativas ativas de exploração.
Quem utiliza versões até 3.1.8.9 deve atualizar imediatamente para 3.1.8.10 ou posterior.
Se a instalação esteve vulnerável durante a janela em que os ataques já estavam ativos, revise também logs, arquivos e contas administrativas.
Se você precisa revisar WordPress, plugins, hospedagem e segurança antes que uma vulnerabilidade vire incidente, fale com a Agência Henshin.
Perguntas frequentes (FAQ)
A falha é a CVE-2026-85097, uma vulnerabilidade crítica de upload arbitrário de arquivos que pode permitir execução remota de código PHP. A Patchstack atribuiu CVSS 10,0 ao problema e confirmou tentativas reais de exploração contra sites WordPress vulneráveis.
A vulnerabilidade afeta o Bricksforge até a versão 3.1.8.9 inclusive. A correção foi disponibilizada na 3.1.8.10. Administradores devem utilizar essa versão ou uma release posterior compatível para eliminar a falha conhecida.
Não. A Patchstack classifica a exploração como não autenticada. O atacante consegue utilizar o fluxo vulnerável de upload de arquivos sem possuir previamente uma conta válida no WordPress, característica que aumenta significativamente a gravidade do problema.
Sim. A Patchstack informa que começou a observar tentativas de exploração em 7 de outubro de 2026. A telemetria também encontrou padrões compatíveis com atividade automatizada e distribuída, incluindo múltiplos endereços IP testando diferentes variações das cargas enviadas.
A atualização fecha a vulnerabilidade conhecida, mas um site que ficou exposto durante a exploração ativa pode precisar de investigação adicional. Administradores devem revisar logs, arquivos PHP inesperados, diretórios de upload e alterações não autorizadas para verificar se houve comprometimento anterior.
