Planilhas com JDBC: o limite de confiança não termina nas macros

Pesquisadores demonstraram execução de código ao abrir planilhas no LibreOffice e no Apache OpenOffice, sem o aviso normalmente associado a macros, quando o suporte a Java está habilitado.[2] Até a publicação, havia uma prova de conceito, sem relatos de exploração em ataques reais.[2] Para automações de documentos, o problema relevante é a passagem de dados recebidos para carregamento de código.

O que muda para quem desenvolve

Na cadeia descrita, um intervalo de banco de dados do Calc configurado para atualização automática aponta para um arquivo ODB identificado por URL.[2] Ao abrir a planilha, o programa baixa esse arquivo; o ODB pode indicar um driver JDBC e a localização de seu código Java, em um JAR ou servidor remoto.[2] Carregar o driver executa código dentro do programa sem pedir a confiança exigida para uma macro.[2]

A consequência técnica é não usar “macros desabilitadas” como definição completa de documento seguro. O caso envolve uma composição de recursos, não apenas a presença de um script evidente.[2] Ao desenhar um conversor ou serviço de pré-visualização, proponho classificar conexões externas e resolução de drivers como capacidades executáveis. Elas deveriam ter política própria, independente do formato do arquivo.

O LibreOffice publicou correções em 05/10/2026 para a CVE-2026-63277, com versões recomendadas 26.2.5 ou 26.8.0.[2] No OpenOffice, a CVE-2026-59265 afeta todas as versões até 4.1.16, inclusive; a correção é esperada na 4.1.17, ainda em testes.[2]

Como aplicar

Comece levantando quais estações e serviços abrem planilhas externas, qual versão usam e se Java é necessário para o fluxo. Não limite o levantamento ao aplicativo instalado no desktop: inclua conversores executados em segundo plano e imagens de execução utilizadas por automações.

Atualize o LibreOffice afetado. Para OpenOffice sem correção disponível, o projeto recomenda desabilitar Java ou não abrir planilhas não confiáveis.[2] Antes de remover essa capacidade, teste os documentos e conexões de banco de dados que a aplicação realmente precisa. O objetivo é reduzir o risco sem descobrir depois que um processamento importante deixou de funcionar.

Um experimento defensivo pode usar documentos benignos em um ambiente isolado. Compare a abertura com Java habilitado e desabilitado, observe conexões externas e registre quais funções legítimas dependem delas. Não é necessário executar uma prova de conceito ofensiva para identificar uma dependência operacional. Defina também quais destinos de rede seriam permitidos a um conversor e quais credenciais jamais deveriam estar nesse ambiente.

Cuidados e limites

A demonstração abriu a calculadora para comprovar execução, mas o caminho permite outro código Java; os arquivos estavam na mesma máquina por conveniência e poderiam ser hospedados remotamente.[2] Não confunda o efeito visual do teste com o limite do impacto.

Os testes citados foram realizados em Windows e Linux, e os pesquisadores afirmam que o problema não depende de um único sistema operacional.[2] Mudar apenas a plataforma não deve ser a estratégia de correção. Desabilitar recursos pode quebrar integrações, e isolamento também tem custo. O critério útil é manter somente as capacidades necessárias, corrigir o aplicativo e testar o processamento real de documentos.

Fonte

[2] Fonte: The Hacker News