La versión de mantenimiento 2.7.8 de OpenVPN (debate público fechado el 7 de octubre de 2026) agrupa tres correcciones etiquetadas con CVE más un cambio de robustez de tls-crypt-v2 que deliberadamente no lleva ID de CVE. Esta nota de seguridad reúne los avisos principales para que los operadores prioricen clientes Windows y Android, herramientas de certificados y servidores DCO multicliente, sin tratar los blogs de marketing como la única fuente de verdad.

Encrypt-then-MAC authenticated encryption construction diagram
Fuente: Wikimedia Commons (RokerHRO) — Cifrado autenticado EtM

Fuentes primarias

CVE-2026-88964 — subdesbordamiento de domain search

La wiki de la comunidad indica que un subdesbordamiento de enteros en OpenVPN en Windows y Android permite que servidores autenticados remotos provoquen denegación de servicio o revelación de memoria mediante opciones de domain search manipuladas en el manejo de PUSH_REPLY. Se trata de una clase clásica de error de «par de confianza, opciones hostiles»: la autenticación ya se había completado, pero el análisis de opciones aún confiaba demasiado en la aritmética de longitudes. El impacto es denegación de servicio y posible revelación de memoria, no una afirmación gratuita de ejecución remota de código en el texto público de la wiki. La corrección se incluye en 2.7.8.

Los defensores deben asumir que cualquier cliente que siga en 2.7.7 o anterior dentro de la ventana afectada permanece expuesto al conectarse a un endpoint hostil pero autenticado, incluidos concentradores empresariales comprometidos y servidores de laboratorio mal controlados. La precondición es fácil de malinterpretar: no se trata de un extraño no autenticado que dispara paquetes contra un cliente aleatorio. Requiere que el cliente ya confíe lo suficiente en el par para completar la autenticación y aceptar opciones de PUSH_REPLY. Los concentradores comprometidos, los laboratorios de prueba maliciosos y los perfiles mal emitidos siguen siendo vías realistas. No se debe inflar el aviso hasta convertirlo en una narrativa de ejecución remota de código no autenticada que la wiki de OpenVPN no afirma.

CVE-2026-84790 — bytes NULL en los sujetos de certificados

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

Linux Compatible informa de que ahora se rechazan los certificados con bytes NULL incrustados en las cadenas del subject. Las compilaciones OpenSSL antes se arriesgaban a parsers que se detienen en el primer byte NULL; las compilaciones mbedTLS ya rechazaban esos certificados. Vivek Parikh de BreachX reportó el problema; Max Fillinger implementó la corrección. Impacto operativo: los certificados archivados o elaborados de forma maliciosa que antes «funcionaban» en OpenSSL pueden fallar tras la actualización. Los equipos de herramientas de certificados deberían escanear los inventarios antes de un despliegue masivo y tratar los fallos repentinos de handshake posteriores a 2.7.8 como una señal de higiene de certificados y no como un percance de red aleatorio.

Ese rechazo también puede romper herramientas heredadas que incrustaron accidentalmente caracteres NUL al generar cadenas del subject. La rotura es deseable desde una perspectiva de seguridad del parser, pero las ventanas de cambio necesitan un paso de inventario. Combine la actualización de OpenVPN con revisiones del texto de los certificados o informes de PKI empresarial que marquen bytes no imprimibles en los subjects antes de declarar el despliegue completo.

CVE-2026-84256 — entrecomillado de CreateProcess en Windows

La versión 2.7.8 continúa el endurecimiento en torno al entrecomillado de la línea de comandos de Windows para que los caracteres especiales de cmd.exe no puedan provocar la expansión de variables dentro de argumentos entrecomillados. Lev Stipakov implementó el trabajo; Darren Carreras lo reportó. El mismo número de CVE se abordó parcialmente en 2.7.7, por lo que 2.7.8 es una segunda pasada sobre la misma ruta y no un error de Windows no relacionado. Los scripts que lanzan un shell en torno a OpenVPN en Windows merecen pruebas de regresión tras la actualización, especialmente cuando pasan rutas de perfil controladas por el usuario o argumentos auxiliares a través de CreateProcess.

Robustez de tls-crypt-v2 sin un CVE

Durante los handshakes de tls-crypt-v2, OpenVPN podía intentar añadir una clave de cliente encapsulada incluso cuando no había material de clave disponible, confiando demasiado en una solicitud de reenvío del peer. El cambio de 2.7.8 detiene esa confianza ciega. Según la orientación de la Computer Resilience Agency de Italia transmitida por Linux Compatible, «un servidor malicioso puede impedir que el cliente funcione correctamente» se trató como degradación de robustez y no como un CVE de confidencialidad o integridad. Los operadores aun así deberían instalarlo: los ataques de disponibilidad contra clientes VPN son operativamente costosos incluso cuando carecen del barniz de un CVE, y los sistemas de gestión de cambios deberían registrar explícitamente el endurecimiento sin CVE.

El identificador ausente ilustra una lección más amplia para los programas de seguridad VPN. Las políticas que omiten los ID de CVE para problemas de disponibilidad pura contra peers ya autenticados ocultarán parte de 2.7.8 a menos que los operadores registren elementos explícitos de robustez. El artículo de Linux Compatible del 7 de octubre de 2026 es un contexto secundario útil, pero los tickets de cambio deberían seguir enlazando las páginas ReleaseHistory y el wiki de CVE de OpenVPN como evidencia primaria.

Trabajo adyacente de disponibilidad que los operadores no deberían ignorar

Más allá de la lista de CVE, 2.7.8 cambia el comportamiento multi-client y de offload del data-channel. Las rutas por cliente se eliminan en el momento real de salida y no durante la limpieza diferida de múltiples instancias, corrigiendo una condición de carrera que podía dejar sistemas sin rutas. Un socket netlink dedicado separa el trabajo síncrono de las notificaciones asíncronas. Cuando falla una operación de peer o de clave después de que el peer ya ha desaparecido del kernel, OpenVPN reinicia una sola instancia en lugar de matar todo el servidor. Esas correcciones de disponibilidad y de corrección funcional importan tanto como los CVE para servidores grandes bajo tormentas de reconexión, y las reportó en parte el equipo de Access Server de OpenVPN Inc. según Linux Compatible.

Lo que esto no es

  • No es un aviso de WireGuard. Las discusiones independientes de octubre de 2026 sobre WireGuard, incluidos los parches de handshake-response de LKML y el CVE-2026-13735 de autenticación keepalive de Zephyr, pertenecen a sus propias notas.
  • No es marketing de notas de lanzamiento de un proveedor para una marca comercial de VPN de consumo.
  • No es permiso para ejecutar servidores no confiables «para probar» la clase de error de servidor autenticado.

En octubre de 2026 también hubo debates relacionados con WireGuard que los operadores pueden confundir con parches de OpenVPN. El hilo de handshake-response de LKML y el problema de keepalive de Zephyr CVE-2026-13735 de NVD son reales, pero no parchean OpenVPN 2.7.8, y OpenVPN 2.7.8 no los remedia. Mantenga los inventarios separados por binario: OpenVPN comunitario, WireGuard en el kernel, WireGuard en espacio de usuario, pilas Zephyr y aplicaciones VPN móviles propietarias. Mezclar esos linajes en una sola hoja de cálculo de «VPN CVE» es la forma en que los equipos pasan por alto los clientes OpenVPN de Windows y Android que CVE-2026-88964 realmente nombra.

Lista de verificación para defensores

  1. Inventarie los clientes OpenVPN de Windows y Android en la ventana 2.7.x y despliegue 2.7.8 o posterior.
  2. Examine los almacenes de certificados en busca de bytes NULL incrustados antes de actualizar las flotas de OpenSSL.
  3. Ensaye los reinicios de DCO y de múltiples clientes en un nodo de ensayo para absorber los cambios de comportamiento de reinicio de instancia.
  4. Mantenga las implementaciones de tls-crypt-v2 en compilaciones parcheadas incluso cuando una corrección carezca de un ID de CVE.
  5. Cite los avisos primarios en los tickets de cambio en lugar de solo blogs secundarios.
  6. Separe los tickets de clientes OpenVPN de los tickets de kernel de WireGuard y de Zephyr.

Conclusión: trate OpenVPN 2.7.8 como un paquete de seguridad y disponibilidad para el análisis del canal de control, la higiene de certificados, el entrecomillado de procesos en Windows y la estabilidad de la descarga del canal de datos en servidores grandes. Luego verifique con sus propios hashes de paquetes y laboratorios de ensayo antes de declarar cerrado el clúster de CVE.