Falha no Java (CVE-2026-114820): eMudhra e como corrigir

Novo alerta de emergência no Java: a CVE-2026-114820 remove as raízes da eMudhra e afeta até quem atualizou essa semana. Veja como checar e corrigir.

Se você atualizou o Java essa semana por causa do problema com os certificados da eMudhra, vai precisar mexer de novo. Em 24/10/2026, a Oracle e o OpenJDK publicaram um segundo alerta de emergência, a CVE-2026-114820 (CVSS 3.1 de 9.1, crítica). Desta vez a correção remove do Java as autoridades certificadoras (CAs) raiz ligadas à eMudhra. E as builds lançadas depois do primeiro alerta, de 21/10, também aparecem na lista de afetadas.

Resumindo: confira a versão de cada Java que você roda, instale a build que cita JDK-8395690 (no Oracle JDK ela já saiu: 25.0.5.0.3, 21.0.13.0.3, 17.0.21.0.3, 11.0.33.0.3 e 8u511-b33) ou, se o seu fornecedor ainda não lançou, remova as quatro raízes do truststore, e reinicie todas as JVMs. No Debian e no Ubuntu, atualizar o ca-certificates não basta. Abaixo está o passo a passo para cada tipo de instalação.

O que aconteceu: dois alertas da eMudhra em quatro dias

21/10: CVE-2026-91403, as CAs intermediárias

Em 21/10/2026, a Oracle publicou o Security Alert CVE-2026-91403, fora do ciclo trimestral normal. Segundo o aviso do OpenJDK, as chaves privadas de oito certificados de CAs intermediárias da eMudhra foram comprometidas. A atualização daquele dia passou a desconfiar dessas intermediárias no Java.

Componente: JSSE (javax.net.ssl), que cuida do TLS no Java.
Nota: CVSS 3.1 de 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N): explorável pela rede, sem login e sem interação do usuário, com impacto alto em confidencialidade e integridade.
Afetados (Oracle): Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 e 27.0.1; GraalVM for JDK 17.0.21 e 21.0.13; GraalVM Enterprise 21.3.20.
Afetados (OpenJDK, 21/10): 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.32.1, 8u504 e anteriores.

Depois disso, o OpenJDK publicou as builds 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2 e 17.0.21.0.2, e muita gente atualizou.

24/10: CVE-2026-114820, as CAs raiz

Três dias depois veio o Security Alert CVE-2026-114820 (Rev 1, 24/10/2026). Nas palavras da Oracle, a atualização "remove o conjunto de certificados de CA raiz impactados relacionados à eMudhra". A nota e o vetor são os mesmos do primeiro alerta: 9.1, pela rede, sem autenticação, no componente JSSE.

O OpenJDK pede ação imediata, "mesmo que você tenha atualizado o seu runtime nos últimos dias".

Quem está afetado pela CVE-2026-114820

Todas as linhas suportadas do Java: 8, 11, 17, 21, 25 e 27.

Oracle Java SE: 8u511-b32, 8u511-perf-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2 e 27.0.1.0.2.
Oracle GraalVM for JDK: 17.0.21.0.2 e 21.0.13.0.2.
Oracle GraalVM Enterprise Edition: 21.3.20.0.2.
OpenJDK (aviso de 24/10): 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.32.1, 8u504 e anteriores. Componente: security-libs/javax.net.ssl.

A Oracle lembra que versões fora do suporte não são testadas, mas que "é provável" que também sejam afetadas. Se você roda um Java antigo, considere que ele está no grupo de risco.

Atenção: as builds .0.2 são justamente as que corrigiram o alerta de 21/10. Se você instalou uma delas essa semana, ela também precisa de ação.

Passo 1: descubra onde tem Java

Rode em cada servidor, container e runner de CI:

# versão do Java na máquina
java -version

# versão do Java dentro de uma imagem Docker
docker run --rm IMAGEM java -version

# raízes da eMudhra no truststore padrão (JDK 11+)
keytool -list -cacerts -storepass changeit | grep -i emsign

# JDK 8
keytool -list -keystore $JDK_HOME/jre/lib/security/cacerts -storepass changeit | grep -i emsign

Se aparecer alguma linha com emsign, as raízes da eMudhra ainda estão no truststore desse Java. O changeit é a senha padrão do cacerts; se você trocou, use a sua.

O OpenJDK também oferece um programa oficial para a checagem, o CheckCerts.java, que funciona do JDK 8 em diante. O link está na página openjdk.org/emudhra.

Não esqueça das imagens base, dos runners de CI e daquele servidor antigo que ninguém lembra. Se você baixa imagens do Docker Hub sem fixar versão, vale reler por que a tag latest mente.

Passo 2: descubra que tipo de Java você tem

O que fazer depende de onde o Java veio, porque cada instalação usa um truststore diferente.

Java standalone (baixado de um fornecedor, como Oracle ou Temurin, inclusive dentro de imagens Docker que trazem o JDK pronto): usa o próprio arquivo cacerts. Siga o Passo 3.
Java da distribuição Linux (instalado pelo apt, dnf, pacman etc.): normalmente usa os certificados do sistema operacional. Siga o Passo 4.
Homebrew (macOS) e FreeBSD: o pacote do Java não usa os certificados do sistema. No Homebrew, o openjdk já chegou à 27.0.1.0.3 (brew upgrade openjdk); o openjdk@21 e o openjdk@17 ainda estavam na .0.2 em 25/10, então neles remova as raízes até sair a atualização.

Mais de um Java na mesma máquina? Cada instalação conta separadamente.

Passo 3: Java standalone

Opção preferida: atualizar o Java

Instale a build nova do seu fornecedor. Segundo o OpenJDK, a release note da build corrigida precisa citar o JDK-8395690 / CVE-2026-114820.

Atualização de 25/10/2026: a Oracle já publicou as builds corrigidas do Oracle JDK. Elas saíram em 24/10 e as notas de versão citam o JDK-8395690, a remoção das quatro raízes e a CVE-2026-114820:

Java 25: 25.0.5.0.3
Java 21: 21.0.13.0.3
Java 17: 17.0.21.0.3
Java 11: 11.0.33.0.3
Java 8: 8u511-b33 (versão completa 1.8.0_511-b33)
Java 27: 27.0.1.0.3

Se você usa o Oracle JDK, o java -version precisa mostrar uma dessas versões ou uma mais nova. Os instaladores estão na página de downloads da Oracle.

Em outros fornecedores, a situação na manhã de 25/10 era outra. As últimas builds do Amazon Corretto (21.0.13.0.10, 25.0.5.0.9, 17.0.21.0.10, de 23/10) e do Eclipse Temurin (25.0.5+8, 21.0.13+9 e 17.0.21+9, de 22/10) saíram antes do alerta e não citam o JDK-8395690. No Homebrew, a fórmula openjdk já está na 27.0.1.0.3, mas openjdk@21 e openjdk@17 continuam na .0.2. Para esses casos, siga o OpenJDK: remova as raízes como explicado abaixo, reinicie as JVMs e atualize quando a nota do fornecedor citar o JDK-8395690.

Enquanto isso: remover as raízes do truststore

Faça backup do keystore. No JDK 11 ou mais novo, o arquivo é $JDK_HOME/lib/security/cacerts. No JDK 8, é $JDK_HOME/jre/lib/security/cacerts.

cp $JDK_HOME/lib/security/cacerts ~/cacerts.bak-$(date +%F)

Remova os quatro certificados. No JDK 11 ou mais novo:

keytool -delete -cacerts -alias "emsignrootcag1 [jdk]"
keytool -delete -cacerts -alias "emsignrootcag2 [jdk]"
keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

No JDK 8:

keytool -delete -keystore $JDK_HOME/jre/lib/security/cacerts -alias "emsignrootcag1 [jdk]"
keytool -delete -keystore $JDK_HOME/jre/lib/security/cacerts -alias "emsignrootcag2 [jdk]"
keytool -delete -keystore $JDK_HOME/jre/lib/security/cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -keystore $JDK_HOME/jre/lib/security/cacerts -alias "comodoaaaca [jdk]"

Se aparecer um erro dizendo que o certificado não existe, pode ignorar.
Reinicie todas as instâncias do Java em execução. O truststore é lido quando a JVM sobe; sem restart, nada muda.
Repita em cada instalação de Java standalone da máquina.

Alternativa: ligar a checagem de revogação

O OpenJDK aceita também, como terceira opção, ativar a checagem de certificados revogados. Para aplicações que usam TLS, se ainda não estiver ligado, acrescente ao comando java:

-Dcom.sun.net.ssl.checkRevocation=true
-Dcom.sun.security.enableCRLDP=true

Para JARs assinados, no JDK 17 ou mais novo, verifique cada arquivo com:

jarsigner -verify -revcheck -strict ARQUIVO.jar

Passo 4: Java instalado pela distribuição Linux

Arch, Fedora, Gentoo, Oracle Linux e RHEL

Nessas distribuições, o OpenJDK do pacote usa os certificados do sistema operacional. Segundo o OpenJDK, atualizar os certificados do sistema provavelmente basta. No RHEL e no Fedora, por exemplo:

sudo dnf upgrade ca-certificates

Depois, reinicie as aplicações Java.

Debian, Ubuntu e Devuan: atualizar não basta

Aqui está a pegadinha. Esses runtimes deveriam usar os certificados do pacote ca-certificates por meio do pacote ca-certificates-java. Mas, por causa de um bug antigo no ca-certificates-java, atualizar os dois pacotes não é suficiente.

O workaround oficial é apagar e recriar o keystore Java do sistema, como root:

sudo rm -f /etc/ssl/certs/java/cacerts
sudo update-ca-certificates --fresh

Depois, reinicie todas as JVMs. Se as suas imagens Docker são baseadas em Debian ou Ubuntu e instalam o OpenJDK pelo apt, o mesmo vale para elas: inclua esses comandos no Dockerfile (sem sudo, já que o build roda como root por padrão), reconstrua a imagem e recrie os containers.

Homebrew e FreeBSD

Os pacotes de OpenJDK do Homebrew e do FreeBSD não usam os certificados do sistema. Atualize o pacote do Java diretamente assim que a atualização estiver disponível.

Passo 5: Docker e Kubernetes

Atualizar o Java no host não muda nada dentro dos containers. Para cada imagem que tem Java:

Aplique a correção na imagem (build nova do JDK, remoção das raízes ou o workaround do Debian/Ubuntu).
Reconstrua sem cache, para não reaproveitar a camada antiga: docker build --pull --no-cache -t app .
Publique a imagem e recrie todos os containers e pods com ela.

Se você administra vários containers em um servidor, um painel ajuda a ver o que ficou para trás. Comparamos opções em Portainer, Dockge, Komodo e Dockyard.

Passo 6: confira depois da correção

Rode java -version de novo em todos os ambientes: servidores, containers, imagens e runners de CI.
Se atualizou, confira que a release note da build instalada cita o JDK-8395690 (no Oracle JDK: 25.0.5.0.3, 21.0.13.0.3, 17.0.21.0.3, 11.0.33.0.3, 1.8.0_511-b33 ou mais novo).
O keytool -list ... | grep -i emsign deve voltar vazio, e o CheckCerts.java deve passar.
Nenhuma JVM antiga rodando: tudo reiniciado, imagens refeitas e pods recriados.
Revise truststores próprios (o .jks da aplicação ou o arquivo passado em javax.net.ssl.trustStore): a atualização do Java não mexe neles.

Para não ser pego de surpresa por certificados no futuro, veja também como criar alerta para certificado TLS que vence.

Perguntas frequentes

Já atualizei por causa do alerta de 21/10. Estou seguro?

Não necessariamente. As builds .0.2 lançadas depois de 21/10 estão na lista de afetadas pela CVE-2026-114820. No Oracle JDK, suba para a .0.3 (ou 8u511-b33). Nos outros fornecedores, remova as raízes até sair a build que cita JDK-8395690.

Uso o Java do Ubuntu e já rodei apt upgrade. Resolve?

Não. Por causa do bug no ca-certificates-java, você precisa apagar e recriar o /etc/ssl/certs/java/cacerts com update-ca-certificates --fresh, como mostrado no Passo 4.

Remover as raízes pode quebrar alguma coisa?

Conexões TLS para servidores cujo certificado depende dessas CAs deixam de ser aceitas pelo Java. Esse é exatamente o efeito que a correção oficial busca. Se algum serviço legítimo parar, ele precisa trocar de certificado.

Qual a diferença entre as duas CVEs?

A CVE-2026-91403 (21/10) tratou das CAs intermediárias da eMudhra cujas chaves foram comprometidas. A CVE-2026-114820 (24/10) remove as CAs raiz relacionadas à eMudhra do truststore do Java.

Resumo

O quê: CVE-2026-114820, CVSS 9.1, JSSE. Segundo alerta da eMudhra em quatro dias.
Quem: Java 8, 11, 17, 21, 25 e 27, inclusive as builds .0.2 lançadas depois de 21/10, e GraalVM.
Standalone: Oracle JDK já corrigido em 25.0.5.0.3, 21.0.13.0.3, 17.0.21.0.3, 11.0.33.0.3, 8u511-b33 e 27.0.1.0.3; Corretto, Temurin e outros, keytool -delete das quatro raízes e restart até sair a build com JDK-8395690.
RHEL e família: atualize os certificados do sistema.
Debian/Ubuntu: rm -f /etc/ssl/certs/java/cacerts + update-ca-certificates --fresh.
Homebrew/FreeBSD: openjdk do Homebrew já na 27.0.1.0.3; nas outras versões, remova as raízes até sair a atualização.
Sempre: reinicie toda JVM e recrie os containers.

Fontes: Oracle Security Alert CVE-2026-114820, Oracle Security Alert CVE-2026-91403, OpenJDK Vulnerability Advisory 24/10/2026, OpenJDK Vulnerability Advisory 21/10/2026, OpenJDK: Compromised Certificates and OpenJDK Java Runtimes, CVE.org. Atualizado em 25/10/2026.