Bricksforge: o upload seguro termina no destino, não no MIME

A Patchstack identificou exploração ativa da CVE-2026-85097 no Bricksforge, com CVSS 10,0 e possibilidade de execução de PHP sem autenticação.[1] A falha afeta versões até 3.1.8.9, foi corrigida em 3.1.8.10 e a reportagem recomenda atualizar para 4.0.1, versão mais recente citada no texto.[1]

A leitura de engenharia vai além de instalar uma correção: um upload pode passar pela primeira validação e continuar inseguro se etapas posteriores aceitarem decisões de localização e execução vindas do cliente.

O que muda para quem desenvolve

O Bricksforge verifica o MIME durante o envio, mas depois confia em metadados fornecidos na submissão do formulário, especialmente no campo url de temporaryFileUploads.[1] Isso permite que um arquivo inicialmente aceito como imagem termine em um destino executável como PHP.[1] O fluxo também permite obter um nonce sem autenticação; nesse caso, o nonce não representa autorização.[1]

O erro de projeto é tratar uma validação anterior como garantia para uma operação diferente. Minha recomendação é separar três decisões no servidor: quem pode enviar, qual objeto foi realmente armazenado e onde esse objeto pode ser utilizado. O cliente deveria referenciar um identificador controlado pelo servidor, não escolher novamente o destino físico.

Também convém distinguir identidade de proteção contra repetição ou falsificação de requisições. Um valor que acompanha a chamada não deve substituir a política de acesso ao recurso.

Como aplicar

Em um ambiente sob sua responsabilidade, organize duas frentes:

1. Correção: inventarie plugin e versão, aplique a atualização em uma janela controlada e valide formulários reais, inclusive os caminhos de erro.
2. Investigação: preserve registros antes da limpeza, examine arquivos inesperados e revise contas e mecanismos de persistência. Não encerre o incidente apenas porque o número da versão mudou.

A matéria destaca requisições contendo temporaryFileUploads, submissões repetidas e arquivos PHP inesperados no diretório temporário do plugin como pontos de investigação.[1] Use esses sinais como pistas, não como prova isolada de infecção.

Para um componente de upload próprio, crie um teste de regressão que envie metadados inconsistentes após um envio válido. O aceite deve exigir rejeição da operação, ausência de gravação fora do destino permitido e ausência de execução do conteúdo. Faça isso em ambiente descartável, com arquivos inofensivos, sem reproduzir ataques em sites de terceiros.

Cuidados e limites

Atualizar bloqueia a exploração da falha corrigida, mas não remove automaticamente um implante já instalado.[1] Por isso, correção de vulnerabilidade e recuperação do servidor precisam de evidências diferentes.

A telemetria descrita registra 63 IPs de origem, mas seus agrupamentos não permitem atribuir toda a atividade a um único grupo.[1] Evite transformar volume de requisições em certeza sobre autoria ou extensão do comprometimento.

Restringir execução em áreas de upload é uma defesa complementar que deve ser testada na configuração real. Não substitui corrigir a fronteira de confiança nem investigar o que aconteceu antes da atualização.

Fonte

[1] Fonte: The Hacker News