Tecnología VPN
OpenVPN 2.7.8 se publicó alrededor del 6–7 de octubre de 2026 como una actualización de mantenimiento con cuatro elementos de refuerzo de seguridad. Tres tienen identificadores CVE: CVE-2026-84790 (bytes NULL en los sujetos de certificados), CVE-2026-88964 (subdesbordamiento sin signo en el manejo de domain-search / PUSH_REPLY en Windows y Android para las versiones 2.7_alpha3 hasta 2.7.7) y CVE-2026-84256 (continuación del endurecimiento de comillas de CreateProcess/cmd.exe en Windows). Un cuarto cambio de tls-crypt-v2 que impide que los clientes reenvíen ciegamente claves encapsuladas cuando no hay material de clave disponible se dejó sin CVE bajo la política de robustez CRA de Italia. La versión también mejora la estabilidad de DCO multi-cliente, incluyendo el reinicio de una sola instancia en lugar de que se caiga todo el servidor cuando la instalación de una clave de peer entra en carrera con la eliminación del peer. Linux Compatible indica que la versión fue etiquetada por Gert Doering tras unos 22 commits en 40 archivos de 11 colaboradores, sobre la base de la revisión arquitectónica 2.7.0 de febrero. Los operadores que ejecutan servidores multi-cliente o DCO acelerado por kernel deben tratar 2.7.8 como una versión de mantenimiento de disponibilidad y seguridad, no como un lanzamiento de funciones. Los equipos de herramientas de certificados deben inventariar las cadenas de sujeto en busca de bytes NULL incrustados antes de actualizar las flotas de OpenSSL, porque certificados aceptados previamente pueden fallar de repente en las comprobaciones de handshake. Los administradores de Windows deben probar por regresión los scripts que invocan el shell a través de CreateProcess alrededor de OpenVPN tras el endurecimiento continuo de comillas.
Si ejecuta clientes comunitarios de OpenVPN 2.7.x en Windows/Android o servidores DCO multi-cliente, programe 2.7.8 y vuelva a probar los inventarios de certificados en busca de bytes NULL incrustados. Registre las versiones de los paquetes y las URL de los avisos en el ticket de cambio antes de cerrar el elemento.
Fuente: Linux Compatible
La página CVE-2026-88964 de la wiki de la comunidad OpenVPN indica que un subdesbordamiento de enteros permite a servidores remotos autenticados provocar denegación de servicio o revelación de memoria mediante opciones de búsqueda de dominio manipuladas, nombra a Cole Munz como informante, enlaza el issue privado de GitHub OpenVPN/openvpn-private-issues#178 y dirige a los operadores a la entrada ReleaseHistory de openvpn-2.7.8 fechada el 7 de octubre de 2026. La wiki también enlaza el ancla community ReleaseHistory de openvpn-2.7.8 publicado el 7 de octubre de 2026 y la ruta del issue privado de GitHub usada durante la divulgación coordinada. Los lectores deben tratar los dominios de búsqueda DNS de PUSH_REPLY como material de opción sensible: solo se debe permitir que los envíen servidores de confianza, y se deben capturar las pantallas Acerca de del cliente tras la actualización para demostrar que 2.7.8 o posterior se ejecuta en endpoints Windows y Android en la ventana 2.7.x previamente afectada.
Trate las opciones de búsqueda DNS de PUSH_REPLY solo de servidores de confianza y confirme que las pantallas Acerca de del cliente muestren 2.7.8+ tras la actualización. Registre las versiones de los paquetes y las URL de los avisos en el ticket de cambio antes de cerrar el elemento.
Fuente: OpenVPN community wiki
Seguridad de Internet
El 5 de octubre de 2026, una discusión en la lista de correo del kernel de Linux sobre un parche noise de WireGuard describió un modo de fallo en el que WireGuard puede aceptar una respuesta de handshake antigua después de que haya comenzado una iniciación más reciente, reinstalando claves antiguas y restableciendo los contadores de transporte y el estado de replay. Eso permitiría reutilización de nonce, replay y falsificación de paquetes, rompiendo las garantías de confidencialidad e integridad. La corrección propuesta compara secretos efímeros bajo el bloqueo de escritura para rechazar respuestas de iniciaciones reemplazadas; Jason A. Donenfeld cuestionó el flujo exacto en una respuesta del mismo hilo. El hilo enfatiza que aceptar una respuesta de handshake obsoleta después de que haya comenzado una iniciación más reciente puede reinstalar claves más antiguas y restablecer el estado de replay. Eso es una preocupación de confidencialidad e integridad para peers de WireGuard en el kernel, distinta de las aplicaciones de marca VPN en espacio de usuario. Se deben vigilar las distribuciones por backports estables; no asuma que un parche de lista de correo ya está presente en cada paquete de kernel que ejecuta su flota.
Los consumidores de WireGuard en el kernel y en las distribuciones deben vigilar los backports estables de los parches de rechazo de respuestas de handshake y evitar asumir que las aplicaciones VPN de espacio de usuario por sí solas cubren los peers de WireGuard en el kernel. Registre las versiones de los paquetes y las URL de los avisos en el ticket de cambio antes de cerrar el elemento.
Fuente: LKML / IU archive
El registro de NVD para CVE-2026-13735 describe un error de implementación de WireGuard en Zephyr RTOS: los mensajes keepalive (texto plano vacío de 16 bytes más etiqueta Poly1305) se aceptaban antes del descifrado, por lo que la etiqueta Poly1305 nunca se verificaba. Un atacante que conociera o obtuviera por fuerza bruta un índice de receptor en texto claro podría falsificar señales de estado keepalive sin claves de sesión. La corrección obliga a que las cargas útiles de 16 bytes pasen por el descifrado y las comprobaciones anti-replay. El impacto se limita a la integridad de las señales de estado, no a la inyección de texto plano ni a la toma de control de la sesión. La descripción de NVD aclara que los keepalives falsificados fallan la verificación Poly1305 tras la corrección y se contabilizan como fallos de autenticación. En la ruta anterior a la corrección no se descifra ni se inyecta texto plano, y los endpoints y los temporizadores de liveness no se actualizaban con el retorno anticipado, por lo que la inyección de tráfico y la toma de control de sesión quedan fuera del alcance de este defecto concreto. Los equipos de seguridad de producto aun así deben aplicar el parche, porque las señales falsificadas de VPN conectada pueden inducir a error a los planos de gestión y a los operadores.
Los productos embebidos/IoT que incluyen Zephyr WireGuard deben incorporar la corrección de keepalive autenticado y no equiparar este CVE con WireGuard del kernel de Linux. Registren las versiones de los paquetes y las URL de los avisos en el ticket de cambio antes de cerrar el elemento.
Fuente: NVD — CVE-2026-13735
Regulación
El artículo de Linux Compatible sobre la 2.7.8 señala que las directrices de la Computer Resilience Agency (CRA) de Italia se citaron como motivo de que una corrección de interrupción de clientes tls-crypt-v2 no recibiera CVE: un servidor malicioso que impide que un cliente funcione correctamente se clasificó como degradación de la robustez y no como un fallo de confidencialidad o integridad. Esa decisión de política no elimina la necesidad operativa de aplicar el parche, pero sí cambia cómo los sistemas de tickets de cumplimiento pueden etiquetar el cambio. Los programas de seguridad que solo abren tickets cuando existe un ID de CVE pasarán por alto esta clase de cambio a menos que la revisión de las notas de la versión forme parte del proceso de admisión. Documente la justificación de la CRA en el cuerpo del ticket y siga exigiendo verificación en staging para clientes tls-crypt-v2 tras la 2.7.8, porque los fallos de disponibilidad frente a pares autenticados siguen siendo costosos durante la respuesta a incidentes.
Los programas de seguridad deben hacer seguimiento de las correcciones de robustez sin CVE en clientes VPN cuando las políticas al estilo CRA omiten identificadores. Registre las versiones de los paquetes y las URL de los avisos en el ticket de cambio antes de cerrar el elemento.
Fuente: Linux Compatible
Foros
La entrada pública de la wiki de CVE de OpenVPN para 88964 enlaza de forma cruzada la ruta del rastreador privado de incidencias de GitHub OpenVPN/openvpn-private-issues#178 y el ancla de ReleaseHistory de la comunidad para 2.7.8, lo que ilustra el patrón del proyecto de publicar nombres de informantes y números de incidencias privadas junto con las notas de la versión en lugar de parches silenciosos. Partir de las páginas de anuncios de seguridad del propio proyecto reduce el riesgo de perseguir resúmenes secundarios incompletos. Contraste los nombres de los informantes, las referencias a incidencias privadas y los anclas de ReleaseHistory antes de cerrar los tickets de vulnerabilidad como mitigados.
Al hacer el triage de CVE de VPN, parta de la wiki de anuncios de seguridad del propio proyecto y de los anclas de ReleaseHistory antes que de los agregadores secundarios. Registre las versiones de los paquetes y las URL de los avisos en el ticket de cambio antes de cerrar el elemento.
Fuente: OpenVPN community wiki
Proveedores
Linux Compatible informa de que el equipo de Access Server de OpenVPN Inc. registró el error de condición de carrera de iroute corregido en 2.7.8, en el que las rutas por cliente se eliminaban durante una limpieza diferida de varias instancias en lugar de en el momento real de salida del cliente, con el riesgo de dejar sistemas sin rutas en condiciones de carrera de reconexión. El mismo artículo señala que grupos de investigación externos como BreachX (informe del byte NULL en certificados) alimentan la cadencia de seguridad de 2.7.x. El entorno de staging debe incluir tormentas de reconexión que ejerciten la instalación y la eliminación de rutas mientras los clientes oscilan. Si las rutas desaparecen bajo carga tras la actualización, capture los registros de netlink y de instancia antes de seguir desplegando. La participación de BreachX en el informe del byte NULL en certificados también ilustra por qué los canales de investigación externos importan para la cadencia 2.7.x de OpenVPN.
Access Server y los operadores de DCO a gran escala deben validar el comportamiento de limpieza de rutas en staging tras la 2.7.8 antes de las oleadas de producción. Registre las versiones de los paquetes y las URL de los avisos en el ticket de cambio antes de cerrar el elemento.
Fuente: Linux Compatible