CVE-2026-111943: Autoridade Certificadora Intermediária Comprometida
Uma autoridade certificadora intermediária comprometida operada pela eMudhra foi descoberta usando chaves elípticas absurdamente fracas, permitindo que invasores derivem chaves privadas a partir de certificados públicos e emitam certificados TLS “válidos” para qualquer domínio. Sistemas operacionais, linguagens e ferramentas estão correndo para revogar ou colocar em denylist as intermediárias afetadas, com atenção especial aos casos em que o software traz seu próprio trust store (por exemplo, `crypto/x509` do Go, `certifi` do Python, `uv`, containers e dispositivos embarcados) em vez de depender apenas de atualizações do SO. Comentadores destacam tanto como testar se os clientes ainda confiam nas CAs ruins quanto como o gerenciamento fragmentado de trust stores e múltiplos gerenciadores de pacotes torna uma remediação rápida e abrangente surpreendentemente difícil.
Natureza do incidente
- A eMudhra gerou oito chaves de CA intermediária de forma tão fraca que as chaves privadas podem ser derivadas dos certificados públicos.
- Qualquer pessoa com essas chaves pode emitir certificados TLS “válidos” para domínios arbitrários (bancos, PyPI, etc.), possibilitando ataques MITM.
- Vários participantes ligam para o mesmo site de explicação e tópicos anteriores do HN; este CVE focado em Go faz parte de um incidente maior e contínuo da eMudhra.
Ângulo específico de Go e trust stores
- A discussão se concentra em
crypto/x509do Go usando o trust store do sistema mais uma denylist interna. - O CVE é essencialmente: algumas versões do Go não têm as entradas atualizadas da denylist para as intermediárias comprometidas.
- Foi esclarecido que o Go rejeitará os certificados se ou o SO os tiver removido ou a denylist do Go estiver atualizada.
- Nuance importante: binários incorporam estaticamente a lógica de confiança do Go, então é preciso recompilar/reimplantar os apps com um toolchain Go mais novo para se beneficiar.
Respostas do SO e das distribuições
- Gentoo e Slackware são relatadas como atualizadas; comandos específicos de
emergedo Gentoo são compartilhados. - O macOS parece desconfiar dos certificados no nível do SO, embora algumas ferramentas vejam visões diferentes de confiança.
- A resposta da Red Hat é criticada por ser incompleta e lenta; apenas um contorno removendo duas raízes da Comodo é citado, marcado como “ongoing”.
- São feitas comparações: alguns preferem Debian devido a atualizações de segurança mais rápidas; outros ainda favorecem a qualidade geral dos patches do RHEL, mas observam atrasos persistentes.
Outros ecossistemas e ferramentas
- Python,
certifi,uv,bun, Java (AWS Corretto) e outras stacks podem incorporar seus próprios bundles de CA e precisar de atualizações explícitas. - É mencionada orientação separada para usuários de Python; o próprio
uvé citado como tendo seu próprio trust store. - Navegadores frequentemente têm CRLs independentes e podem estar seguros mesmo quando ferramentas de CLI (curl, wget) não estão.
Testes e mitigação local
- Vários endpoints de teste são compartilhados; o resultado correto é falha de TLS com “unable to get local issuer certificate”.
- Pessoas usam curl e Python
urllibcontra esses hosts para verificar o comportamento de confiança. - Contornos incluem apontar o curl no macOS para um bundle de CA atualizado do Homebrew; scripts para gerenciar certificados CA no Debian são compartilhados.
Temas operacionais e meta
- Muitos expressam frustração com gerenciamento de pacotes em múltiplas camadas, containers e trust stores espalhados.
- Alguns defendem containers; outros argumentam por deploy mais simples baseado no host e hardening com systemd.
- Há debate sobre confiar em LLMs/agentes para patching automatizado: útil para cobertura, mas com risco de complacência do operador.
- Discussão breve sobre a terminologia (“monster-in-the-middle” vs “man-in-the-middle”) e sobre quão rápido isso virou “notícia velha”.