Um conjunto de pelo menos 15 vulnerabilidades na biblioteca wolfSSL, usada em mais de 5 bilhões de dispositivos, permite falsificação de certificados TLS, execução remota de código e ataques de negação de serviço. Os fabricantes de dispositivos IoT e os administradores devem atualizar imediatamente para a versão 5.9.2, divulgada pela wolfSSL no fim de junho de 2026.
wolfSSL: alcance e relevância
wolfSSL é uma implementação leve de TLS escrita em C, projetada para ambientes com recursos limitados onde a biblioteca OpenSSL não cabe. A biblioteca está incorporada em servidores web, appliances VPN, controladores industriais, sistemas automotivos, dispositivos IoT e smart home. Segundo a própria wolfSSL, o produto protege comunicações em mais de 5 bilhões de dispositivos em todo o mundo. Muitos desses sistemas também utilizam o wolfCrypt, o motor criptográfico da wolfSSL, que compartilha parte das falhas relatadas.
Qualquer falha sistêmica no wolfSSL carrega implicações em escala global de internet, uma vez que a biblioteca sublinha o canal TLS entre bilhões de endpoints. A divulgação, confirmada pela própria wolfSSL em sua página oficial de vulnerabilidades, lista ao menos 15 CVEs com severidade alta e crítica.
Bypass de verificação de certificado
As falhas mais graves atingem o verificador de certificados compatível com OpenSSL, a função wolfSSL_X509_verify_cert(). Dois CVEs de alta severidade permitem que um atacante apresente certificados controlados por ele como se fossem confiáveis, sem que a cadeia chegue a uma autoridade certificadora configurada.
CVE-2026-11310 afeta as versões 5.8.4, 5.9.0 e 5.9.1. O verificador carrega temporariamente certificados intermediários não confiáveis no gerenciador de certificados, mas falha ao removê-los antes da verificação no repositório de confiança. Um intermediário não confiável passa a ancorar o caminho de validação. A falha foi introduzida no commit 025dbc34.
CVE-2026-11999, que afeta as versões de 5.7.4 a 5.9.1, explota a exaustão de profundidade de caminho. Quando a cadeia fornecida é mais profunda que o limite máximo do verificador (padrão: 100), a construção do caminho se esgota enquanto ainda percorre intermediários não confiáveis, e a cadeia é aceita sem nunca atingir uma âncora de confiança.
Um terceiro bypass, CVE-2026-55960, permite que uma chave pública bruta não negociada (RFC 7250) substitua um certificado X.509, contornando toda a validação de cadeia em builds com HAVE_RPK habilitado.
Em conjunto, essas falhas habilitam ataques de homem-no-meio e personificação de servidores TLS contra clientes wolfSSL, permitindo a interceptação e manipulação de comunicações que os usuários acreditam estar protegidas.
Corrupção de memória e RCE
Além dos bypass de confiança, a divulgação inclui falhas de corrupção de memória que podem ser acionadas antes da autenticação do peer remoto:
CVE-2026-6679 (Alto) descreve um estouro de buffer no heap na serialização de ACK do DTLS 1.3, causado por truncamento de inteiro no cálculo do tamanho da lista de números de registro. Um buffer subdimensionado é alocado e subsequentemente sobrescrito, podendo provocar crash ou execução remota de código em dispositivos com suporte a DTLS 1.3.
CVE-2026-55958 (Alto) causa escrita fora dos limites no buffer de transcrição TLS 1.3 em builds que usam o port TSIP da Renesas, corrompendo o estado adjacente do heap em microcontroladores Renesas com TSIP habilitado.
CVE-2026-5194 (Crítico), reportado por Nicholas Carlini da Anthropic, revela validação ausente de tamanho de digest e OID em algoritmos de assinatura incluindo ECDSA, DSA, ML-DSA, Ed25519 e Ed448, permitindo assinaturas com digests menores que o padrão FIPS.
Fragilidades em criptografia pós-quântica
wolfSSL se posiciona como biblioteca preparada para o pós-quântico, porém diversos CVEs expõem falhas nos caminhos de código ML-KEM e ML-DSA:
CVE-2026-6330 mostra que a comparação de ciphertext ML-KEM na implementação ARM64 NEON avalia apenas metade da entrada, quebrando a rejeição implícita do transform Fujisaki-Okamoto e enfraquecendo a segurança IND-CCA2 nesse caminho. CVE-2026-10097 expõe falha análoga na implementação ML-KEM-1024 x64 AVX2.
Aceitar apenas a metade do ciphertext compromete a garantia fundamental de que um atacante não consiga distinguir entre um ciphertext válido e inválido, base da segurança dos esquemas de encapsulamento de chave pós-quânticos.
Versões afetadas e cronologia
| CVE | Severidade | Versões afetadas | Corrigido em |
|---|---|---|---|
| CVE-2026-11310 | Alto | v5.8.4, v5.9.0, v5.9.1 | 5.9.2 |
| CVE-2026-11999 | Alto | v5.7.4 – v5.9.1 | 5.9.2 |
| CVE-2026-55960 | Alto | builds com HAVE_RPK | 5.9.2 |
| CVE-2026-6679 | Alto | v5.9.0 e anteriores | 5.9.1 |
| CVE-2026-55958 | Alto | builds Renesas TSIP | 5.9.2 |
| CVE-2026-5194 | Crítico | pré-5.9.1 | 5.9.1 |
| CVE-2026-6330 | Médio | ARM64 NEON ML-KEM | 5.9.2 |
| CVE-2026-10097 | Médio | ML-KEM-1024 x64 AVX2 | 5.9.2 |
O que fazer agora
Administradores e fabricantes de IoT devem atualizar imediatamente para wolfSSL 5.9.2, que corrige todas as vulnerabilidades divulgadas. A wolfSSL recomenda desabilitar recursos opcionais como compatibilidade OpenSSL (--enable-opensslextra), PKCS7 e suporte experimental pós-quântico onde não forem estritamente necessários.
Equipes de segurança devem auditar flags de build — especialmente --enable-opensslextra, --enable-all e HAVE_RPK — para determinar a superfície de exposição específica de cada implantação. Fabricantes de dispositivos IoT e sistemas embarcados precisam reconstruir imagens de firmware com a biblioteca atualizada, pois usuários finais raramente conseguem atualizar a biblioteca TLS incorporada por conta própria.
O monitoramento de tráfego TLS e DTLS anômalo em dispositivos que expõem serviços baseados em wolfSSL também é recomendado como medida defensiva complementar.