Seu sistema pode confiar em certificados eMudhra comprometidos?

O caso interessa a quem mantém aplicações que verificam certificados TLS, administra infraestrutura Cloudflare ou distribui imagens de contêiner. Em 20 de outubro, a Cloudflare informou que oito certificados intermediários da eMudhra tiveram suas chaves privadas comprometidas. Essas autoridades intermediárias eram aceitas por navegadores, sistemas operacionais e serviços da própria Cloudflare.

Uma chave intermediária comprometida pode ser usada para emitir um certificado falso dentro das condições de confiança que ainda aceitem aquela cadeia. Isso cria a possibilidade de um servidor fraudulento se passar por outro durante uma conexão. A falha não significa que o TLS foi quebrado, nem que o certificado de todo site foi roubado. O problema está na confiança em certificados de uma cadeia específica e na velocidade com que cada produto atualiza sua lista de confiança.

A Cloudflare afirmou que sua investigação não identificou exploração ativa nos serviços da empresa. Ainda assim, a organização publicou correções para produtos e orientações para clientes que mantêm configurações próprias.

O risco não é que todo HTTPS esteja quebrado: é que aplicações e serviços ainda confiem em uma cadeia de certificados comprometida.

Quando você abre um site HTTPS, o navegador não recebe apenas um certificado isolado. Ele confere uma cadeia que liga o certificado do domínio a uma autoridade reconhecida. Uma autoridade intermediária pode emitir certificados para outros serviços dentro das regras de confiança aceitas pelos clientes.

Se a chave privada dessa autoridade sai do controle, alguém pode tentar produzir certificados falsos que pareçam válidos para sistemas desatualizados. Navegadores e serviços de segurança podem revogar ou deixar de confiar nos certificados afetados. Aplicações que carregam um repositório próprio de certificados, uma imagem antiga ou uma cópia embutida de uma biblioteca podem demorar mais para receber a mudança.

É por isso que atualizar apenas o código da aplicação nem sempre resolve. A validação pode acontecer no sistema operacional, no runtime, em uma biblioteca HTTP ou em um pacote de certificados que foi incluído na imagem do contêiner.

Comece pelo inventário de componentes. O comunicado da Cloudflare recomenda atenção especial a clientes que operam Cloudflare Tunnel, autenticação TLS mútua, certificados de origem personalizados, Cloudflare Containers ou aplicações com repositórios de confiança próprios.

Se você usa Cloudflare Tunnel, a orientação é atualizar o cloudflared para a versão 2026.10.2 e reconstruir ou redeployar a imagem nos ambientes containerizados. Se sua aplicação valida certificados de cliente por mTLS, revise o arquivo de autoridades que você carregou. Se usa Full (strict) ou Strict para conectar a Cloudflare ao servidor de origem, confira os certificados e a configuração do seu origin server.

Uma equipe que mantém uma API em Node.js também deve verificar a atualização de segurança publicada em 21 de outubro. O projeto lançou Node.js 22.23.4, 24.22.1 e 26.12.1 e incluiu uma atualização do pacote ca-cert associada ao comprometimento eMudhra. O mesmo release corrige outras falhas de segurança, portanto não é uma atualização exclusiva de certificados.

Liste os caminhos que fazem conexões HTTPS de saída: backend Node.js, worker em segundo plano, integração com gateway de pagamento, SDK de nuvem, container de processamento e chamadas de APIs de terceiros. Não olhe apenas para a tela do navegador. Uma aplicação de servidor pode usar outro runtime ou um conjunto de certificados diferente.

Procure também repositórios customizados, arquivos CA incluídos no projeto, variáveis como NODE_EXTRA_CA_CERTS e imagens de contêiner antigas. A intenção é descobrir de onde vem a política de confiança. Atualizar um SDK pode não mudar o certificado raiz se a validação for feita pelo sistema operacional ou por uma biblioteca separada.

Para um inventário inicial de dependências JavaScript, consulte o arquivo de lock e pesquise por pacotes que embutem autoridades de certificação ou implementam TLS. Faça isso como triagem, não como prova de que a aplicação está vulnerável ou corrigida.

npm ls --all

Se o projeto usa pnpm ou Yarn, prefira o comando equivalente à ferramenta de lockfile adotada. Registre o runtime, a imagem base e as dependências usadas no deploy, porque o ambiente local pode não ter os mesmos certificados da produção.

Em um projeto Node.js, compare a versão que está em execução com a linha mantida e com as versões de segurança publicadas. Confira a versão local:

node --version
npm --version

Atualize o Node.js para a versão corrigida da sua linha e teste a aplicação. Se o runtime vem de uma imagem Docker, altere a imagem base para a versão de segurança, reconstrua a imagem e redeploye todos os serviços que a utilizam. Não basta atualizar o Node na máquina do desenvolvedor se a produção continua na imagem antiga.

Para clientes Cloudflare, aplique a versão indicada para o produto específico. Uma atualização do cloudflared não substitui a revisão de um repositório mTLS personalizado. Da mesma forma, atualizar o WARP não altera automaticamente um servidor de origem administrado pela sua equipe.

Depois do patch, faça uma chamada de teste pela aplicação real e verifique os logs. Se seu serviço usa Node.js, teste o processo Node; se usa um container, teste dentro da imagem atualizada; se tem uma biblioteca HTTP com trust store customizado, execute a validação a partir dessa biblioteca. Um teste no navegador confirma apenas o caminho daquele navegador.

A Cloudflare também aponta um site de acompanhamento do incidente, com verificações no navegador e instruções para outros ambientes. Use o resultado como sinal para o caminho testado, não como atestado universal de todos os processos da máquina. Se o teste passar mas o worker continuar usando um container antigo, a aplicação ainda pode estar desprotegida.

Quando o patch for ativado, erros de certificado podem surgir porque um certificado anteriormente aceito deixou de ser confiável. Isso pode interromper uma integração legítima que ainda não foi atualizada. Identifique o host, a biblioteca e o certificado da cadeia antes de agir. Não desligue a validação TLS para fazer a conexão voltar.

Nunca use NODE_TLS_REJECT_UNAUTHORIZED=0 como correção: isso desativa a verificação que impede conexões com servidores falsos.

Registre quais componentes foram atualizados, a versão anterior, a versão aplicada e o teste realizado. Para os serviços Cloudflare, consulte a tabela de ação do comunicado, pois cada produto tem uma correção diferente. Para pacotes do ecossistema, procure uma versão corrigida e confirme se ela entrou no arquivo de lock e na imagem publicada.

Se você administra apenas um site comum em hospedagem gerenciada e não usa certificados próprios, cloudflared, mTLS ou imagens de servidor controladas por você, peça ao fornecedor uma confirmação sobre o caminho de confiança. A matéria não deve levar o dono de qualquer site a substituir seu certificado público sem uma indicação de que ele pertence à cadeia afetada.

O objetivo é atualizar aquilo que realmente participa da validação TLS. Um inventário curto e um teste pelo caminho real ajudam mais do que reinstalar certificados de forma indiscriminada.