Bibliotecas TLS aceitam certificados indevidos — o patch varia por stack

Em 14 de outubro de 2026, o CERT/CC publicou a nota VU#948176 sobre casos em que bibliotecas TLS podem aceitar nomes de certificados fora dos limites impostos a uma autoridade certificadora subordinada. As falhas dependem do tipo de nome e do caminho de validação; parte delas já foi corrigida, enquanto outros relatos seguem em análise ou tiveram a classificação contestada.

Na síntese coordenada de Oleh Konko, publicada no mesmo dia, as correções aparecem distribuídas entre versões de GnuTLS, pyca/cryptography, wolfSSL, Go e outras implementações. Para uma aplicação, a versão relevante é a do validador que constrói a cadeia e entrega a identidade usada na autorização, inclusive quando ele chega ao serviço por uma dependência indireta.

Como uma cadeia assinada ultrapassa a delegação

A extensão X.509 Name Constraints delimita os nomes que uma autoridade subordinada pode certificar. Uma assinatura válida demonstra que os certificados pertencem à cadeia apresentada, mas não resolve sozinha se o nome do certificado final está dentro do espaço permitido. Essa decisão depende de o validador aplicar a restrição ao campo correto e comparar os nomes conforme suas regras.

Os casos divulgados envolvem comparações de DNS que distinguem maiúsculas de minúsculas, nomes com coringa, endereços IP, extração do host de uma URI e uso do Common Name quando o certificado não tem Subject Alternative Name (SAN). Há defeitos de implementação corrigidos e diferenças em pontos que a especificação não define por completo, como certas interpretações de coringas e de endereços IPv4 representados em IPv6. Por isso, duas bibliotecas podem decidir de maneira diferente sobre a mesma cadeia sem que toda divergência constitua a mesma falha.

O efeito sobre um serviço exige condições adicionais: uma assinatura confiável sobre campos escolhidos por quem emitiu o certificado, acesso ao caminho de validação afetado e uso da identidade aceita para autorizar uma ação. Um certificado fora da delegação só produz esse risco concreto quando as três condições se encontram na implantação. O simples uso de uma biblioteca mencionada na divulgação não demonstra que a aplicação percorre o trecho vulnerável.

Matriz de comportamento e correção por biblioteca

As versões abaixo são mínimas para os comportamentos indicados, não uma declaração de que todas as formas de Name Constraints estão resolvidas em cada projeto. A divulgação coordenada também inclui rustls/webpki e BoringSSL em avisos relacionados, além dos registros reunidos na VU#948176.

• GnuTLS: comparações sensíveis a maiúsculas e minúsculas afetavam determinados nomes DNS e a parte de domínio de nomes de e-mail. CVE-2026-3833 foi corrigido em 3.8.13.
• pyca/cryptography: com um nome DNS curinga no SAN do certificado final, as restrições eram verificadas contra os nomes do certificado, mas não contra o nome do par solicitado. CVE-2026-34073 foi corrigido em 46.0.6; a versão do pacote Python deve ser identificada separadamente de qualquer outra biblioteca TLS usada pela aplicação.
• wolfSSL: restrições de URI em uma autoridade intermediária eram analisadas, mas não impostas na verificação da cadeia. Há uma divergência de identificação: o aviso coordenado registra CVE-2026-3547 e 5.9.0, enquanto o lançamento da wolfSSL 5.9.1 descreve explicitamente essa falha como CVE-2026-5263 e a corrige nessa versão. A correção para certos coringas é um ajuste separado, também presente em 5.9.1.
• Go crypto/x509: a busca da restrição parental para nomes com coringa podia falhar por distinguir maiúsculas de minúsculas. CVE-2026-33810 foi corrigido em Go 1.26.2. Outros relatos sobre Go permanecem em triagem; a equipe do projeto não aceitou o caso de IPv4 representado como IPv6 como questão de segurança.
• OpenSSL: foi incorporada uma correção para a leitura de URIs nas quais o caractere @ aparece após o host, no caminho, na consulta ou no fragmento. Ela estava nas versões publicamente suportadas na confirmação do projeto, sem uma única versão mínima indicada para todas as linhas. O relato distinto sobre dois-pontos na parte de informações do usuário continuava em triagem.
• AWS-LC e s2n-tls: quando falta SAN, o retorno ao Common Name com coringa pode interagir de modo incorreto com a restrição DNS. O caso do AWS-LC foi corrigido em 1.71.0, correspondente a aws-lc-sys 0.39.0; o relato de s2n-tls segue em triagem. A questão separada sobre Common Name em Unicode ainda aparece sob coordenação no aviso do CERT/CC.
• rustls/webpki: a correção para coringas em subárvores permitidas chegou à linha 0.103.12. Para restrições de URI, a primeira correção rejeitava restrições não suportadas, e o caso de subárvores excluídas foi completado em 0.103.13; esta é a referência da linha estável para cobrir ambos os comportamentos descritos na síntese.
• BoringSSL: ajustes para coringas diante de nomes excluídos e para nomes DNS terminados em ponto entraram no código upstream do caminho legado crypto/x509. Outros relatos têm estados diferentes, entre aceito, contestado e recusado. Uma versão de distribuição não pode ser inferida apenas da presença do ajuste no repositório.
• Apple Security.framework, Mozilla NSS e LibreSSL: os relatos sobre nomes IP, URI ou coringas permanecem em triagem ou coordenação, conforme a implementação. A divulgação não oferece uma versão mínima de correção comum para esse grupo.
• Mbed TLS: na configuração examinada, restrições não marcadas como críticas deixam de ser impostas. Marcá-las como críticas faz essa configuração rejeitar a cadeia, sem passar a interpretar a restrição. O fornecedor trata o suporte como recurso a implementar, e a classificação do relato continua contestada.

O inventário termina no validador em execução

O nome da linguagem, do servidor ou do pacote principal não identifica, por si só, o componente que decide se a cadeia é válida. Um serviço pode receber esse componente diretamente, por uma dependência transitiva, por uma biblioteca do sistema ou incorporado a outro pacote. O inventário precisa relacionar cada serviço ao validador efetivamente carregado, à sua versão e à função que usa o nome aceito.

Essa relação muda a leitura da matriz. Uma aplicação que verifica nomes de URI precisa distinguir a falha desse caminho de uma correção restrita a DNS; outra que permite retorno ao Common Name sem SAN deve examinar esse comportamento específico. Também importa saber se o serviço aceita cadeias com autoridades subordinadas sujeitas a Name Constraints e se usa o nome validado para autorizar acesso, pois a presença da biblioteca sozinha não estabelece o impacto.

Para as linhas com correção publicada, a evidência decisiva é a versão que roda no processo e o caminho de validação acionado por ele. Para os relatos ainda em análise, a política de emissão continua sendo o limite mais imediato sobre quais nomes uma autoridade subordinada pode obter. Enquanto as coordenações pendentes não resultarem em decisões ou versões específicas, serviços que dependem dessa delegação podem tomar decisões diferentes sobre uma mesma identidade conforme o validador implantado.

Leia também:

• PaperCut sofre ataques ativos — até o primeiro patch precisa ser trocado
• Na OpenAI, agentes trabalham 3,1 dias por dia humano — com correções
• Habilidade em IA paga 62% a mais — mas o prêmio varia de 16% a 118%