Tecnologia VPN

O OpenVPN 2.7.8 foi lançado por volta de 6–7 de outubro de 2026 como uma atualização de manutenção com quatro itens de endurecimento de segurança. Três possuem IDs CVE: CVE-2026-84790 (bytes NULL em subjects de certificados), CVE-2026-88964 (underflow sem sinal no tratamento de domain-search / PUSH_REPLY no Windows e no Android para as versões 2.7_alpha3 até 2.7.7) e CVE-2026-84256 (continuação do endurecimento de quoting do CreateProcess/cmd.exe no Windows). Uma quarta alteração de tls-crypt-v2 que impede os clientes de reenviar cegamente chaves encapsuladas quando não há material de chave disponível ficou sem CVE sob a política de robustez CRA da Itália. A versão também melhora a estabilidade do DCO multi-cliente, incluindo o reinício de uma única instância em vez de derrubar o servidor inteiro quando a instalação de chave de um peer corre em condição de corrida com a remoção do peer. O Linux Compatible observa que a versão foi marcada por Gert Doering após cerca de 22 commits em 40 arquivos de 11 colaboradores, apoiando-se na reformulação arquitetural da 2.7.0 em fevereiro. Operadores que executam servidores multi-cliente ou DCO acelerado por kernel devem tratar a 2.7.8 como uma versão de manutenção de disponibilidade e segurança, e não como um lançamento de funcionalidades. As equipes de ferramentas de certificados devem inventariar as strings de subject em busca de bytes NULL embutidos antes da atualização das frotas OpenSSL, porque certificados anteriormente aceitos podem falhar de súbito nas verificações de handshake. Administradores Windows devem testar regressão em scripts que invocam shell via CreateProcess em torno do OpenVPN após o endurecimento contínuo de quoting.

Se você executa clientes OpenVPN community 2.7.x no Windows/Android ou servidores DCO multi-cliente, agende a 2.7.8 e reteste os inventários de certificados em busca de bytes NULL embutidos. Registre as versões dos pacotes e as URLs dos avisos no ticket de mudança antes de encerrar o item.

Fonte: Linux Compatible

A página CVE-2026-88964 da wiki da comunidade OpenVPN afirma que um integer underflow permite que servidores autenticados remotos provoquem negação de serviço ou divulgação de memória por meio de opções de domain search manipuladas, nomeia Cole Munz como relator, vincula o issue privado do GitHub OpenVPN/openvpn-private-issues#178 e aponta os operadores para a entrada ReleaseHistory do openvpn-2.7.8 datada de 7 de outubro de 2026. A wiki também vincula o âncora ReleaseHistory da comunidade para o openvpn-2.7.8 lançado em 7 de outubro de 2026 e o caminho do issue privado do GitHub usado durante a divulgação coordenada. Os leitores devem tratar os domínios de pesquisa DNS de PUSH_REPLY como material de opção sensível: apenas servidores confiáveis devem ter permissão para enviá-los, e as telas About do cliente devem ser capturadas após a atualização para comprovar que a 2.7.8 ou mais recente está em execução em endpoints Windows e Android na janela 2.7.x anteriormente afetada.

Trate as opções de pesquisa DNS de PUSH_REPLY apenas de servidores confiáveis e confirme que as telas About do cliente mostram 2.7.8+ após a atualização. Registre as versões dos pacotes e as URLs dos avisos no ticket de mudança antes de encerrar o item.

Fonte: Wiki da comunidade OpenVPN

Segurança da Internet

Em 5 de outubro de 2026, a discussão na lista de e-mail do kernel Linux sobre um patch noise do WireGuard descreveu um modo de falha em que o WireGuard pode aceitar uma resposta de handshake antiga depois que uma iniciação mais nova já começou, reinstalando chaves antigas e redefinindo contadores de transporte e o estado de replay. Isso habilitaria reutilização de nonce, replay e falsificação de pacotes, quebrando as garantias de confidencialidade e integridade. A correção proposta compara segredos efêmeros sob o write lock para rejeitar respostas de iniciações substituídas; Jason A. Donenfeld questionou o fluxo exato em resposta no mesmo tópico. O tópico enfatiza que aceitar uma resposta de handshake obsoleta depois que uma iniciação mais nova já começou pode reinstalar chaves mais antigas e redefinir o estado de replay. Trata-se de uma preocupação de confidencialidade e integridade para peers WireGuard in-kernel, distinta dos aplicativos de marcas VPN em userspace. As distribuições devem ser monitoradas em busca de backports estáveis; não presuma que um patch da lista de e-mail já esteja presente em todos os pacotes de kernel que sua frota executa.

Os consumidores de WireGuard no kernel e nas distribuições devem acompanhar backports estáveis dos patches de rejeição de resposta de handshake e evitar assumir que apenas os aplicativos VPN em userspace cobrem os peers WireGuard in-kernel. Registre as versões dos pacotes e as URLs dos avisos no ticket de mudança antes de encerrar o item.

Fonte: LKML / IU archive

O registro da NVD para CVE-2026-13735 descreve um bug na implementação WireGuard do Zephyr RTOS: mensagens keepalive (texto simples vazio de 16 bytes mais tag Poly1305) eram aceitas antes da descriptografia, de modo que a tag Poly1305 nunca era verificada. Um invasor que soubesse ou obtivesse por força bruta um índice de receptor em texto simples poderia falsificar sinais de status de keepalive sem chaves de sessão. A correção força payloads de 16 bytes a passarem pela descriptografia e por verificações anti-replay. O impacto limita-se à integridade dos sinais de status, não à injeção de texto simples nem à tomada de sessão. A descrição da NVD esclarece que keepalives forjados falham na verificação Poly1305 após a correção e são contabilizados como falhas de autenticação. Nenhum texto simples é descriptografado ou injetado no caminho anterior à correção, e os endpoints e os temporizadores de liveness não eram atualizados pelo retorno antecipado, portanto a injeção de tráfego e a tomada de sessão estão fora do escopo deste defeito específico. As equipes de segurança de produto ainda assim devem aplicar o patch, porque sinais falsificados de VPN conectada podem induzir ao erro planos de gerenciamento e operadores.

Produtos embarcados/IoT que incluem o WireGuard do Zephyr devem incorporar a correção de keepalive autenticado e não igualar esta CVE ao WireGuard do kernel Linux. Registre as versões dos pacotes e as URLs dos avisos no ticket de mudança antes de encerrar o item.

Fonte: NVD — CVE-2026-13735

Regulamentação

O artigo da Linux Compatible sobre a 2.7.8 observa que as diretrizes da Computer Resilience Agency (CRA) da Itália foram citadas como o motivo pelo qual uma correção de interrupção de cliente tls-crypt-v2 não recebeu CVE: um servidor malicioso que impede um cliente de funcionar corretamente foi classificado como degradação de robustez, e não como falha de confidencialidade ou integridade. Essa escolha de política não elimina a necessidade operacional de aplicar o patch, mas altera a forma como os sistemas de tickets de conformidade podem rotular a alteração. Programas de segurança que só abrem tickets quando existe um ID de CVE perderão essa classe de alteração, a menos que a revisão das notas de lançamento faça parte do processo de entrada. Documente a fundamentação da CRA no corpo do ticket e ainda exija verificação em staging para clientes tls-crypt-v2 após a 2.7.8, porque falhas de disponibilidade contra pares autenticados continuam caras durante a resposta a incidentes.

Os programas de segurança devem acompanhar correções de robustez sem CVE em clientes VPN quando políticas no estilo CRA omitem identificadores. Registre as versões dos pacotes e os URLs dos avisos no ticket de alteração antes de encerrar o item.

Fonte: Linux Compatible

Fóruns

A entrada pública da wiki de CVE da OpenVPN para 88964 faz ligação cruzada com o caminho do rastreador privado de issues do GitHub OpenVPN/openvpn-private-issues#178 e com a âncora comunitária ReleaseHistory da 2.7.8, ilustrando o padrão do projeto de publicar nomes de relatores e números de issues privadas junto das notas de lançamento, em vez de patches silenciosos. Começar pelas páginas de anúncio de segurança pertencentes ao projeto reduz o risco de perseguir resumos secundários incompletos. Faça a verificação cruzada dos nomes dos relatores, das referências a issues privadas e das âncoras ReleaseHistory antes de encerrar tickets de vulnerabilidade como mitigados.

Ao triar CVEs de VPN, comece pela wiki de anúncios de segurança do próprio projeto e pelas âncoras ReleaseHistory antes dos agregadores secundários. Registre as versões dos pacotes e os URLs dos avisos no ticket de alteração antes de encerrar o item.

Fonte: Wiki da comunidade OpenVPN

Fornecedores

A Linux Compatible relata que a equipe Access Server da OpenVPN Inc. registrou o bug de corrida iroute corrigido na 2.7.8, em que rotas por cliente eram removidas durante a limpeza atrasada de múltiplas instâncias, em vez de no momento real de saída do cliente, com o risco de deixar sistemas sem rotas em condições de corrida de reconexão. O mesmo artigo observa que grupos de pesquisa externos como a BreachX (relatório de NULL-byte em certificado) alimentam o ritmo de segurança da série 2.7.x. O staging deve incluir tempestades de reconexão que exercitem a instalação e a remoção de rotas enquanto os clientes oscilam. Se as rotas desaparecerem sob carga após a atualização, capture os logs de netlink e das instâncias antes de avançar. O envolvimento da BreachX no relatório de NULL-byte em certificado também ilustra por que pipelines de pesquisa externos importam para o ritmo da série 2.7.x da OpenVPN.

Operadores de Access Server e grandes operadores DCO devem validar o comportamento de limpeza de rotas em staging após a 2.7.8 antes das ondas de produção. Registre as versões dos pacotes e os URLs dos avisos no ticket de alteração antes de encerrar o item.

Fonte: Linux Compatible