O projeto OpenVPN anunciou a disponibilidade do OpenVPN 2.7.7, uma atualização com foco pesado em segurança. O lançamento corrige sete vulnerabilidades rastreadas por CVEs, que vão desde falhas capazes de causar negação de serviço (DoS) até brechas para manipulação de privilégios e carregamento indevido de configurações.
Embora uma das vulnerabilidades atinja todas as plataformas suportadas, o grande volume de correções desta versão concentra-se na arquitetura de serviços do OpenVPN para Windows. Além da segurança, a nova versão introduz validação aprimorada para conexões via Netlink no Kernel Linux e otimizações de desempenho na gestão de pacotes e chaves criptográficas.
O que isso significa para quem administra redes
Se você gerencia instâncias de OpenVPN, esta é uma atualização altamente recomendada. Para servidores baseados em Linux e BSD, a atualização protege a camada de confiabilidade do protocolo contra instabilidades no TLS. Já no caso de clientes rodando Windows, o patch é ainda mais urgente: ele fecha brechas de transbordamento de buffer, abusos de privilégio local e caminhos de configuração que poderiam permitir que um usuário mal-intencionado interferisse no serviço de VPN.
Correção global na camada de confiabilidade
A correção de maior impacto geral aborda a infraestrutura central de transmissão, afetando instalações em Linux, macOS e Windows.Identificada como CVE-2026-84732, a falha reside na camada de confiabilidade responsável por gerenciar handshakes do protocolo TLS e pacotes de confirmação (ACKs).
Dois problemas coexistiam nesta estrutura: um limite de tempo (timeout) não restrito para o TLS e a falta de filtros adequados para ACKs correspondentes a pacotes que já não deveriam estar pendentes. Descobertos pelo pesquisador Mark Bregman, esses bugs poderiam ser explorados para manipular o fluxo da conexão, criando condições propícias para uma negação de serviço via handshake malformado.
Foco na arquitetura do Windows
As outras seis vulnerabilidades corrigidas afetam especificamente os clientes de Windows. As modificações refletem um esforço para proteger componentes críticos, como o utilitário tapctl e o serviço openvpnserv, que acumularam comportamentos problemáticos de borda e validação insuficiente de entradas:
- CVE-2026-84256: Corrigiu o tratamento de aspas e argumentos no
CreateProcess(). Anteriormente, caracteres especiais processados pelocmd.exe, aliados a um script de validação e a uma autoridade certificadora desonesta, poderiam resultar em comportamento inesperado na execução. - CVE-2026-84226:O utilitário
tapctlpassou a invocar onetsh.exeinformando seu caminho completo, preenchendo uma lacuna técnica que poderia ser abusada para sequestro de binários ou de rotas (binary hijacking). - CVE-2026-82312: O OpenVPN não usa mais permissões DACL nulas em objetos do sistema (como o semáforo do
netsh.exe). A abordagem antiga permitia que um usuário local bloqueasse intencionalmente o evento de saída ou as instâncias de OpenVPN de outros usuários, causando um DoS local. - CVE-2026-78221:Evita um problema de buffer overread no
openvpnservao processar domínios (NRPT) com codificação UTF-8, ajustando adequadamente o tamanho de leitura esperado. - CVE-2026-78043: A validação de diretórios de configuração do Windows não barrava o uso da barra comum (
/). Esse drible nas APIs de abertura de arquivos permitia carregar configurações de VPN não autorizadas pelos administradores do sistema. - CVE-2026-81738: Soluciona um erro de limite (“off-by-one”) em opções malformadas de DHCP. Domínios de pesquisa cuidadosamente criados podiam transbordar um buffer temporário em um byte.
Otimizações de rede e Netlink no Linux
Fora do escopo direto das vulnerabilidades, a versão 2.7.7 incorpora melhorias estruturais para desempenho e estabilidade do tráfego.
Para os usuários de Linux, a principal adição é que o cliente agora valida as respostas do Netlink em relação à requisição que as gerou. Sugerida pelo pesquisador Joshua Rogers, a camada extra atua como uma salvaguarda de comunicação com o Kernel Linux.
No tratamento de pacotes, os desenvolvedores reduziram a retenção de chaves futuras no formato de canal de dados EPOCH.O limite despencou de 16 para 4 chaves. A adequação elimina excesso de registros (logs) e reduz o consumo de recursos computacionais nas implementações de kernel, pois apenas 4 chaves sobressalentes já são estatisticamente suficientes para manter links estabilizados até em altas taxas de 100 Gbit/s.
Por fim, respeitando o padrão da RFC 768, o cliente deixou de ajustar checksums UDP quando seus valores são nulos.Em paralelo, a integração com o OpenSSL evita a redefinição desnecessária da chave HMAC a cada novo pacote processado, poupando ciclos de CPU.
