Seguir Um grande incidente de infraestrutura de chave pública desencadeou medidas de segurança de emergência em navegadores, ecossistemas de linguagens de programação, armazenamentos de certificados e pacotes de software. Chaves privadas associadas a oito certificados de autoridade certificadora intermediária da eMudhra foram comprometidas, potencialmente permitindo que partes não autorizadas criassem certificados que poderiam parecer confiáveis para clientes vulneráveis.
O incidente afeta seis intermediários TLS usados para certificados validados por domínio, validados por organização e de validação estendida, juntamente com dois intermediários de assinatura de código. Porque uma AC (autoridade certificadora) intermediária pode emitir certificados abaixo de uma raiz confiável, a posse de sua chave privada cria um risco substancialmente diferente do comprometimento de um certificado de site comum. Um atacante poderia potencialmente criar certificados fraudulentos que herdam confiança da cadeia afetada.
O Projeto Go respondeu introduzindo o CVE-2026-111943, que aborda casos em que aplicativos Go poderiam continuar confiando em cadeias de certificados contendo os intermediários comprometidos. O Go 1.26.10 e 1.27.3 adicionam uma lista de bloqueio ao crypto/x509, fazendo com que a verificação do certificado falhe quando uma das chaves intermediárias conhecidas como não confiáveis aparece em uma cadeia.
As equipes de segurança que buscam oportunidades de detecção do CVE-2026-111943 devem olhar além da telemetria convencional de exploração de vulnerabilidades. Este incidente é fundamentalmente sobre confiança em certificados, então os defensores devem monitorar cadeias de certificados TLS, emissores de certificados inesperados, falhas de validação de certificados, sessões criptografadas suspeitas e software que mantém seu próprio conjunto de certificados em vez de depender dos mecanismos de revogação de navegador rapidamente atualizados.
A Plataforma de Inteligência de Detecção Nativa de IA da SOC Prime permite que as equipes de segurança aumentem a visibilidade sobre ameaças emergentes, aproveitando conteúdo de detecção continuamente atualizado em diversas tecnologias SIEM, EDR e Data Lake. Clique Explorar Detecções para acessar conteúdo relevante de detecção e lógica de caça para comportamentos de ataques emergentes.
Os profissionais de segurança também podem usar o Prime Architect para transformar inteligência sobre ameaças recentes e indicadores em consultas de caça e lógica de detecção, ajudando as equipes a Detectar exposições relacionadas ao CVE-2026-111943 e investigar atividades suspeitas de certificados em seus ambientes.
Análise do CVE-2026-111943
O incidente começou em 17 de outubro de 2026, quando um pesquisador de segurança identificou uma falha criptográfica que afeta oito certificados intermediários operados pela eMudhra sob sua infraestrutura de autoridade certificadora emSign. O pesquisador demonstrou posse das chaves privadas correspondentes enviando atestações assinadas válidas para todos os oito certificados para programas raiz de navegadores e eMudhra.
Posteriormente, a Mozilla confirmou o comprometimento e, de forma importante, relatou que seus engenheiros conseguiram recuperar independentemente as chaves privadas afetadas sem receber detalhes sobre o método do pesquisador. A Mozilla concluiu que o processo subjacente de geração de chaves era falho e fácil de explorar.
As autoridades certificadoras afetadas incluíram:
- EM DV TLS CA – G3B
- EM DV TLS CA – G3C
- EM OV TLS CA – G3B
- EM OV TLS CA – G3C
- EM EV TLS CA – G3B
- EM EV TLS CA – G3C
- EM OV CS CA – G3B
- EM OV CS CA – G3C
Os primeiros seis são intermediários TLS capazes de participar em cadeias de certificados usadas para autenticar websites. Os dois restantes são intermediários de assinatura de código. Os certificados G3B estavam associados à eMudhra BV na Holanda, enquanto os certificados G3C estavam associados à eMudhra Inc. nos Estados Unidos.
As implicações de segurança são significativas. Qualquer pessoa capaz de derivar ou obter de outra forma uma chave privada de AC intermediária poderia potencialmente emitir certificados abaixo desse intermediário sem passar pelo processo legítimo de emissão da autoridade certificadora. No contexto do TLS, certificados fraudulentos poderiam ser usados para personificar domínios se um atacante também pudesse interceptar ou redirecionar a conexão de uma vítima.
A Mozilla notou que tal atacante poderia potencialmente personificar websites e ler ou modificar o tráfego quando posicionado para interceptar a conexão. Isso torna a questão particularmente relevante para cenários de adversário-no-meio, infraestrutura de rede comprometida, proxies maliciosos ou manipulação de DNS e roteamento.
No entanto, as evidências disponíveis não demonstram abuso generalizado de certificados TLS fraudulentos antes da resposta defensiva. De acordo com as descobertas do Programa Raiz do Chrome citadas pelo The Hacker News, nenhum certificado TLS encadeando-se aos seis intermediários de websites afetados havia aparecido nos logs de Transparência de Certificados antes do Chrome bloquear as chaves. Porque o Chrome e outros navegadores que exigem registro CT normalmente rejeitariam um certificado publicamente confiável não registrado, isso limitou significativamente as oportunidades de abuso TLS público não detectado por meio desses clientes.
O Chrome recebeu o relatório às 18:05 UTC em 17 de outubro e implantou um bloqueio CRLSet para os seis intermediários TLS às 19:45 UTC. A Mozilla recebeu o relatório mais tarde naquela noite e distribuiu um bloqueio OneCRL para as configurações padrão do Firefox às 22:59 UTC. Usuários do Firefox recebendo Configurações Remotas portanto ganharam proteção sem precisar atualizar ou reiniciar manualmente o navegador.
A situação do PoC do CVE-2026-111943 é incomum porque não é uma vulnerabilidade convencional de corrupção de memória ou execução remota de código com código de exploração. Em vez disso, o pesquisador forneceu prova criptográfica de controle sobre todas as oito chaves privadas, e a Mozilla reproduziu de forma independente a recuperação das chaves, demonstrando efetivamente que a falha criptográfica poderia ser explorada.
O próprio CVE foi atribuído pelo Projeto Go. Ele descreve um problema mais restrito envolvendo a validação de certificados na biblioteca padrão do Go. Na maioria das plataformas, o Go depende de armazenamentos certificados raízes do sistema. Mas sistemas onde a configuração de confiança relevante não é atualizada prontamente poderiam continuar aceitando cadeias através de intermediários que não são mais confiáveis.
Para fechar essa lacuna, o Projeto Go adicionou uma lista de bloqueio explícita ao crypto/x509. A lógica de verificação atualizada retorna um erro sempre que uma cadeia de certificados contiver uma das chaves públicas intermediárias comprometidas.
O CVE-2026-111943 afeta versões da biblioteca padrão do Go anteriores à 1.26.10 e o branch Go 1.27 anterior à versão 1.27.3. Aplicações construídas usando versões afetadas podem, portanto, precisar ser recompiladas com uma versão corrigida do Go para receber a nova proteção.
Os detalhes para o CVE-2026-111943 são particularmente importantes para proprietários de aplicações porque a correção do navegador não protege automaticamente todos os programas que realizam validação TLS. Muitas aplicações usam armazenamentos de certificados específicos de linguagem ou incorporados e podem não consumir sistemas de revogação de navegador, como CRLSet do Chrome ou OneCRL da Mozilla.
O The Hacker News relata que essa distinção desencadeou atualizações em diversos ecossistemas. O Go adicionou bloqueio explícito, a Mozilla atualizou o NSS, o pacote de certificados certifi do Python removeu a raiz afetada, e o ecossistema webpki-roots do Rust emitiu uma atualização. O RustSec identifica separadamente a versão 1.0.10 ou mais recente como corrigida para o pacote PKI web raiz afetado.
Os IOCs do CVE-2026-111943 são, portanto, principalmente orientados a certificados, em vez de indicadores tradicionais de malware, como endereços IP, domínios ou hashes de arquivos. As organizações devem se concentrar nas oito identidades de certificados intermediários afetados e nos hashes de chaves públicas usados pelo Go e outros fornecedores para bloquear explicitamente essas chaves. A telemetria de cadeia de certificados mostrando um desses intermediários deve ser tratada como não confiável e investigada.
Mitigação do CVE-2026-111943
A correção mais importante para ambientes Go é atualizar para Go 1.26.10, Go 1.27.3, ou uma versão posterior suportada e reconstruir aplicações que dependem da verificação de certificados TLS do Go. Atualizar apenas a ferramenta Go em um servidor de desenvolvimento não altera retroativamente binários já compilados; aplicações afetadas precisam ser reconstruídas e redeployadas com a biblioteca padrão corrigida.
As organizações também devem fazer inventário de aplicações que mantêm armazenamentos CA independentes ou conjuntos de certificados. Navegadores como Chrome e Firefox reagiram rapidamente através de mecanismos centralizados de revogação, mas utilitários de linha de comando, aplicações de servidor, containers, agentes, dispositivos incorporados, e runtimes de linguagem podem depender de fontes de certificados diferentes.
Usuários do Firefox com configurações normais receberam o bloqueio OneCRL automaticamente em 17 de outubro. A Mozilla lançou adicionalmente o Firefox 158.0.1, Firefox ESR 115.43.1, e Firefox ESR 153.5.1 para fornecer a lista de bloqueios atualizada para usuários cujas políticas ou ambientes de rede impediram que as Configurações Remotas funcionassem normalmente. A Mozilla também lançou o NSS 3.131.1 com alterações no conjunto de certificados confiáveis.
As equipes de segurança devem:
- Atualizar aplicações Go e reconstruir binários afetados.
- Atualizar conjuntos de CA de sistema e armazenamentos de confiança específicos de linguagem.
- Garantir que os mecanismos de revogação de certificado dos navegadores e sistemas operacionais estejam funcionando.
- Bloquear ou não confiar nas oito chaves de certificados intermediários comprometidas.
- Identificar aplicações internas com armazenamentos de certificados incorporados ou empacotados estaticamente.
- Inspecionar a telemetria TLS para cadeias de certificados contendo os intermediários afetados.
- Reemita certificados legítimos se serviços existentes dependem de cadeias de certificados que agora foram desconsideradas.
- Teste serviços críticos após atualizações dos armazenamentos raiz porque remover uma raiz CA também pode interromper serviços legítimos que previamente se encadeavam através dela.
As equipes também devem prestar atenção especial a appliances de software de longa duração, containers, ferramentas internas de desenvolvimento e software não suportado. Esses sistemas podem continuar confiando em conjuntos de certificados antigos muito tempo depois que navegadores mainstream bloquearam uma CA comprometida.
Remover um certificado raiz pode ter consequências operacionais. Certificados legítimos encadeados através dessa raiz também podem parar de validar, mesmo que esses certificados individuais nunca tenham sido comprometidos. Por esse motivo, as organizações devem combinar a desconfiança rápida com a descoberta de dependências e substituição de certificados, em vez de supor que a remoção do depósito de confiança não tem impacto na disponibilidade.
As equipes SOC podem fortalecer sua postura defensiva correlacionando falhas de validação de certificados, telemetria de interceptação TLS, atividade de DNS incomum, comportamento de proxy inesperado e mudanças de emissores de certificados. Um atacante geralmente requer algum mecanismo para direcionar ou interceptar o tráfego antes que um certificado TLS fraudulento se torne útil, então anomalias de certificados devem ser investigadas juntamente com evidências ao nível de rede.
FAQ
O que é CVE-2026-111943 e como funciona?
CVE-2026-111943 é um problema de segurança rastreado pelo Projeto Go no pacote de verificação de certificados crypto/x509 após o comprometimento de oito chaves privadas de ACs intermediárias da eMudhra. As chaves comprometidas poderiam potencialmente ser usadas para criar certificados encadeados por intermédios afetados. Aplicações Go que dependem de armazenamentos de certificados que ainda não removeram ou revogaram esses intermediários poderiam continuar aceitando tais cadeias. O Go abordou o risco adicionando uma lista de bloqueio explícita que faz a verificação de certificado falhar sempre que uma das chaves intermediárias comprometidas conhecidas é encontrada.
Quando o CVE-2026-111943 foi descoberto pela primeira vez?
O comprometimento subjacente de chaves da eMudhra foi identificado em 17 de outubro de 2026. De acordo com o cronograma do incidente da Mozilla, o pesquisador Wayne descobriu o quebrou criptográfico naquela tarde e relatou a questão, juntamente com prova de controle de chave privada, para programas raiz de navegadores e eMudhra. Chrome e Mozilla verificaram as descobertas dentro de horas e começaram a bloquear os intermediários afetados. CVE-2026-111943 foi posteriormente publicado pelo Projeto Go como parte de sua resposta ao risco residual de confiança de certificados.
Qual é o impacto do CVE-2026-111943 sobre os sistemas?
O principal risco é a confiança indevida em cadeias de certificados envolvendo chaves de CA intermediárias comprometidas. Para TLS, a posse de uma chave privada de CA intermediária poderia potencialmente permitir que certificados fraudulentos fossem emitidos para websites que um atacante não controla. Se o atacante puder interceptar ou redirecionar o tráfego de rede e o software da vítima ainda confiar na cadeia de certificados afetada, isso poderia facilitar a personificação de websites e potencialmente permitir que comunicações criptografadas fossem observadas ou alteradas. O comprometimento também incluiu duas chaves intermediárias de assinatura de código, ampliando a preocupação além da autenticação de websites para ecossistemas de confiança de software que aceitam cadeias através desses intermediários.
O CVE-2026-111943 ainda pode me afetar em 2026?
Sim. A exposição permanece possível para software que não recebeu informações atualizadas de desconfiança de certificados. Instalações padrão do Chrome e Firefox receberam proteção rápida, mas aplicações Go compiladas com versões vulneráveis da biblioteca padrão, aplicações usando conjuntos de CA independentes desatualizados, software não suportado, sistemas incorporados, ou ambientes onde os mecanismos de revogação de certificados são desativados podem continuar confiando nas rotas de certificados comprometidos. As organizações portanto não devem assumir que atualizar seus navegadores web elimina o risco.
Como eu posso me proteger do CVE-2026-111943?
Atualize para Go 1.26.10, Go 1.27.3, ou mais recente e reconstrua aplicações Go afetadas. Atualize as lojas de confiança de sistemas operativos e aplicações, versões de navegadores, conjuntos de certificados específicos de linguagem, e outros softwares que realizam verificação TLS. As organizações também devem verificar que os oito intermediários comprometidos não são mais confiáveis, inspecionar a telemetria de cadeia de certificados para sua presença, e identificar aplicações que carregam conjuntos de CA estáticos ou incorporados. Se serviços legítimos atualmente dependem de correntes afetadas pelas ações de desconfiança de emergência, substitua esses certificados por correntes ancoradas em autoridades certificadoras não afetadas.
