Falha crítica no Bricksforge já é explorada — atualizar não limpa invasões

Em 8 de outubro de 2026, a Patchstack publicou um alerta sobre tentativas de exploração da CVE-2026-85097 no Bricksforge, observadas desde 7 de outubro, às 21h47 UTC, em versões até 3.1.8.9; a correção indicada para essa linha é a 3.1.8.10. Administradores de sites WordPress afetados precisam atualizar o plugin e investigar o período anterior à correção: instalar o patch fecha a falha, mas não remove um arquivo ou uma alteração que já tenha sido deixada no servidor.

A SecurityWeek também relatou as tentativas de exploração em sites reais e o risco de execução de código sem autenticação. O alerta trata de atividade observada contra a vulnerabilidade; para saber se um site específico foi comprometido, é preciso confrontar registros de acesso, arquivos armazenados e mudanças feitas no WordPress. Essa distinção define a resposta: atualizar protege contra novos abusos dessa falha, enquanto a análise posterior procura efeitos de um abuso anterior.

Como o Pro Forms pode gravar um arquivo PHP

A falha está no processamento de arquivos do Pro Forms, componente do Bricksforge. Na etapa inicial, o plugin valida o tipo de um arquivo enviado. Quando o formulário é submetido, porém, aceita metadados fornecidos pelo cliente, incluindo um campo de URL em temporaryFileUploads que pode indicar um destino com extensão PHP. A validação feita no primeiro envio deixa, assim, de garantir que o arquivo será gravado com um nome seguro.

Nas tentativas descritas, o arquivo de entrada se apresenta como imagem e contém código PHP. O caminho temporário aponta para essa imagem, mas a URL enviada na submissão aponta para um arquivo PHP na área de uploads. Se o servidor executar PHP nesse destino e alguém solicitar o arquivo, o código poderá rodar. Isso explica por que a inspeção deve alcançar os arquivos efetivamente gravados, e não apenas os tipos de anexo que o formulário aparenta aceitar.

As requisições observadas se concentraram na rota REST de submissão do Bricksforge; houve também uso da ação de submissão via AJAX do WordPress. Em ambos os casos, o indício relevante é a combinação de metadados de upload temporário com um destino executável. Uma tentativa registrada no tráfego não demonstra, sozinha, que o arquivo foi criado ou executado. Já um PHP inesperado em uploads, seguido por uma requisição ao mesmo caminho, exige investigação imediata.

Qual versão corrige a falha

O histórico oficial do Bricksforge situa a correção da CVE-2026-85097 em 3.1.8.10 e 4.0.0, distingue dela outro ajuste de upload no Pro Forms em 4.0.1, de 8 de outubro, e registra novos reforços de segurança em 4.0.2, de 13 de outubro. Essa distinção importa para quem administra instalações em linhas diferentes: a versão corrigida da CVE na linha antiga e as atualizações posteriores da linha mais recente não descrevem uma única mudança de código.

A conferência deve ser feita na versão efetivamente instalada em cada site, inclusive cópias de teste acessíveis pela internet. Uma atualização automática agendada ou uma notificação no painel não basta para concluir que o plugin foi substituído. Depois da instalação, vale confirmar a versão exibida pelo WordPress e verificar se o site continua recebendo atualizações do fornecedor. Quem usa a linha mais recente deve aplicar os ajustes de segurança publicados para ela, mesmo que esta CVE específica já estivesse corrigida.

Se não for possível atualizar de imediato, uma regra temporária de firewall que restrinja as rotas de submissão do Pro Forms pode reduzir a exposição enquanto a correção é instalada. A regra precisa considerar os formulários legítimos do site, pois um bloqueio amplo também pode interromper envios de visitantes. Essa contenção atua sobre novas requisições; ela não avalia nem remove arquivos que possam ter sido gravados antes do bloqueio.

O que procurar depois de atualizar

A busca deve começar no intervalo em que o site executou uma versão vulnerável e estava acessível. Preserve os registros HTTP e da aplicação antes de limpar arquivos suspeitos. Procure submissões incomuns para /wp-json/bricksforge/v1/form_submit e para a ação AJAX bricksforge_form_submit, sobretudo quando houver metadados temporaryFileUploads. Variações rápidas de extensão ou de grafia do destino ajudam a identificar tentativas automatizadas, mas o registro da requisição precisa ser relacionado ao estado do servidor.

Examine a pasta temporária de uploads do Bricksforge e os demais diretórios de mídia do WordPress. Arquivos com extensões executáveis, nomes inesperados ou datas próximas às requisições suspeitas merecem análise; imagens comuns enviadas por usuários não constituem, por si, evidência de invasão. Compare nomes, datas e conteúdo com uma cópia confiável do site. Não abra um arquivo PHP suspeito pelo navegador para descobrir o que ele faz, pois isso pode executá-lo.

Verifique também os acessos feitos depois da criação de um arquivo suspeito. Uma resposta do servidor a uma solicitação para esse caminho pode indicar que a carga foi acionada, embora a interpretação dependa dos registros disponíveis. A inspeção não deve parar na pasta temporária: os destinos observados incluem outras áreas de uploads, e um código executado pode criar novos arquivos ou alterar componentes existentes. Mudanças recentes em plugins, temas e configurações devem ser reconciliadas com a manutenção autorizada.

Como responder a sinais de comprometimento

Se a investigação encontrar um executável inesperado ou evidência de sua execução, trate o site como possivelmente comprometido. Preserve uma cópia do artefato e dos registros, restrinja o acesso ao ambiente afetado e examine contas administrativas, permissões, usuários criados recentemente e alterações de conteúdo. Um arquivo removido da pasta de uploads pode ter servido apenas como ponto de entrada para outras mudanças; por isso, apagar o primeiro achado não encerra a análise.

Quando houver indícios de acesso indevido, remova as alterações identificadas e troque as credenciais que possam ter sido expostas, incluindo senhas administrativas e chaves usadas pelo site. A limpeza do código malicioso deve acompanhar essa troca: se ele continuar ativo, poderá capturar novas credenciais ou recriar acessos. Confronte o estado atual com uma cópia anterior confiável e registre o que foi alterado para delimitar o alcance do incidente.

Se os registros não permitirem determinar o que um arquivo executado modificou, a restauração a partir de uma cópia sabidamente íntegra pode ser necessária. Nesse caso, o site restaurado ainda precisa receber as correções antes de voltar a aceitar tráfego normal; caso contrário, o mesmo caminho de entrada permanecerá disponível.

Leia também:

• Falha no Cisco SD-WAN já dá acesso de administrador — não há atalho
• Falha do SharePoint já é explorada — versões antigas chegaram ao fim
• Chrome corrige falha explorada — versões anteriores à 152 seguem expostas