flawopen.com/Incidents/bricksforge-pro-forms-upload-metadata-october-2026

● Bricksforge WordPress plugin · CVE-2026-85097 · 2026-10-07 · CVSS 9.8 · Crítica

Pesquisa · FlawOpen

CVE-2026-85097 no Bricksforge: falha de upload no Pro Forms

A CVE-2026-85097 permitia que solicitações sem autenticação explorassem a divergência entre o conteúdo validado de um arquivo temporário e os metadados de destino controlados pelo cliente no Bricksforge Pro Forms. A Patchstack relata tentativas de exploração; atualize o plugin e investigue sites expostos.^{[1], [2], [3], [4], [5]}

💡 Explicação em Linguagem Simples (ELI5)

Imagine uma central de correspondência que confere se um pacote contém uma imagem inofensiva e depois permite que o remetente troque a etiqueta antes de enviá-lo a um escritório que abre certos tipos de etiqueta como programas. O Bricksforge verificava o upload temporário, mas o envio posterior do formulário podia fornecer outro nome de destino. A defesa é manter a identidade e o destino do arquivo sob controle do servidor durante todo o armazenamento.^{[3], [2]}

Conceitos Centrais e Termos

Upload temporário: Arquivo armazenado provisoriamente antes de o envio do formulário terminar. A validação nessa etapa não torna confiáveis metadados enviados pelo cliente depois.^{[2], [3]}
CWE-434: Upload irrestrito de tipo perigoso: o sistema aceita um arquivo que pode ser interpretado ou executado de forma perigosa.^{[1], [2]}
Limite de confiança dos metadados: Ponto em que a aplicação decide se nome, URL, tipo MIME ou caminho vêm de um registro confiável do servidor ou de um cliente não confiável.^{[2], [3]}
Pontuação CVE e exploração: O registro CVE da CNA Wordfence atribui CVSS 3.1 9.8 e o enriquecimento da CISA informa que não há exploração. A Patchstack atribui 10.0 e relata telemetria observada pela primeira vez em 7 de outubro de 2026. São registros atribuídos separadamente; nenhum confirma inclusão no CISA KEV.^{[1], [2], [3], [4]}
Código ilustrativo: A comparação PHP abaixo representa genericamente o limite de validação. Não é código do Bricksforge nem uma reconstrução do patch; o changelog citado não publica esses detalhes.^{[2], [3], [5]}

Mapeamentos de frameworks

Referência CWE para a fraqueza descrita neste guia: CWE-434

Status de versão relatado e ação do operador

Fonte da evidência	O que informa	Ação defensiva
Registro CNA da Wordfence / CVE	Descreve upload arbitrário de arquivos sem autenticação; o intervalo afetado registrado termina na versão 3.1.8.9.	Use isso como o escopo registrado pela CNA, não como prova de que uma instalação está limpa.
Patchstack (8 out. 2026)	Relata tentativas de exploração observadas pela primeira vez em 7 de outubro e identifica a 3.1.8.10 como corrigida.	Trate isso como o limite de correção informado pela Patchstack; verifique a versão efetivamente instalada em cada site.
Changelog público da Bricksforge	A versão 4.0.1 lista uma correção de segurança de upload no Pro Forms, mas não identifica o limite da 3.1.8.10.	Não conclua apenas pelo changelog que a 4.0.1 foi a primeira versão corrigida ou que uma versão 3.x específica é segura.
Site exposto ou com suspeita de comprometimento	As fontes descrevem tentativas de exploração, não provam que todos os sites visados foram comprometidos.	Atualize para uma versão atualmente suportada; analise os logs de upload e do servidor web e investigue arquivos inesperados antes de declarar a recuperação.

Linha do Tempo do Incidente

2026-10-07

A Wordfence informa 7 de outubro como data de publicação pública do aviso. A Patchstack afirma que sua telemetria observou as primeiras tentativas nesse dia, às 21:47 UTC; publicação do aviso e observação de telemetria são eventos distintos.^{[2], [3]}

2026-10-08

O registro CVE indica datePublished como 8 de outubro, um dia depois da data de publicação pública da Wordfence, 7 de outubro. O relatório da campanha da Patchstack também informa publicação em 8 de outubro; são datas de registros e publicações distintos.^{[1], [2], [3]}

2026-10-08

A análise da Patchstack de 8 de outubro descreve a divergência de validação e as tentativas observadas, e identifica a versão 3.1.8.10 como corrigida. O changelog da Bricksforge lista separadamente uma correção de segurança de upload do Pro Forms na 4.0.1, mas não estabelece o limite exato da correção na série 3.x.^{[3], [4], [5]}

Fluxo de Ataque Passo a Paso

Passo 1

Um arquivo temporário passa por uma verificação inicial

A CNA descreve um upload temporário anterior que passa pela validação MIME. Isso não autoriza alterações posteriores arbitrárias no nome ou no destino do arquivo.^{[2], [1]}

Passo 2

O envio do formulário fornece metadados separados

A Patchstack relata que o processamento posterior confiava nos metadados temporaryFileUploads enviados pelo cliente, inclusive uma URL que podia divergir do arquivo já validado. A falha está em confiar no conteúdo verificado e não verificar os metadados de destino.^{[2], [3]}

Passo 3

O arquivo recebe um nome perigoso

Quando o servidor usa esse destino controlado pelo cliente para concluir o upload, uma extensão perigosa pode levar à interpretação no servidor se o destino permitir execução. Esta descrição explica a falha em alto nível; não é necessário fornecer formato de requisição ou payload.^{[2], [3]}

Passo 4

A exposição pode comprometer o servidor

A CNA afirma que o problema pode permitir execução arbitrária de PHP. A Patchstack relata tentativas e recomenda atualização. Essas observações não provam que todo site visado foi comprometido nem identificam um ator de ameaça.^{[2], [3]}

Código-Fonte: Vulnerável vs. Seguro

Este exemplo genérico demonstra identidade de upload controlada pelo servidor, busca por usuário, nova verificação do tipo do conteúdo, nomes gerados e armazenamento privado. Não é código do Bricksforge nem seu patch real. O código de produção também deve impor limites de tamanho, permissões seguras, transições atômicas de estado e entrega apropriada ao contexto; a correção direta para sites afetados é atualizar o Bricksforge para uma versão corrigida e compatível.^{[2], [3]}

IMPLEMENTAÇÃO VULNERÁVEL

function finalize_upload( array $item, string $stagedPath, string $uploadDir ): string {
    // Os metadados do cliente escolhem o nome final após uma verificação MIME anterior.
    $name = basename( (string) parse_url( $item['file']['url'], PHP_URL_PATH ) );
    $destination = $uploadDir . DIRECTORY_SEPARATOR . $name;
    if ( ! rename( $stagedPath, $destination ) ) {
        throw new RuntimeException( 'Could not finalize upload' );
    }
    return $destination;
}

PATCH SEGURO E ROBUSTO

function finalize_upload( string $uploadId, UploadRegistry $registry, string $privateDir ): string {
    // Obtenha o proprietário e o caminho de um registro no servidor, nunca de uma URL do cliente.
    $upload = $registry->findPendingForCurrentUser( $uploadId );
    if ( $upload === null || ! is_file( $upload->path ) ) {
        throw new RuntimeException( 'Unknown pending upload' );
    }
    $types = [ 'image/jpeg' => 'jpg', 'image/png' => 'png' ];
    $mime = ( new finfo( FILEINFO_MIME_TYPE ) )->file( $upload->path );
    if ( ! isset( $types[ $mime ] ) ) {
        throw new RuntimeException( 'Unsupported file type' );
    }
    $destination = $privateDir . DIRECTORY_SEPARATOR . bin2hex( random_bytes( 16 ) ) . '.' . $types[ $mime ];
    if ( ! rename( $upload->path, $destination ) ) {
        throw new RuntimeException( 'Could not finalize upload' );
    }
    $registry->markConsumed( $uploadId );
    return $destination;
}

Lista de Verificação de Segurança para Engenharia

✓Inventarie as versões do Bricksforge em produção, homologação e sites de clientes gerenciados; atualize instalações afetadas para a versão mais recente compatível com o fornecedor. A Patchstack identifica 3.1.8.10 como corrigida, enquanto o changelog do fornecedor documenta a correção em 4.0.1 sem indicar o limite exato da linha 3.x.^{[1], [2], [3], [4], [5]}
✓Orientação operacional da FlawOpen: Trate todo nome, URL, caminho e rótulo MIME enviado pelo cliente como não confiável na finalização; derive nome e caminho armazenados de um registro de upload do servidor e de uma lista permitida baseada no conteúdo inspecionado.
✓Orientação operacional da FlawOpen: Armazene uploads fora de raízes web executáveis sempre que possível; caso contrário, configure o servidor web para negar execução de scripts em todos os diretórios de upload e temporários.
✓Orientação operacional da FlawOpen: Associe cada registro temporário à sessão de formulário que o criou, use-o uma única vez e rejeite identificadores ausentes, expirados, repetidos ou incompatíveis.
✓Orientação operacional da FlawOpen: Se um site vulnerável ficou acessível publicamente, revise logs web e da aplicação em busca de atividade incomum de upload e arquivos recém-criados; preserve evidências e siga o processo de resposta a incidentes do provedor antes da limpeza.
✓Orientação operacional da FlawOpen: Adicione testes de regressão para metadados divergentes, conteúdo não permitido, IDs de outra sessão, IDs expirados e repetidos; confirme a rejeição e que nenhum arquivo é gravado em local executável.