A versão de manutenção 2.7.8 do OpenVPN (discussão pública datada de 7 de outubro de 2026) reúne três correções com tag de CVE mais uma alteração de robustez do tls-crypt-v2 que deliberadamente não carrega um ID de CVE. Esta nota de segurança costura os avisos principais para que os operadores possam priorizar clientes Windows e Android, ferramentas de certificado e servidores DCO multi-cliente, sem tratar blogs de marketing como a única fonte da verdade.

Encrypt-then-MAC authenticated encryption construction diagram
Fonte: Wikimedia Commons (RokerHRO) — Criptografia autenticada EtM

Fontes primárias

CVE-2026-88964 — underflow na pesquisa de domínio

A wiki da comunidade afirma que um underflow de inteiro no OpenVPN no Windows e no Android permite que servidores autenticados remotos causem negação de serviço ou divulgação de memória por meio de opções de pesquisa de domínio manipuladas no tratamento de PUSH_REPLY. Trata-se de uma classe clássica de falha “peer confiável, opções hostis”: a autenticação já foi bem-sucedida, mas a análise das opções ainda confiava demais na aritmética de comprimentos. O impacto é negação de serviço e possível divulgação de memória, e não uma alegação de execução remota de código irrestrita no texto público da wiki. A correção é disponibilizada na 2.7.8.

Os defensores devem assumir que qualquer cliente ainda na 2.7.7 ou anterior, na janela afetada, permanece exposto ao se conectar a um endpoint hostil, porém autenticado, incluindo concentradores corporativos comprometidos e servidores de laboratório mal controlados. A pré-condição é fácil de mal-entender: não se trata de um estranho não autenticado disparando pacotes contra um cliente aleatório. Exige que o cliente já confie o suficiente no peer para concluir a autenticação e aceitar opções PUSH_REPLY. Concentradores comprometidos, laboratórios de teste maliciosos e perfis emitidos incorretamente continuam sendo caminhos realistas. Não inflacione o aviso em uma narrativa de execução remota de código sem autenticação que a wiki do OpenVPN não afirma.

CVE-2026-84790 — bytes NULL em subjects de certificado

Padlock symbol representing encrypted network traffic
Fonte: Wikimedia Commons — Padlock.svg

A Linux Compatible relata que certificados com bytes NULL embutidos nas strings de subject agora são recusados. Compilações OpenSSL anteriormente corriam o risco de analisadores que param no primeiro byte NULL; as compilações mbedTLS já rejeitavam tais certificados. Vivek Parikh da BreachX relatou o problema; Max Fillinger implementou a correção. Impacto operacional: certificados arquivados ou forjados de forma maliciosa que antes “funcionavam” no OpenSSL podem falhar após a atualização. Equipes de ferramentas de certificados devem varrer os inventários antes da implantação em massa e tratar falhas súbitas de handshake após 2.7.8 como um sinal de higiene de certificados, e não como uma oscilação de rede aleatória.

Essa recusa também pode quebrar ferramentas legadas que, acidentalmente, embutiram caracteres NUL ao gerar strings de subject. A quebra é desejável do ponto de vista da segurança do analisador, mas as janelas de mudança precisam de uma etapa de inventário. Combine a atualização do OpenVPN com revisões do texto dos certificados ou relatórios de PKI empresarial que sinalizem bytes não imprimíveis nos subjects antes de declarar a implantação concluída.

CVE-2026-84256 — aspas do CreateProcess no Windows

A versão 2.7.8 continua o reforço em torno das aspas da linha de comando do Windows para que caracteres especiais ao cmd.exe não possam acionar a expansão de variáveis dentro de argumentos entre aspas. Lev Stipakov implementou o trabalho; Darren Carreras o relatou. O mesmo número de CVE foi parcialmente tratado no 2.7.7, portanto o 2.7.8 é uma segunda passagem no mesmo caminho, e não um bug do Windows não relacionado. Scripts que disparam o shell em torno do OpenVPN no Windows merecem testes de regressão após a atualização, especialmente quando passam caminhos de perfil controlados pelo usuário ou argumentos auxiliares pelo CreateProcess.

Robustez do tls-crypt-v2 sem um CVE

Durante os handshakes tls-crypt-v2, o OpenVPN podia tentar adicionar uma chave de cliente encapsulada mesmo quando não havia material de chave disponível, confiando demais no pedido de reenvio de um peer. A alteração do 2.7.8 interrompe essa confiança cega. Segundo a orientação da Computer Resilience Agency da Itália, retransmitida pela Linux Compatible, “um servidor malicioso pode impedir que o cliente funcione corretamente” foi tratado como degradação de robustez, e não como um CVE de confidencialidade ou integridade. Os operadores ainda assim devem instalá-lo: ataques de disponibilidade contra clientes VPN são operacionalmente caros mesmo quando não ostentam o verniz de um CVE, e os sistemas de gestão de mudanças devem acompanhar explicitamente o reforço sem CVE.

O identificador ausente ilustra uma lição mais ampla para os programas de segurança de VPN. Políticas que omitem IDs de CVE para questões puramente de disponibilidade contra peers já autenticados ocultarão parte do 2.7.8, a menos que os operadores registrem itens explícitos de robustez. O artigo da Linux Compatible de 7 de outubro de 2026 é um contexto secundário útil, mas os tickets de mudança ainda devem ligar as páginas OpenVPN ReleaseHistory e o wiki de CVE como evidência primária.

Trabalho adjacente de disponibilidade que os operadores não devem ignorar

Além da lista de CVE, o 2.7.8 altera o comportamento de multi-client e de offload do canal de dados. As rotas por cliente são removidas no momento real de saída, e não durante a limpeza atrasada de múltiplas instâncias, corrigindo uma condição de corrida que podia deixar sistemas sem rotas. Um socket netlink dedicado separa o trabalho síncrono das notificações assíncronas. Quando uma operação de peer ou de chave falha depois de o peer já ter saído do kernel, o OpenVPN reinicia uma única instância em vez de derrubar o servidor inteiro. Essas correções de disponibilidade e de exatidão importam tanto quanto os CVE para servidores grandes sob tempestades de reconexão, e foram relatadas em parte pela equipe Access Server da OpenVPN Inc., segundo a Linux Compatible.

O que isto não é

  • Não é um aviso de segurança do WireGuard. Discussões separadas de outubro de 2026 sobre o WireGuard, incluindo patches de handshake-response no LKML e o CVE-2026-13735 de autenticação de keepalive do Zephyr, pertencem às suas próprias notas.
  • Não é marketing de notas de lançamento do fornecedor para uma marca comercial de VPN de consumo.
  • Não é permissão para executar servidores não confiáveis “para testar” a classe de bugs de servidor autenticado.

Outubro de 2026 também registrou discussões relacionadas ao WireGuard que os operadores podem confundir com patches do OpenVPN. O tópico handshake-response da LKML e o problema de keepalive do Zephyr CVE-2026-13735 da NVD são reais, mas eles não corrigem o OpenVPN 2.7.8, e o OpenVPN 2.7.8 não os remedia. Mantenha os inventários separados por binário: OpenVPN da comunidade, WireGuard no kernel, WireGuard em espaço de usuário, stacks Zephyr e aplicativos VPN móveis proprietários. Misturar essas linhagens em uma única planilha de “VPN CVE” é como as equipes deixam de identificar os clientes OpenVPN para Windows e Android que o CVE-2026-88964 efetivamente nomeia.

Lista de verificação do defensor

  1. Inventarie os clientes OpenVPN para Windows e Android na janela 2.7.x e implante a 2.7.8 ou mais recente.
  2. Analise os repositórios de certificados em busca de bytes NULL incorporados antes da atualização das frotas OpenSSL.
  3. Ensaie reinícios DCO e multi-cliente em um nó de homologação para absorver as mudanças de comportamento de reinício de instância.
  4. Mantenha as implantações tls-crypt-v2 em builds corrigidos mesmo quando uma correção não tiver um ID de CVE.
  5. Cite os avisos primários nos tickets de mudança em vez de apenas blogs secundários.
  6. Separe os tickets de cliente OpenVPN dos tickets de kernel WireGuard e Zephyr.

Conclusão: trate o OpenVPN 2.7.8 como um pacote de segurança e disponibilidade para análise do canal de controle, higiene de certificados, quoting de processos no Windows e estabilidade do offload do canal de dados em servidores grandes. Em seguida, verifique com seus próprios hashes de pacotes e laboratórios de homologação antes de declarar o cluster de CVE encerrado.