O que você precisa fazer: atualizar o plugin Bricksforge para a versão 3.1.8.10 em todo site WordPress que o tenha instalado, e depois procurar arquivo PHP inesperado nos diretórios de upload. A CVE-2026-85097 recebeu nota 10.0, não exige autenticação nenhuma e permite gravar e executar PHP arbitrário no servidor. Versões afetadas: 3.1.8.9 e anteriores. A exploração em massa começou em 7 de outubro às 21h47 UTC, antes da divulgação pública, e a Patchstack registrou 63 endereços de origem distintos, com os seis mais ativos respondendo por cerca de 46% das requisições. Atualizar o plugin fecha a porta, mas não remove o que entrou por ela: parte das cargas observadas gravou arquivos com nome no padrão login_admin_ no diretório comum de uploads do WordPress, e não apenas na pasta temporária do plugin. Site que rodou versão vulnerável sem proteção na camada de tráfego precisa de revisão de log e de inspeção de arquivo, não só de atualização.
A falha não está em verificar o arquivo. Está em verificar uma vez e depois acreditar no cliente sobre onde gravar.
Como a cadeia funciona
O Bricksforge é um complemento do construtor Bricks, e a parte afetada é o módulo de formulários profissionais. O tratamento do parâmetro temporaryFileUploads checa o tipo MIME no momento em que o arquivo sobe. Depois, na submissão do formulário, o plugin passa a confiar em metadado fornecido pelo cliente e não valida o campo url, que define o caminho de destino. O código envolvido está em includes/elements/pro-forms/actions/init.php e em base.php.
Com isso, a exploração tem quatro passos e nenhum deles pede credencial:
- Chamar a ação AJAX
bricksforge_regenerate_nonce, que responde sem autenticação, e obter um nonce válido. - Subir um arquivo híbrido, GIF e PHP no mesmo conteúdo, que passa pela checagem de imagem e fica no diretório temporário de upload.
- Enviar o formulário apontando o caminho do arquivo para a imagem, mas com o campo
urlterminando em extensão PHP. - O plugin grava o conteúdo no destino PHP. Na primeira requisição àquele endereço, o servidor executa.
O resultado é execução remota de código com o privilégio do processo do servidor web: shell, alteração de conteúdo, leitura de banco e acesso persistente.
O que apareceu no tráfego
A maior parte das requisições foi para POST /wp-json/bricksforge/v1/form_submit. Houve ao menos uma pelo caminho antigo, em /wp-admin/admin-ajax.php com a ação bricksforge_form_submit. Quem tiver regra de bloqueio por endpoint precisa cobrir os dois.
| Medida | Observado |
|---|---|
| Primeira tentativa registrada | 7 de outubro de 2026, 21h47 UTC |
| Endereços de origem distintos | 63 |
| Concentração nos seis mais ativos | cerca de 46% das requisições |
| Varredura com carga idêntica | 44 endereços |
| Teste de variação de filtro | 3 endereços, 25 variações |
| Infraestrutura | datacenter, nuvem, VPN e proxy, e banda larga residencial |
A mistura de infraestrutura é o detalhe operacional que estraga a resposta fácil. Bloquear faixa de datacenter resolve parte do volume e deixa passar o resto, porque há origem em provedor residencial no mesmo conjunto.
O que procurar, e onde
- Submissão de formulário com
temporaryFileUploadsem que o caminho do arquivo é imagem e o destino termina em PHP. É a assinatura direta. - Requisição ao gerador de nonce seguida de upload e de submissão, na mesma origem e em intervalo curto.
- Arquivo PHP inesperado em diretório de upload, com atenção ao padrão
login_admin_. Procurar no diretório padrão do WordPress, e não apenas no temporário do plugin. - Requisição a arquivo PHP recém-criado em caminho de upload. Upload não executa nada por si; a execução é a requisição seguinte.
- Variação de caixa de letra e de codificação na extensão, que indica tentativa de contornar filtro e não erro de cliente.
Para quem precisa de ordem de prioridade: primeiro atualizar para 3.1.8.10; se não for possível agora, bloquear o padrão na camada de tráfego; depois revisar log histórico desde 7 de outubro e inspecionar o sistema de arquivos. Trocar senha de administrador antes de remover o que foi gravado não serve para nada, porque o shell não usa senha.
O que muda para quem opera no Brasil
- O inventário de plugin é o inventário de software. Agência e provedor que mantêm dezenas ou centenas de sites raramente têm lista de qual plugin está em qual site, em qual versão. Sem essa lista, a resposta a um aviso como este é visitar painel por painel, e isso leva dias que a exploração não dá.
- Nota 10.0 sem autenticação muda o prazo, não a nota. Falha que dispensa login em componente de formulário público não tem janela de manutenção. O critério prático é a hora, não a próxima quinta-feira.
- Site institucional é caminho para dentro. O site de marketing costuma estar fora do escopo do time de segurança e dentro do mesmo domínio de e-mail, do mesmo provedor e, às vezes, da mesma rede de administração. O shell no site vira ponto de partida.
- Dado pessoal em formulário de contato também é dado pessoal. Execução de código em um site que recebe formulário de lead, de candidatura ou de atendimento alcança registro de titular, e essa é a conversa que a LGPD puxa depois.
Leitura LATAMSEC
Tem um padrão nessa classe de falha que vale separar do caso. A validação aconteceu, e aconteceu no lugar certo: no upload. O que não aconteceu foi tratar o caminho de destino como entrada hostil. Entre a checagem e a gravação existe um segundo ponto de confiança que quase nenhuma revisão de código olha, porque o campo parece interno quando se lê o arquivo de cima para baixo.
A outra coisa que fica é o descompasso de velocidade. A exploração começou antes do aviso público e em escala, com varredura automatizada e um grupo pequeno refinando evasão em paralelo. A versão corrigida existir é condição necessária e insuficiente: o parque instalado é que decide o resultado, e ele atualiza no ritmo de quem administra, não no ritmo de quem ataca.
Outros sinais do dia
- Cronologia
A primeira tentativa foi registrada em 7 de outubro às 21h47 UTC
A Patchstack diz que sua regra de mitigação na camada de tráfego já estava ativa antes do primeiro ataque, e publicou a análise no dia 8. Quem depende só do ciclo de atualização do plugin ficou atrás da exploração.
- Automação
Quarenta e quatro endereços enviaram o mesmo payload e três testaram vinte e cinco variações
A telemetria mostra dois comportamentos distintos no mesmo período: varredura em massa com carga idêntica e um grupo pequeno iterando filtro. Os seis endereços mais ativos respondem por cerca de 46% das requisições.
- Persistência
Parte das cargas gravou arquivos login_admin_ fora do diretório temporário do plugin
Os arquivos apareceram no diretório normal de uploads do WordPress. Quem for caçar só na pasta temporária do Bricksforge vai achar o site limpo e continuar com shell no ar.
- Evasão
A variação ataca o filtro, não o código
As tentativas alternaram extensão PHP, caixa de letra, codificação simples e dupla na URL e campos de metadado. É o padrão de quem sabe que a correção do fornecedor chega antes da correção do cliente.
Fontes e aprofundamento
- Patchstack · Critical Unauthenticated Arbitrary File Upload Vulnerability Exploited in Bricksforge Plugin, com a cadeia de exploração, os endpoints usados, a telemetria de 63 endereços e os indicadores.
- Rapid7 · CVE-2026-85097 (Bricksforge arbitrary file upload), com a ficha da falha e as versões afetadas.
- BugShield · Bricksforge vulnerability: update to 3.1.8.10 as attacks target file uploads, com a orientação de atualização e a leitura para quem administra vários sites.
- Codeflamme · Bricksforge CVE-2026-85097 RCE: Agency Patch Plan, com o plano de correção para agência que mantém parque de sites.