Em 5 de agosto de 2026, pesquisadores da Novee liderados por Lidor Ben Shitrit apresentaram na Black Hat USA um trabalho que revelou doze vulnerabilidades em quatro plataformas Java corporativas, incluindo duas cadeias críticas que permitem executar código no servidor sem nenhum login, na plataforma de fluxos de trabalho Bonita BPM e no Apache OFBiz, o ERP de código aberto. A conclusão prática para qualquer dono de empresa: o sistema que você considera protegido por ser interno pode ser alcançado com duas requisições do navegador se estiver exposto e sem correção. A proteção real começa com um inventário do que você roda e uma rotina de correções, e não com a confiança no perímetro da rede.

O que os pesquisadores realmente encontraram

A pesquisa não se apoiou em um único bug espetacular. Ela foi construída combinando pequenos erros comuns de middleware: diferenças na forma como uma URL é interpretada, proteção incompleta na camada que trata as requisições, chaves criptográficas fixadas no código-fonte e avaliação insegura de templates. Isoladamente, nenhum deles parece perigoso, e é exatamente por isso que passam pela revisão de código e são arquivados como baixa prioridade. Encadeados, eles produzem um caminho completo de um visitante anônimo até a execução de comandos no servidor. Das doze vulnerabilidades, quatro funcionam antes da autenticação e uma quebra o isolamento dentro da sandbox de execução.

A cadeia BadBonita: três pontos fracos formam um comprometimento total

A primeira cadeia afeta a versão 10.4.3 do Bonita BPM. Ela começa com um contorno de autenticação formado por três fraquezas interligadas: travessia de diretórios usando a notação ..;, um filtro de segurança que compara uma substring em vez do caminho completo e a lógica interna de encaminhamento de requisições. O resultado é que uma requisição chega a uma API interna que ninguém de fora deveria ver. Essa API aceita XML não confiável e o repassa diretamente à biblioteca XStream, que o desserializa, e por meio de uma conhecida cadeia de gadgets do Commons Collections o caminho termina com comandos Groovy sendo executados no servidor.

Observe que nenhuma dessas etapas exige uma senha vazada, engenharia social ou acesso prévio. Tudo o que o atacante precisa é que o sistema esteja acessível pela rede.

OFBiz: uma chave de assinatura publicada em um repositório aberto

O segundo problema, registrado como CVE-2026-31986 e classificado como crítico, afeta a versão 24.09.05 do Apache OFBiz quando o login único está ativado. O problema é que as chaves de assinatura padrão estão no código-fonte publicado abertamente e, como muitas instalações não mexem nos valores padrão, um atacante pode forjar um token SSO válido em nome de uma conta de administrador. A partir daí, a requisição passa por uma lista de bloqueio que tentava barrar palavras como java, process e import, mas a lista diferenciava maiúsculas de minúsculas e verificava padrões específicos, então basta mudar uma letra para maiúscula ou usar outro nome de classe importada automaticamente para passar. O resultado final: duas requisições GET sem autenticação bastam para chegar à execução de código em qualquer instalação que use SSO.

Por que isso importa especificamente para você

Porque nenhuma das duas é uma ferramenta marginal. O OFBiz é um ERP de código aberto que muitas empresas usam para gerenciar estoque, compras e faturamento, e o Bonita é um motor de fluxos de trabalho que conduz aprovações e procedimentos internos. Quem chega a esses dois lugares não está apenas lendo dados: está no meio do seu ciclo operacional, com pedidos de compra, preços de fornecedores, registros de funcionários e histórico de clientes. Os pesquisadores informaram que os dois fornecedores lançaram versões corrigidas dentro do prazo padrão de divulgação de noventa dias, o que significa que a atualização existe e a responsabilidade agora é de quem opera o sistema, e não de quem o construiu.

A verdadeira lacuna do mercado não é a falta de correções, é a falta de inventário. Muitas organizações não têm uma lista atualizada do que realmente rodam, em qual versão e em qual domínio. Assim, uma cópia antiga de homologação fica pendurada por dois anos em um subdomínio esquecido e vira a porta em que ninguém pensou.

O que fazer esta semana

  • Faça o inventário dos seus sistemas: uma lista escrita de cada sistema que você roda, sua versão, se está exposto à internet e quem é o responsável, com nome.
  • Atualize imediatamente o Bonita e o OFBiz para as versões corrigidas, se você usa algum deles, e leia a página oficial de segurança da Apache antes de atualizar.
  • Substitua todas as chaves padrão de criptografia ou de assinatura que vieram com o produto. Nenhum valor impresso na documentação é segredo.
  • Feche os gateways de administração para a internet aberta e acesse-os por uma rede privada ou por uma lista curta de endereços permitidos.
  • Desative as cópias antigas de homologação e os subdomínios sem uso. Eles são o alvo mais fácil e o menos monitorado.
  • Ative o registro de acessos e guarde-o. Sem registros, você não conseguirá responder depois se alguém chegou a entrar.

A lição de engenharia: a rede interna não é uma fronteira de segurança

A recomendação mais importante que sai desta pesquisa é que o roteamento interno deve ser tratado com controles no nível da internet. A velha ideia de que tudo o que está atrás do firewall é seguro falhou na prática: uma única falha de contorno de autenticação transforma cada endpoint interno em um endpoint público. Daí decorrem três regras de engenharia, que devem fazer parte dos seus padrões de desenvolvimento:

Nunca dependa de uma lista de bloqueio para proteger uma operação perigosa. Se a avaliação de expressões não é necessária em um caminho de código, remova-a por completo em vez de tentar filtrá-la.

A segunda regra é nunca condicionar uma operação sensível a uma flag de configuração ou a uma preferência do usuário que possa ser alterada de dentro do sistema. A terceira é auditar a lógica dos filtros de autenticação em busca de qualquer comparação por substring, porque esse é o erro mais repetido e mais fácil de explorar dessa categoria. Quando construímos novos sistemas de negócio na Origami, aplicamos isso por padrão: autorização explícita em cada endpoint e nenhuma confiança baseada na posição de uma requisição na rede.

O aspecto regulatório na Arábia Saudita

Se o sistema comprometido contém dados pessoais de pessoas dentro do Reino, a questão deixa de ser puramente técnica. A Lei de Proteção de Dados Pessoais (PDPL) obriga o controlador a adotar as medidas necessárias para proteger esses dados e a comunicar incidentes que afetem a sua privacidade. A Autoridade Nacional de Cibersegurança (NCA) publica controles essenciais que abrangem gestão de vulnerabilidades, aplicação de correções e gestão de ativos, que são exatamente os controles que teriam interrompido essa cadeia. Rodar uma versão antiga de um produto com uma vulnerabilidade conhecida e já corrigida é uma posição difícil de defender em qualquer auditoria.

A regra simples: trate as atualizações de segurança como um compromisso operacional mensal, com um responsável e uma data, e não como uma tarefa de emergência feita depois de um incidente.

Fontes

  • Help Net Security — detalhes das cadeias de RCE sem autenticação e do CVE-2026-31986: helpnetsecurity.com
  • Página oficial de segurança do Apache OFBiz: ofbiz.apache.org/security.html
  • Autoridade Nacional de Cibersegurança (NCA) — controles e marcos regulatórios: nca.gov.sa
  • Autoridade Saudita de Dados e Inteligência Artificial (SDAIA) — Lei de Proteção de Dados Pessoais: sdaia.gov.sa