Voltar

2026/10/30

Os navegadores foram protegidos em horas. E o Java corporativo? Como a LOGIQ respondeu ao incidente de certificados da eMudhra

Navegadores bloquearam os intermediários da eMudhra em horas, mas cada JDK tem seu próprio trust store. O que Azul, BellSoft e LOGIQ fizeram e o que verificar.

Principais conclusões

  • Em 17 de outubro de 2026, a Mozilla recebeu um relato de que as chaves privadas de oito certificados de CA intermediária da eMudhra haviam sido comprometidas. Os navegadores os bloquearam em questão de horas a dias. A eMudhra afirma não ter conhecimento de nenhuma evidência de que as chaves tenham sido exploradas.
  • O Java não usa as decisões de confiança do navegador nem do sistema operacional. Cada JDK, e cada imagem de contêiner ou aplicação que inclui um, carrega seu próprio trust store. Cada um deles precisa de sua própria atualização.
  • A Azul lançou duas atualizações extraordinárias do Zulu, em 21 e 24 de outubro. A segunda existe porque a primeira correção não foi suficiente; por isso, o paliativo de 21 de outubro, sozinho, já não basta.
  • A BellSoft lista builds corrigidos do Liberica para Java 8, 11, 17, 21, 25 e 27. A LOGIQ obteve esses builds por meio do nosso canal de suporte da BellSoft e os disponibilizou aos nossos clientes.
  • O que fazer: localize todos os runtimes Java que você executa, verifique o fornecedor e o build exatos, migre para o build corrigido desse fornecedor, teste suas conexões TLS e continue acompanhando lançamentos extraordinários.

O que aconteceu

No sábado, 17 de outubro de 2026, às 20:06 UTC, a Mozilla recebeu um relato de que as chaves privadas de oito certificados intermediários da eMudhra haviam sido comprometidas. A Mozilla bloqueou os oito certificados no Firefox por meio do OneCRL, sua lista central de revogação, e a atualização chegou aos usuários com configurações padrão até as 22:59 UTC, menos de três horas depois. A Mozilla divulgou o incidente publicamente em 20 de outubro. Também lançou versões pontuais do Firefox para usuários cujas configurações bloqueavam a atualização do OneCRL e removeu do trust store do NSS o certificado raiz que assinou os intermediários.

O risco é a falsificação de certificados. Quem tivesse uma dessas chaves poderia emitir um certificado HTTPS para um site que não controla. Se também conseguisse se posicionar entre um cliente e esse site, poderia se passar por ele e ler ou alterar o tráfego.

Até o momento, não há evidência de que isso tenha acontecido. Em sua declaração sobre o incidente, a eMudhra afirma que os oito intermediários foram revogados em 18 de outubro, que nenhum deles havia emitido certificados de entidade final e que “não tem conhecimento de nenhuma evidência de que as chaves fracas tenham sido recuperadas ou exploradas por alguém antes da divulgação do problema”. A eMudhra descreve a causa como chaves fracas geradas durante uma cerimônia de chaves em 2025. Diz que ainda não confirmou a causa raiz exata e que sua investigação continua em andamento. Os programas de raízes dos navegadores deixaram de confiar, por precaução, na raiz da eMudhra acima desses intermediários.

Portanto, este artigo trata de fechar uma janela de exposição, não de um ataque confirmado.

Por que o Java precisa de sua própria correção

Navegadores e sistemas operacionais têm mecanismos automáticos para deixar de confiar em uma autoridade certificadora, e os usaram rapidamente. Segundo o relato da Azul sobre o incidente, o Chrome bloqueou os certificados no mesmo dia, a Apple em 19 de outubro e a Microsoft em 20 de outubro.

O Java não herda nada disso. Um JDK decide em quais certificados confiar com base em seus próprios arquivos:

  • Seu próprio trust store. Cada JDK traz seu próprio arquivo cacerts. Atualizar o pacote de certificados do sistema operacional, ou reiniciar um navegador, não o altera.
  • Sem verificação de revogação por padrão. Como diz a documentação da Azul, o Java confia nos certificados raiz aos quais esses intermediários se encadeiam e “não verifica a revogação por padrão”. A revogação dos intermediários pela eMudhra, por si só, não protege um cliente Java.
  • Muitas cópias. Um servidor pode executar o JDK do sistema, um JDK incluído em uma aplicação, um runtime jlink e várias imagens de contêiner, cada um com sua própria cópia do trust store. Cada cópia permanece exposta até ser atualizada ou reconstruída.

Assim, um serviço Java que faz chamadas TLS de saída ainda pode aceitar um certificado falsificado mesmo depois de todos os navegadores da empresa estarem protegidos. É dessa lacuna que trata este artigo.

Duas atualizações emergenciais da Azul

A Azul lançou duas atualizações extraordinárias do Azul Zulu após seu lançamento trimestral de outubro:

  • 21 de outubro: a primeira atualização extraordinária adiciona os oito intermediários comprometidos à lista de bloqueio do JDK (blocked.certs no JDK 11 e posteriores, blacklisted.certs em versões mais antigas). Ela abrange o Zulu 27, 25, 21, 17, 11, 8, 7 e 6. A lista de CVEs da Azul a registra como CVE-2026-91403. Para runtimes que não podiam ser atualizados de imediato, a Azul também publicou um paliativo manual que substitui o arquivo da lista de bloqueio.
  • 24 de outubro: a Azul constatou que a lista de bloqueio não resolvia totalmente o problema. A segunda atualização extraordinária corrige a CVE-2026-114820 (JSSE, pontuação base 9.1) removendo completamente determinados certificados de CA do cacerts. No momento em que este artigo foi escrito, esses builds estão disponíveis para a linha CPU da Azul, somente de segurança, tanto na base CPU de outubro de 2026 (por exemplo, Zulu 21.53.114, 17.69.114, 11.91.114 e 8.97.0.112) quanto na base CPU de julho de 2026. A Azul diz que os builds PSU “provavelmente” virão em uma atualização separada.

A atualização de 24 de outubro muda a recomendação. A página do paliativo da Azul agora avisa que ele “já não resolve totalmente o problema”, e a Azul orienta todos os clientes a atualizar para a versão mais recente. Se você aplicou a atualização de 21 de outubro ou o paliativo, ainda precisa do build de 24 de outubro. Em seu próprio relato, a Azul afirma que levou cerca de 12 horas desde a decisão de gerar novos builds até que os builds somente de segurança estivessem nas mãos dos clientes.

O que a BellSoft lançou para o Liberica JDK

A BellSoft publicou seu lançamento regular de outubro de 2026 do Liberica JDK em 21 de outubro. Esse lançamento trimestral lista 52 CVEs corrigidas e inclui builds CPU para Java 6 e 7 (6u521 e 7u521). Suas notas de versão não tratam do problema da eMudhra.

A BellSoft aborda a eMudhra em um guia separado, “Distrusting compromised eMudhra intermediates in Java” (atualizado pela última vez em 27 de outubro). Ele lista como builds corrigidos o Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 e 27.0.1.0.3+5. Para sistemas que ainda não podem ser atualizados, o guia apresenta uma mitigação temporária: remover as raízes afetadas do trust store. Ele alerta que isso pode quebrar cadeias de certificados legítimas e deve ser testado antes.

Dois pontos são importantes ao comparar fornecedores:

  • As listas de CVEs não são iguais. A Azul e a BellSoft publicam, cada uma, sua própria lista de CVEs para o ciclo de outubro, e as contagens e observações diferem. Os dois IDs de CVE da Azul citados acima vêm dos registros da Azul. O guia da BellSoft não os menciona. Consulte as notas de versão do seu fornecedor para saber as correções exatas do seu build e não presuma que a lista de um fornecedor se aplica ao JDK de outro.
  • Java 6 e 7 não constam da lista da BellSoft sobre a eMudhra. Os builds mais recentes de Java 6 e 7 da BellSoft estão disponíveis, mas a lista de builds corrigidos em seu guia sobre a eMudhra começa no Java 8. Se você executa o Liberica 6 ou 7, pergunte se o seu build inclui a alteração no trust store antes de confiar nele, ou aplique a mitigação do fornecedor. A Azul lista builds de 24 de outubro para o Zulu 6 e 7.

Como a LOGIQ respondeu

Distribuímos builds Java da BellSoft e da Azul aos nossos clientes e os ajudamos a migrar de versões mais antigas do Oracle JDK. Veja o que fizemos, com a situação de cada item no momento em que este artigo foi escrito (29 de outubro).

Concluído

  • 21–22 de outubro: avisos dos fornecedores analisados. Recebemos e analisamos o aviso de atualização extraordinária da Azul de 21 de outubro e o aviso de lançamento de outubro de 2026 da BellSoft. No mesmo dia, abrimos tarefas de download e de repositório para ambos os fornecedores. Tratamos os dois lançamentos separadamente e não presumimos que o lançamento trimestral da BellSoft contivesse a mesma correção para a eMudhra que o da Azul.
  • 23 de outubro: builds trimestrais do Liberica preparados. Baixamos os builds do Liberica JDK de outubro de 2026 do portal de suporte da BellSoft e os adicionamos ao repositório do qual nossos clientes fazem download.
  • 24–25 de outubro: segunda atualização da Azul acompanhada. Recebemos o aviso da Azul de 24 de outubro, incluindo sua recomendação de atualizar mesmo que o build de 21 de outubro já estivesse instalado.
  • 27–28 de outubro: builds corrigidos do Liberica obtidos por meio da BellSoft. Por meio de nossa relação de suporte comercial, pedimos à BellSoft que disponibilizasse os builds mais recentes em nosso portal de suporte. A BellSoft os carregou em 28 de outubro, incluindo os builds corrigidos para Java 8, 11, 17, 21, 25 e 27 e os builds mais recentes de Java 6 e 7. Alguns clientes ainda precisam do Java 8 de 32 bits, por isso também pedimos à BellSoft que adicionasse ao nosso portal os instaladores 8u513+9 de 32 bits para Windows e Linux. A BellSoft os adicionou no mesmo dia.
  • 28–29 de outubro: repositório e mapeamentos de migração atualizados. Adicionamos esses builds ao nosso repositório de downloads para clientes e atualizamos nossas orientações de migração do Oracle JDK para o Liberica para apontar para eles, com revisão da atualização por um segundo engenheiro.

Clientes do Azul Zulu

Os builds da Azul de 21 e 24 de outubro estão disponíveis aos assinantes da Azul por meio da própria Azul. O build adequado depende da sua versão do Java, de você usar a linha CPU ou PSU e de qual base (outubro ou julho) você utiliza. Consulte as notas de versão da Azul para o seu build exato, ou fale conosco e ajudaremos a identificá-lo.

Java 6 e 7 legados

Alguns clientes ainda executam Java 6 ou 7, muitas vezes em aplicações que não podem ser migradas rapidamente. A Oracle não fornece mais atualizações públicas para essas versões, mas isso não significa que não haja opções. Ajudamos clientes a migrar de builds antigos do Oracle JDK 6 e 7 para os builds mais recentes do Liberica JDK 6 e 7, e os builds de outubro de 2026 da BellSoft para ambas as versões estão disponíveis para nós por meio do portal de suporte da BellSoft. Quando falta uma correção ou um pacote de que precisamos para essas versões, escalamos a questão à BellSoft por meio do nosso canal de suporte comercial. Para este incidente, veja a observação acima: confirme que o seu build de Java 6 ou 7 inclui a alteração no trust store referente à eMudhra antes de confiar nele.

O que você deve fazer agora

1. Localize todos os runtimes Java

Liste todos os lugares onde o Java é executado, não apenas o JDK do sistema. Isso inclui servidores de aplicação, runtimes incluídos em produtos de fornecedores, imagens jlink, agentes de build de CI e todas as imagens de contêiner. No Linux, este comando encontra os binários Java em um host:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

Para imagens de contêiner, execute a verificação dentro da imagem, por exemplo docker run --rm --entrypoint java <image> -version.

2. Verifique o fornecedor e o build exatos

A versão principal não basta. Você precisa do fornecedor e do número de build completo para comparar com a lista de builds corrigidos do fornecedor:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

Como indicador rápido, você também pode listar as raízes da eMudhra (emSign) no trust store de um runtime:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

Em nossos testes com as imagens de contêiner públicas da BellSoft, um build mais antigo do Liberica 21.0.10 listou cinco raízes emSign, enquanto os builds corrigidos 21.0.13.0.3+5 e 8u513 não listaram nenhuma. Um resultado vazio é um bom sinal, mas não uma prova. A correção da Azul de 21 de outubro, por exemplo, bloqueou os intermediários sem remover raízes. O número do build é a verificação confiável. Nosso artigo anterior sobre como verificar os truststores do Java traz verificações mais detalhadas.

3. Obtenha o patch mais recente aplicável

  • Azul Zulu: migre para o build extraordinário de 24 de outubro da sua linha (CPU ou PSU, base de outubro ou de julho), mesmo que tenha instalado o build de 21 de outubro ou aplicado o paliativo. Se você usa builds PSU, acompanhe o lançamento PSU complementar da Azul.
  • Liberica JDK: migre para os builds corrigidos listados pela BellSoft (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
  • Outros fornecedores e runtimes incluídos em produtos: consulte o comunicado de segurança desse fornecedor. Um JDK dentro de um produto de terceiros é atualizado pelo fornecedor desse produto, não pelas atualizações do seu sistema operacional.
  • Contêineres: reconstrua as imagens sobre uma imagem base corrigida e faça um novo deploy. Aplicar patch em um contêiner em execução não altera a imagem.

4. Valide o TLS antes e durante a implantação

Remover raízes de um trust store pode quebrar conexões legítimas, por exemplo com sites que ainda usam certificados encadeados às raízes da eMudhra removidas. A eMudhra afirma que está reemitindo os certificados de clientes afetados a partir de uma hierarquia de CA alternativa. Antes de uma implantação ampla, teste as conexões TLS de saída das quais suas aplicações dependem, especialmente com parceiros ou serviços que possam usar certificados da eMudhra. Implante em etapas, reinicie os processos Java para que carreguem o novo trust store e, depois, confirme a versão em execução.

5. Acompanhe os lançamentos extraordinários

Este incidente gerou dois lançamentos emergenciais de Java em quatro dias, e outros podem vir, como os builds PSU da Azul. Assine os avisos de segurança dos seus fornecedores, consulte diretamente as páginas de lançamentos deles em vez de depender apenas de e-mail e planeje atualizações do Java fora do calendário trimestral.

A lição

Os usuários do Firefox foram protegidos em poucas horas porque os navegadores têm seus próprios trust stores e um mecanismo automático para atualizá-los. O Java corporativo tem muitos trust stores, nenhuma verificação de revogação por padrão e atualizações que esperam alguém instalá-las. Fechar essa lacuna exige um inventário preciso, números de build exatos, acesso rápido aos builds dos fornecedores e um processo que não espere o próximo patch trimestral. Se precisar de ajuda para localizar ou atualizar os runtimes Java do seu ambiente, entre em contato com a LOGIQ.

Referências