CVE-2026-114820: atualize o Oracle Java após o incidente eMudhra

Resumo executivo

A CVE-2026-114820 afeta o componente JSSE do Oracle Java SE, Oracle GraalVM for JDK e Oracle GraalVM Enterprise Edition. A Oracle atribuiu CVSS 3.1 de 9,1 e informa que a condição pode ser explorada remotamente, sem autenticação e sem interação do usuário, por aplicações que forneçam dados às APIs afetadas.

A correção remove do cacerts quatro raízes capazes de formar cadeias para os certificados intermediários comprometidos. O risco prático é aceitar identidades digitais que deixaram de ser confiáveis, o que pode permitir falsificação de serviços e exposição ou alteração de dados quando um atacante também consegue se posicionar no caminho da comunicação. A Oracle não declarou exploração ativa, e o incidente público afirma que não se sabe se clientes fora do ecossistema de navegadores foram atacados.

Versões afetadas e corrigidas

A lista acima reproduz as versões suportadas testadas pela Oracle. O fornecedor alerta que versões anteriores fora de suporte provavelmente também são afetadas e recomenda migrar para uma versão suportada.

Impacto e evidências disponíveis

O incidente envolve as chaves privadas de oito certificados intermediários eMudhra, emitidos a partir de abril de 2025. Com uma dessas chaves, seria possível criar certificados que se apresentassem como sites ou serviços legítimos diante de clientes que ainda aceitassem a cadeia comprometida.

• A Oracle confirma impacto alto sobre confidencialidade e integridade, sem impacto direto sobre disponibilidade no vetor CVSS publicado.
• A superfície inclui serviços Java que usam JSSE para conexões TLS, aplicações que mantêm trust stores próprios, Java Web Start e applets legados dependentes do sandbox.
• O JDK corrigido remove as raízes emsignrootcag1 [jdk], emsignrootcag2 [jdk], emsigneccrootcag3 [jdk] e comodoaaaca [jdk].
• A revogação feita pela autoridade certificadora pode não proteger clientes que não consultam CRL ou OCSP. Por isso a atualização do runtime continua necessária.

Não há, nas fontes oficiais consultadas, indicador suficiente para afirmar que um servidor foi comprometido apenas por executar uma versão afetada. A análise deve considerar registros TLS, destinos acessados, certificados observados e a posição de rede do ativo.

Resposta imediata

1. Inventarie JDKs, JREs e distribuições GraalVM em servidores, estações, contêineres, ferramentas de build e aplicações empacotadas. Registre a saída de java -version e o caminho real do runtime.
2. Atualize o Oracle Java SE para o build corrigido correspondente e obtenha as correções do GraalVM pelo canal oficial. Reinicie todos os processos Java para carregar o novo runtime.
3. Quando a atualização imediata não for possível, siga a orientação oficial da Oracle: faça backup do cacerts, remova as quatro raízes listadas no aviso e reinicie as instâncias. Valide antes em homologação, pois a remoção pode interromper cadeias legítimas ainda dependentes dessas raízes.
4. Como alternativa temporária para aplicações TLS, habilite verificação de revogação com as propriedades documentadas pela Oracle e confirme que os endpoints de CRL estejam acessíveis. Isso reduz risco, mas não substitui a atualização.
5. Revise conexões TLS realizadas durante o período de exposição, especialmente em redes não confiáveis, proxies, integrações externas e fluxos de atualização. Investigue certificados, autoridades emissoras ou destinos incomuns.
6. Se houver evidência de interceptação ou identidade forjada, trate os dados e credenciais transmitidos como potencialmente expostos e acione o plano de resposta a incidentes.

Mitigação e hardening

• Mantenha um inventário por caminho e por processo: múltiplos runtimes podem coexistir, e atualizar o java padrão não altera necessariamente o runtime usado pelo serviço.
• Evite cópias privadas e desatualizadas de cacerts; quando forem necessárias, estabeleça sincronização, responsável e prazo de atualização.
• Monitore divergências do security baseline e bloqueie imagens de contêiner ou artefatos que tragam builds afetados.
• Restrinja saída de rede dos serviços Java ao necessário e monitore mudanças de destino, SNI e cadeia de certificados.
• Teste revogação, rotação de certificados e falha segura. Não aceite automaticamente conexões quando o status de revogação não puder ser determinado em fluxos sensíveis.