Uma vulnerabilidade crítica de upload de arquivo sem autenticação foi identificada no plugin Bricksforge, usado para ampliar os recursos do construtor visual Bricks Builder em sites WordPress. A falha permite que invasores, sem precisar de login, enviem e executem código PHP arbitrário nos servidores afetados — o que, na prática, abre caminho para execução remota de código (RCE). A recomendação é clara: quem utiliza o plugin deve atualizar imediatamente para a versão 3.1.8.10 ou superior.
Catalogada como CVE-2026-85097, a brecha recebeu nota máxima na escala CVSS, 10.0, classificação reservada aos riscos mais graves encontrados em softwares. Ela afeta todas as versões do Bricksforge até a 3.1.8.9, e já há correção disponível desde a versão 3.1.8.10. Por isso, organizações que ainda rodam versões vulneráveis precisam priorizar a atualização o quanto antes, já que a exploração dessa vulnerabilidade está ocorrendo ativamente, em tempo real.
Registros de monitoramento indicam que tentativas de ataque contra instalações do Bricksforge começaram a ser observadas em 7 de outubro de 2026, às 21h47 UTC. Entre os principais dados técnicos do caso estão: tipo de vulnerabilidade classificado como upload de arquivo arbitrário sem autenticação, levando a RCE; status de exploração ativa confirmado; nenhuma autenticação exigida para o ataque; versões afetadas até 3.1.8.9; e versão corrigida 3.1.8.10, conforme publicado no changelog oficial do fornecedor.
Como funciona a vulnerabilidade do Bricksforge
O Bricksforge verifica o tipo MIME de um arquivo apenas no momento do primeiro upload. No entanto, quando um formulário é enviado posteriormente, o plugin passa a confiar nos metadados do arquivo enviados pelo cliente — sem validar corretamente o campo “url” dentro do parâmetro temporaryFileUploads. Essa brecha oferece aos atacantes um caminho de quatro etapas até a execução de código:
- Solicitar um nonce válido por meio do endpoint AJAX não autenticado bricksforge_regenerate_nonce.
- Enviar um arquivo híbrido GIF/PHP: uma imagem válida que também contém código PHP embutido, capaz de passar pela checagem de tipo MIME e ser armazenada na pasta temporária de upload.
- Submeter um formulário em que o caminho do arquivo aponta para essa imagem já validada, mas cujo campo “url” termina com uma extensão PHP.
- O Bricksforge, confiando nos metadados enviados, grava o conteúdo do arquivo no local indicado em PHP. Assim, quando esse arquivo é acessado, o servidor executa o código malicioso embutido nele.
O resultado é a execução arbitrária de código PHP no servidor. A partir disso, um invasor pode instalar web shells, alterar o conteúdo do site, acessar dados sensíveis e garantir acesso persistente ao ambiente comprometido — ou seja, um comprometimento completo da infraestrutura.
O que vem sendo observado nos ataques
Praticamente todas as tentativas de exploração, com uma única exceção, tiveram como alvo o endpoint da API REST do Bricksforge responsável pelo envio de formulários (/wp-json/bricksforge/v1/form_submit). A requisição restante mirou o arquivo /wp-admin/admin-ajax.php, utilizando a ação bricksforge_form_submit. Em todos os casos, havia um parâmetro temporaryFileUploads manipulado.
Um exemplo representativo do payload observado mostra um arquivo com caminho terminando em “.gif”, enquanto o campo de destino (“url”) aponta para um arquivo “.php” — exatamente a combinação que caracteriza a tentativa de exploração. Em 95% das requisições capturadas, o caminho do lado do servidor terminava em .gif ou .png, e a maioria delas vinha acompanhada de uma URL de destino relacionada a PHP.
A maior parte dos payloads fazia referência a arquivos no diretório temporário do Bricksforge (/wp-content/uploads/bricksforge/tmp/). Contudo, alguns ataques foram além: usaram nomes de arquivo de destino no padrão login_admin_*.php para posicionar arquivos PHP diretamente no diretório padrão de uploads do WordPress, como em /wp-content/uploads/2026/10/.
Variações de payload identificadas
Os atacantes testam ativamente diferentes formas de burlar os filtros de extensão de arquivo. Foram observadas quatro categorias de variação:
- Extensões alternativas de PHP: .php, .php5, .php7, .php8, .phtml, .pht, .phtm e .phps.
- Manipulação de maiúsculas e minúsculas: .PHP, .Php, .pHp e .PHTML.
- Extensões codificadas: formas em URL-encoding e com codificação dupla, como %2ephp, .%70hp e .%2570%2568%2570.
- Metadados alterados: campos como path, name, originalFilename e url modificados ou ausentes, usados para testar como o plugin valida e processa os arquivos.
Indícios de atividade coordenada e automatizada
Dois conjuntos de dados chamam atenção nos registros analisados. No primeiro, 44 IPs enviaram 56 requisições com payloads idênticos em questão de segundos umas das outras. No segundo, três IPs testaram 25 variações de extensões PHP e codificações contra o mesmo arquivo temporário.
Ambos os padrões sugerem exploração automatizada, possivelmente por meio de proxies rotativos ou infraestrutura distribuída. Isso, porém, não permite atribuir a atividade a um único grupo ou agente de ameaça específico.
Endereços IP de origem dos ataques
Foram registrados 63 endereços IP únicos envolvidos nas tentativas de exploração. Os seis mais ativos concentraram cerca de 46% de todas as requisições, com destaque para o IP 177.75.57.20, ligado a um provedor brasileiro de internet fixa (EXPLORERNET), com apenas 8 denúncias no AbuseIPDB e sem registro em listas negras do CleanTalk. Outros endereços notáveis incluem um IP hospedado na Microsoft Azure com mais de 1.270 denúncias, além de IPs vinculados à HostRoyale, B2 Net Solutions, Tencent e Cloudzy, estes últimos já listados como maliciosos pelo CleanTalk.
A infraestrutura usada nos ataques é mista: servidores de datacenter, provedores de nuvem, serviços de VPN e proxy, além de conexões residenciais ou de ISPs de linha fixa. O endereço mais ativo, 177.75.57.20, destoa dos demais justamente por estar em um provedor fixo brasileiro, e não em um datacenter, além de ter histórico quase nulo de abusos anteriores.
Como identificar tentativas de exploração
Para quem administra sites com o Bricksforge instalado, recomenda-se revisar logs HTTP e de aplicação em busca dos seguintes indícios:
- Requisições ao endpoint /wp-json/bricksforge/v1/form_submit contendo o parâmetro temporaryFileUploads.
- Metadados de upload em que um caminho de imagem (.gif, .png) aparece associado a uma URL de destino relacionada a PHP.
- Chamadas à ação AJAX bricksforge_regenerate_nonce seguidas de upload e envio de formulário.
- Envios repetidos de formulário alternando extensões de arquivo, codificações ou variações de maiúsculas e minúsculas.
- Arquivos PHP inesperados em diretórios de upload do WordPress.
Diante do cenário de exploração ativa e da gravidade máxima atribuída à falha, a atualização imediata do Bricksforge para a versão 3.1.8.10 segue sendo a medida mais eficaz de proteção. A Plustag IA recomenda que administradores de sites WordPress que utilizam o plugin revisem seus registros em busca dos indícios listados e adotem camadas adicionais de monitoramento, já que a combinação de nota CVSS 10.0 com ataques automatizados em curso torna esse um dos casos mais sensíveis de segurança identificados recentemente no ecossistema WordPress.
Com informações de patchstack.com.
