Bricksforge CVE-2026-85097 está a ser explorada: atualize o Pro Forms já

#O meu site com Bricksforge está vulnerável à CVE-2026-85097

Está, se a versão instalada for a 3.1.8.9 ou inferior. É esse o intervalo do registo no NVD e da base de dados da Wordfence. O atacante não precisa de iniciar sessão nem de qualquer clique do seu lado.

Ter um campo de upload no formulário não é condição. No registo de alterações do fabricante, a entrada da 4.0.1 diz expressamente que o problema afeta todos os sites com o Pro Forms ativo, incluindo aqueles cujos formulários não têm campos de upload. “Só temos um formulário de contacto” não é razão para adiar.

A gravidade depende da fonte. A Patchstack atribui 10.0 e marca a falha como explorada (KEV). A Wordfence e o NVD atribuem 9.8 com CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Para quem gere o site, a diferença é irrelevante: ataque pela rede, sem privilégios, impacto total.

O Bricksforge é um plugin comercial. A API de plugins do WordPress.org responde “Plugin not found”. Isso conta em dois passos mais abaixo: as atualizações chegam pela licença do fabricante, não pelo diretório, e o wp plugin verify-checksums não tem com que comparar.

#Como funciona a falha de upload no Bricksforge Pro Forms

A descrição da CVE e a análise da Patchstack descrevem três passos:

1. O atacante obtém um nonce válido através da ação AJAX bricksforge_regenerate_nonce, que responde sem autenticação.
2. Carrega um ficheiro que é ao mesmo tempo um GIF válido e PHP válido, um poliglota. A verificação de tipo MIME no primeiro upload deixa-o passar, porque o ficheiro parece mesmo uma imagem. Fica numa pasta temporária.
3. Envia um formulário com o parâmetro temporaryFileUploads manipulado. O caminho no servidor aponta para o GIF validado, mas o campo url termina em .php. O plugin confia nos metadados enviados pelo cliente e grava o conteúdo num caminho PHP.

A Patchstack indica dois pontos de entrada: POST /wp-json/bricksforge/v1/form_submit e /wp-admin/admin-ajax.php com a ação bricksforge_form_submit. O código afetado está em includes/elements/pro-forms/actions/init.php e base.php. Segundo o registo da CVE, o fabricante foi notificado a 3 de setembro de 2026 e a divulgação aconteceu a 7 de outubro. O investigador creditado é d.v4n_s3c.

#Como verificar a versão do Bricksforge no wp-admin e no WP-CLI

No painel: Plugins, Plugins instalados, linha do Bricksforge, número da versão por baixo da descrição. Se a licença expirou, o painel pode não mostrar uma atualização que existe. A ausência de aviso não prova que está em dia.

Por SSH, para um site:

wp plugin list --name=bricksforge --fields=name,status,version,update_version

Se gere vários sites de clientes no mesmo servidor, um ciclo dá-lhe o inventário em segundos:

for d in /home/*/public_html; do
  printf '%s ' "$d"
  wp --path="$d" plugin get bricksforge --field=version 2>/dev/null || echo "nao instalado"
done

O padrão /home/*/public_html é o habitual em servidores com cPanel. Ajuste-o à sua estrutura. Tudo o que esteja na 3.1.8.9 ou abaixo entra na lista de atualização e verificação.

#Devo atualizar o Bricksforge para a 3.1.8.10 ou para a 4.0.1

As fontes não coincidem, e convém sabê-lo antes de carregar em Atualizar.

• A Patchstack e a Wordfence indicam ambas a 3.1.8.10 como versão corrigida.
• O registo de alterações do fabricante, a 10 de outubro de 2026, não tem entrada para a 3.1.8.10. Lista a 3.1.8.9 (28 de agosto), a 4.0.0 (17 de setembro) e a 4.0.1 (8 de outubro), esta com o título “Security fix for the Pro Forms file upload”.

A regra prática: depois de atualizar, a versão tem de ser a 3.1.8.10, ou a 4.0.1 ou superior. Se está na 4.0.0, passe para a 4.0.1. Nenhuma das fontes diz expressamente se a 4.0.0 é vulnerável, mas o fabricante publicou a correção do upload na 4.0.1, por isso não há motivo para ficar.

wp plugin update bricksforge
wp plugin get bricksforge --field=version

Se o WP-CLI não vir a atualização, descarregue o zip na sua conta de cliente do fabricante e instale a partir do ficheiro: wp plugin install /tmp/bricksforge.zip --force. A passagem para a 4.x é uma versão principal nova. Num site com formulários complexos, teste primeiro em staging, mas hoje e não na próxima semana.

Não consegue atualizar já? Desative o plugin (wp plugin deactivate bricksforge) ou bloqueie os dois endpoints na WAF. A Patchstack aplicou uma regra RapidMitigate para esta CVE aos seus clientes. A própria Patchstack trata-a como medida provisória, não como substituto da atualização.

#O que verificar se o site correu o Bricksforge 3.1.8.9 ou anterior

A atualização fecha a porta. Não expulsa quem já entrou. O dia 7 de outubro é a primeira observação na telemetria da Patchstack, não a prova de que ninguém tentou antes. Reveja, por isso, uma janela mais larga, por exemplo desde 3 de setembro, quando o fabricante foi notificado.

#Novas contas de administrador

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Compare com as pessoas que conhece. Uma conta criada nas últimas semanas, com endereço num domínio estranho ou um nome de utilizador como wp-support, justifica uma investigação completa. Verifique também as palavras-passe de aplicação: wp user application-password list <ID> para cada administrador.

#Ficheiros PHP na pasta de uploads

Em wp-content/uploads não deve existir PHP executável. A Patchstack encontrou ficheiros chamados login_admin_*.php em /wp-content/uploads/bricksforge/tmp/ e /wp-content/uploads/2026/10/.

find wp-content/uploads -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \) -ls
find wp-content/uploads -type f -name 'login_admin_*' -ls
ls -la wp-content/uploads/bricksforge/tmp/

O padrão *.php* com -iname apanha também .php5 e .PHP. A Patchstack descreve variantes de extensão, de maiúsculas e minúsculas e de codificação nos payloads, por isso não procure apenas .php exato. Procure também ficheiros .htaccess estranhos nos uploads, porque podem pôr outras extensões a correr como PHP.

#Ficheiros alterados no núcleo, temas e plugins

wp core verify-checksums
find wp-content -type f -name '*.php' -newermt '2026-09-03' ! -path '*/cache/*' -ls

O núcleo verifica-se por somas de controlo. O Bricksforge e o Bricks não estão no WordPress.org, por isso descarregue cópias limpas do fabricante e compare com diff -r. Dê atenção especial a wp-content/mu-plugins, onde o código carrega sempre e nunca aparece na lista de plugins, e ao wp-config.php.

#Tarefas agendadas

wp cron event list --fields=hook,next_run_relative,recurrence
crontab -l

Hooks desconhecidos no WP-Cron, ou uma linha no crontab que vai buscar algo a um endereço externo, são a forma clássica de voltar a entrar depois de apagada a webshell.

#Registos do servidor

Procure os endpoints do relatório da Patchstack:

grep -E 'bricksforge/v1/form_submit|bricksforge_regenerate_nonce|bricksforge_form_submit' access.log*
zgrep -E 'bricksforge/v1/form_submit' access.log*.gz
grep -E '^(177\.75\.57\.20|23\.97\.62\.146|84\.247\.60\.125|38\.154\.185\.97|150\.109\.16\.166|153\.75\.90\.146) ' access.log*
grep -E 'GET /wp-content/uploads/.*\.php' access.log*

Estes seis endereços são os mais ativos dos 63 IP únicos que a Patchstack contou na campanha. Uma limitação: um registo de acesso normal guarda apenas o URL, e o nome da ação AJAX segue muitas vezes no corpo do POST. Um pedido a admin-ajax.php pode nem ter “bricksforge” no registo. Nesse caso, cruze por IP e hora. O sinal mais forte é um GET bem-sucedido a um ficheiro .php em uploads, com código 200.

#Quando repor o WordPress a partir de uma cópia de segurança

Um ficheiro PHP nos uploads que não consegue explicar, ou uma conta de administrador desconhecida, chega para tratar o site como comprometido. O código que correu no servidor teve acesso à base de dados, aos ficheiros e ao wp-config.php. Apagar um ficheiro à mão não lhe diz se era o único.

A ordem que funciona:

1. Guarde o estado atual, ficheiros e base de dados, como prova, antes de apagar o que quer que seja.
2. Reponha os ficheiros a partir de uma cópia anterior à primeira entrada suspeita nos registos. Se os registos não recuam tanto, escolha uma cópia anterior a 3 de setembro e volte a introduzir à mão o conteúdo posterior.
3. Atualize o Bricksforge para a 3.1.8.10 ou a 4.0.1 antes de o site voltar a estar online. A cópia reposta traz a versão antiga e vulnerável.
4. Mude as palavras-passe da base de dados, do SFTP e de todos os administradores, gere novas chaves no wp-config.php (wp config shuffle-salts) e revogue as palavras-passe de aplicação.

Os formulários do Pro Forms costumam recolher nomes, emails e mensagens. Se o atacante teve acesso à base de dados, pode tratar-se de uma violação de dados pessoais nos termos do artigo 33.º do RGPD, a notificar à CNPD no prazo de 72 horas após ter tido conhecimento, salvo se for improvável que resulte num risco para os titulares. Documente o que encontrou, mesmo que no fim a notificação não seja necessária.

Se a verificação não encontrar nada, não precisa de repor. Registe o que verificou e quando.

#Quarta falha no Bricksforge em 2026

A lista da Wordfence mostra entradas anteriores do mesmo ano: CVE-2026-14956 (até à 3.1.8.6, escalada de privilégios sem autenticação através do Pro Forms, 9.8), CVE-2026-18030 (até à 3.1.8.7, escalada de privilégios sem autenticação através da reposição de palavra-passe, 9.8) e CVE-2026-84814 (até à 3.1.8.8, escalada de privilégios a partir de subscritor, 6.3). Três das quatro mexem em formulários ou na lógica de início de sessão.

Não é razão para arrancar o plugin à pressa. É razão para o Bricksforge ser um ponto que alguém verifica todas as semanas nos sites de clientes, e não uma vez por trimestre.

#Como um contrato de manutenção apanha uma falha destas

Uma falha explorada sem autenticação dá-lhe dias, às vezes horas. Um contrato de manutenção de sites WordPress deve cobrir as três coisas que aqui decidem o resultado:

• um inventário de plugins e versões por site, incluindo os comerciais, porque o aviso de atualização do diretório não chega a plugins fora do WordPress.org,
• alertas de vulnerabilidades (Patchstack, Wordfence, NVD) cruzados com esse inventário, para que o alerta do Bricksforge chegue a alguém que sabe que o usa,
• registos de acesso guardados mais do que alguns dias, porque sem eles a pergunta “alguém entrou antes da atualização” fica sem resposta.

Se não tem a certeza de que o seu site passou esta semana limpo, uma auditoria de segurança WordPress cobre exatamente os passos desta lista: uploads, contas, cron, somas de controlo e registos.

Última atualização a 10 de outubro de 2026. Fontes: artigo e entrada na base de dados da Patchstack (7 e 8 de outubro de 2026), registo da Wordfence Intelligence, registo do NVD para a CVE-2026-85097, registo de alterações do Bricksforge, artigo 33.º do RGPD.