Chaves da eMudhra comprometidas: o que atualizar já para evitar sites e APIs falsos

No dia 19 de outubro de 2026 tornou-se público um problema grave numa autoridade de certificação, a eMudhra: as chaves privadas de oito certificados intermédios foram geradas de forma tão fraca que qualquer pessoa as consegue recuperar em menos de um segundo num portátil normal. Com uma dessas chaves, um atacante pode criar um certificado HTTPS válido para qualquer site e fazer-se passar por ele perante os programas que ainda confiam nesses certificados.

Os navegadores já estão protegidos. O risco está agora nos servidores, nas aplicações e nos scripts que fazem pedidos HTTPS sem passar por um navegador: o site que chama a API de pagamentos, o servidor que envia faturas para um serviço externo, a integração com o CRM. Este artigo explica o que aconteceu, quem está exposto e o que deve atualizar esta semana.

O que aconteceu, ao certo

A eMudhra é uma autoridade de certificação indiana, uma das entidades que emitem os certificados que garantem que o cadeado do navegador corresponde mesmo ao site certo. Segundo o aviso do DSCI, a própria eMudhra gerou as chaves numa cerimónia a 30 de abril de 2025. Uma chave P-384 devia ser um número aleatório enorme. As oito chaves afetadas são todas inferiores a 256, o que deixa, no máximo, cerca de 8 bits de segurança.

A eMudhra explicou a 21 de outubro que uma falha no processo criou um segundo par de chaves fracas, ao lado das chaves fortes, e que foram as fracas as enviadas para os navegadores. A empresa garante que a sua infraestrutura não foi comprometida e que não houve fuga de dados.

A cronologia, segundo os avisos oficiais:

• 17 de outubro: um investigador, identificado como Wayne, comunica o problema à Apple, à Google, à Microsoft, à Mozilla e à eMudhra, e prova que controla as chaves assinando a mensagem "We have a problem here" com cada uma delas.
• 17 de outubro: o Chrome e o Firefox bloqueiam os certificados em poucas horas, sem que os utilizadores precisem de atualizar o navegador.
• 18 de outubro: a eMudhra revoga os oito certificados intermédios.
• 19 de outubro: o problema é divulgado às outras listas de certificados de confiança (sistemas operativos, linguagens e bibliotecas).
• 20 de outubro: bloqueio nos sistemas da Microsoft. A Mozilla retira do NSS 3.131.1 a raiz que assinou estes certificados, a emSign ECC Root CA - G3.
• 21 de outubro: saem as versões corrigidas do Node.js.
• 22 de outubro: bloqueio nos produtos da Apple.
• 27 de outubro: a Google prevê retirar a mesma raiz da lista de confiança do Chrome.

Das oito chaves, seis são de certificados para sites (TLS) e duas para assinar software. Cada chave aparece também num certificado com assinatura cruzada da Sectigo, através da raiz antiga "AAA Certificate Services", por isso há 16 certificados afetados. As chaves já foram recuperadas e publicadas por outras pessoas, por isso devem ser tratadas como públicas.

Qual é o risco: sites e APIs falsos

Um certificado diz ao programa "este servidor é mesmo o banco, a loja ou a API que procura". Quem tiver uma destas chaves pode emitir um certificado para qualquer domínio, incluindo o seu. Um atacante que consiga ficar no meio da ligação, numa rede Wi-Fi pública, num router comprometido ou num fornecedor de internet, pode então:

• fazer-se passar por um site ou serviço legítimo sem que apareça qualquer aviso;
• ler o tráfego, incluindo palavras-passe, chaves de API e dados de clientes;
• alterar as respostas, por exemplo trocar o IBAN de um pagamento ou injetar código num ficheiro descarregado.

As duas chaves de assinatura de código permitiam ainda falsificar assinaturas de programas em sistemas Microsoft.

Há uma boa notícia. Os navegadores modernos (Chrome, Firefox, Edge e Safari) exigem que os certificados fiquem registados em listas públicas, a Certificate Transparency. Não há registos de certificados emitidos por estes intermédios, por isso, segundo a Google e a página do incidente, os navegadores não podiam ter sido atacados. Muitos programas fora do navegador, como o curl e a maioria das bibliotecas de HTTP, não fazem essa verificação. Não se sabe se alguém explorou a falha contra eles desde abril de 2025.

Quem está exposto

A sua empresa pode estar exposta mesmo que nunca tenha comprado um certificado à eMudhra. O problema não está no certificado do seu site, mas nos programas que confiam em certificados alheios. Segundo a página do incidente, mantida pela comunidade, estão em risco:

• servidores e aplicações em Node.js, Python, Go, Rust, Bun, Elixir, PHP ou Java que fazem pedidos HTTPS a APIs externas (pagamentos, faturação, email, CRM, IA);
• programas que trazem a sua própria lista de certificados, como o certifi do Python ou o Node.js, que não usam a lista do sistema;
• contentores Docker construídos com uma imagem antiga, que mantêm a lista de certificados do dia em que foram criados;
• aplicações Electron, como o Slack e o Discord, que só ficam protegidas quando são atualizadas para uma versão feita com o Electron corrigido;
• ferramentas de linha de comandos como o curl, o git e o pip, e equipamentos com software embebido que não verificam revogações.

Se usa um navegador atualizado para ir ao banco ou ao email, está protegido. Se o seu site em WordPress, Laravel ou Next.js corre num servidor que fala com outros serviços, esse servidor tem de ser atualizado.

Há ainda um segundo caso: se o certificado do seu próprio site foi emitido pela eMudhra e depende da raiz emSign ECC Root CA - G3, a Google avisa que deixa de funcionar no Chrome. Nesse caso tem de instalar já um certificado de outra autoridade, por exemplo um gratuito do Let's Encrypt.

Versões corrigidas

Componente	Atualizar para	Notas
Node.js	22.23.4, 24.22.1 ou 26.12.1 (ou mais recente da mesma linha)	As versões anteriores à 22 já não têm suporte e não foram corrigidas
Python (certifi)	2026.10.19 ou mais recente	Usado pelo Requests, HTTPX e muitas outras bibliotecas
Bun	1.4.4
Go	1.27.3 ou 1.26.10
Rust (rustls-webpki)	0.103.16	Rejeita as chaves comprometidas
Rust (webpki-roots / webpki-root-certs)	1.0.10
Elixir (castore)	1.0.22	Usado pelo Req, Finch, Mint e Tesla
PHP (Composer ca-bundle)	1.4.16 ou 1.6.0	O PHP usa sobretudo a lista do sistema
Debian ca-certificates	20250419~deb12u2 (12), 20250419+deb13u1 (13)
Ubuntu ca-certificates	20260816ubuntu0.22.04.1, 20260816ubuntu0.24.04.1, 20260816ubuntu0.26.04.1 ou 20260816ubuntu0.26.10.1
Arch Linux ca-certificates-mozilla	3.131.1-1
Alpine ca-certificates	20261020-r0	Muito usado em imagens Docker
Docker Desktop / Docker Engine	4.96.2 / 29.9.2

A lista completa, com Java, Deno, Electron, VS Code, Tailscale e outras ferramentas, está na página do incidente.

O que fazer esta semana

1. Atualize o Node.js em todos os servidores e na configuração de build do alojamento (Vercel, Netlify, Render ou um VPS) para a 22.23.4, a 24.22.1 ou a 26.12.1. Se não puder atualizar já, a Render indica como solução provisória acrescentar --use-openssl-ca à variável NODE_OPTIONS e retirar --use-bundled-ca e --use-system-ca, se estiverem lá.
2. Atualize o certifi em Python. No requirements.txt, ponha certifi>=2026.10.19. Com o uv, corra uv lock --upgrade-package certifi. Com o Poetry, poetry update certifi.
3. Atualize as outras linguagens: Bun 1.4.4, Go 1.27.3, e em Rust cargo update -p rustls-webpki e cargo update -p webpki-roots. Em Elixir, mix deps.update castore.
4. Atualize a lista de certificados do sistema em cada servidor e VPS. Em Debian e Ubuntu: sudo apt update && sudo apt install --only-upgrade ca-certificates. Em Arch: sudo pacman -Syu. Em Alpine: apk upgrade ca-certificates. É esta lista que o PHP, o curl e o git usam.
5. Reconstrua as imagens Docker. Atualize a imagem base, instale a versão mais recente do ca-certificates no Dockerfile e volte a publicar a imagem. Um contentor antigo não se atualiza sozinho.
6. Volte a fazer deploy e reinicie os processos. As ligações TLS retomadas antes da atualização só são verificadas de novo quando expiram, por isso reinicie os processos Node.js que ficam muito tempo ligados.
7. Teste se ficou protegido. A partir do próprio servidor e com o cliente HTTP da sua aplicação, faça um pedido a https://dv-g3b-emudhra.we-have-a-problem.com/ e a https://dv-g3b-aaa-emudhra.we-have-a-problem.com/. Os dois pedidos têm de falhar com um erro de certificado. Se algum funcionar, mesmo com um erro HTTP, o programa ainda confia nos certificados comprometidos.
8. Atualize os computadores da equipa: sistema operativo, navegador, Slack, Discord, VS Code e outras aplicações. No macOS, o curl, o git e o Python de origem usam um ficheiro de certificados que a Apple ainda vai atualizar.
9. Verifique o certificado do seu site. Se foi emitido pela eMudhra, substitua-o já por um de outra autoridade.

Um pormenor importante para o teste: um curl feito no terminal do servidor pode usar uma lista de certificados diferente da que a aplicação usa. O teste que conta é o que é feito pela própria aplicação.

Uma lição sobre a confiança na internet

Este caso mostra que a segurança de um site não depende só do seu código. Depende também de uma cadeia de confiança que inclui autoridades de certificação, navegadores, sistemas operativos e bibliotecas. Os navegadores corrigiram o problema em horas. Os servidores só ficam protegidos quando alguém os atualiza. É o mesmo padrão das falhas críticas de outubro no GitLab, no Next.js e no Pillow e do Vghost no kernel Linux: a correção existe, mas só protege quem a instala.

Quer saber se o seu site está protegido?

A MarcaWeb trata da cibersegurança de sites, lojas online e servidores. Podemos verificar as versões do Node.js, do PHP e da lista de certificados nos seus servidores e contentores, atualizar o que falta, voltar a fazer deploy e confirmar com os testes acima que a sua aplicação rejeita os certificados comprometidos. Comece pela auditoria gratuita ou fale connosco: escreva para info@marcaweb.pt ou ligue para o +351 920 260 897.

Fontes: Render, aviso eMudhra (22-10-2026), eMudhra Intermediate CA Compromise (20-10-2026), Google, Chrome e Android, Mozilla Security Blog (20-10-2026), Node.js, atualizações de segurança (21-10-2026), DSCI, eMudhra, comunicado e eMudhra, comunicado de 21-10-2026. Consultadas a 27-10-2026.