OpenVPN acaba de publicar una actualización especialmente importante para administradores de servidores VPN. OpenVPN 2.7.8 ya está disponible con nuevas correcciones de seguridad, validaciones más estrictas de certificados y varias mejoras destinadas a evitar caídas, carreras internas y problemas de estabilidad en servidores que utilizan Data Channel Offload sobre Linux.
La nueva versión fue publicada oficialmente el 7 de octubre de 2026 y llega apenas un mes después de OpenVPN 2.7.7, continuando una serie de actualizaciones dedicadas a fortalecer uno de los proyectos VPN open source más utilizados en servidores Linux, infraestructura empresarial y acceso remoto.
Entre los cambios de seguridad aparecen CVE-2026-84790, CVE-2026-88964 y nuevas medidas relacionadas con CVE-2026-84256. OpenVPN también corrigió un problema durante el handshake de tls-crypt-v2 que podía provocar fallos en clientes cuando se conectaban a un servidor que se comportaba incorrectamente.
Sin embargo, para administradores Linux, algunas de las mejoras más interesantes están fuera de la lista de CVE: OpenVPN 2.7.8 corrige varias condiciones de carrera relacionadas con DCO, mejora la gestión de clientes que se reconectan y evita que determinados errores de un único peer puedan finalizar todo el proceso del servidor.
Puede leer también | OpenVPN Connect Client: una herramienta para conexiones VPN
OpenVPN 2.7.8 es principalmente una versión de seguridad y estabilidad
OpenVPN define esta publicación como una bugfix release.
No estamos ante una versión destinada a introducir una larga lista de funciones visibles para el usuario.
El objetivo es reforzar áreas como:
- Validación de certificados.
- Handshake TLS.
- Opciones DNS.
- Data Channel Offload.
- Gestión de peers.
- Reconexiones.
- Colas de servidores multipunto.
- Comportamiento frente a errores.
Precisamente este tipo de actualización puede ser especialmente importante en servidores VPN, donde la estabilidad y el comportamiento ante tráfico inesperado son más importantes que incorporar nuevas funciones visuales.
Tres CVE aparecen en las notas de seguridad
| Vulnerabilidad | Problema | Plataformas principales |
|---|---|---|
| CVE-2026-84790 | Bypass de identidad mediante bytes NUL dentro del certificado | Multiplataforma |
| CVE-2026-88964 | Integer underflow y acceso fuera de límites mediante PUSH_UPDATE | Windows y Android |
| CVE-2026-84256 | Problemas con expansión y quoting de comandos | Windows |
Para servidores Linux, CVE-2026-84790 es el problema de seguridad que merece mayor atención directa, mientras las importantes correcciones de DCO mejoran principalmente la robustez operativa.
CVE-2026-84790: certificados manipulados podían confundir la identidad
La vulnerabilidad más relevante de esta versión está identificada como:
CVE-2026-84790El problema afecta al tratamiento de determinados campos incluidos dentro del subject de certificados X.509.
OpenVPN podía aceptar cadenas que contenían un carácter:
NULembebido dentro de algunos valores.
El carácter NUL tiene una importancia particular en software escrito en C porque tradicionalmente representa el final de una cadena.
Una misma identidad podía interpretarse de formas diferentes
Imagine conceptualmente una identidad:
usuario-admin[NUL]usuario-normal
Una parte del software podría interpretar:
usuario-admin
mientras otra parte podría considerar la cadena completa.
Esa diferencia puede convertirse en un problema cuando el contenido del certificado se utiliza para identificar al usuario.
El resultado potencial es una forma de:
suplantación de identidad entre usuarios autenticados mediante certificados cuidadosamente construidos.
OpenVPN 2.7.8 adopta una solución estricta
En lugar de intentar interpretar estos certificados ambiguos, OpenVPN ha optado ahora por rechazarlos.
La lógica puede resumirse así:
Certificado recibido
|
v
Examinar subject
|
v
¿contiene NUL embebido?
|
+---+---+
| |
NO SÍ
| |
continuar rechazar
La nueva versión considera esos certificados:
invalidy evita que continúe la autenticación.
Las versiones desde OpenVPN 2.3.0 estaban afectadas
El aviso oficial del proyecto indica que CVE-2026-84790 afecta a:
OpenVPN 2.3.0 hasta OpenVPN 2.7.7La corrección aparece en:
OpenVPN 2.7.8Esto convierte el problema en particularmente relevante porque el código vulnerable existía desde hace bastante tiempo.
No significa que cualquier persona pueda entrar sin certificado
Existe una precisión importante.
La vulnerabilidad es descrita por OpenVPN como una posibilidad de:
identity/authentication bypass
pero el escenario implica un usuario remoto que ya dispone de un certificado autenticable cuidadosamente preparado.
No debe interpretarse como:
Atacante cualquiera
|
Internet
|
sin certificado
|
ROOT / VPN
El escenario se parece más a:
certificado válido o autorizado
|
v
subject especialmente construido
|
v
interpretación inconsistente
|
v
posible suplantación
La diferencia es importante para evaluar correctamente el riesgo.
CVE-2026-88964 afecta a opciones DNS recibidas desde el servidor
La segunda vulnerabilidad nueva es:
CVE-2026-88964Se trata de un integer underflow relacionado con la limpieza de:
domain_search_listcuando el cliente procesa determinadas actualizaciones de configuración DNS.
Un servidor OpenVPN autenticado y malicioso podía enviar opciones construidas especialmente mediante:
PUSH_UPDATEy provocar un comportamiento incorrecto.
Podía terminar en DoS o exposición de memoria
El aviso oficial indica que CVE-2026-88964 puede producir:
- Denegación de servicio.
- Acceso fuera de los límites de memoria.
- Potencial exposición de memoria.
El problema afecta principalmente a:
Windows Android
y a versiones:
OpenVPN 2.7_alpha3 hasta 2.7.7OpenVPN 2.7.8 corrige el cálculo que podía producir el underflow.
¿Qué es un integer underflow?
Imagine una variable sin signo cuyo valor es:
0y el programa intenta restar:
1En lugar de convertirse en:
-1puede transformarse en un número extremadamente grande dependiendo del tipo de dato utilizado.
Conceptualmente:
0 - 1 | v underflow | v valor enorme | v cálculo de memoria incorrecto
Eso puede provocar lecturas o escrituras fuera del espacio esperado.
CVE-2026-84256 recibe endurecimiento adicional
La tercera referencia CVE incluida nuevamente en OpenVPN 2.7.8 es:
CVE-2026-84256Este problema pertenece específicamente al cliente Windows y está relacionado con cómo se construyen comandos entregados a:
CreateProcess()cuando determinados caracteres especiales son interpretados posteriormente por:
cmd.exeOpenVPN 2.7.7 ya había incorporado una corrección para esta vulnerabilidad.
La versión 2.7.8 añade un endurecimiento adicional para impedir que cmd.exe expanda variables dentro de argumentos entrecomillados.
Por tanto, no debería describirse este tercer punto como una vulnerabilidad completamente nueva descubierta en 2.7.8, sino como un refuerzo de la corrección introducida anteriormente.
Existe además una corrección de seguridad sin CVE
OpenVPN 2.7.8 también corrige un problema relacionado con:
tls-crypt-v2Durante el handshake, un cliente podía intentar añadir una clave envuelta incluso cuando no existía material criptográfico disponible.
Ese comportamiento podía desencadenarse al conectarse contra un servidor que enviara una respuesta incorrecta.
La nueva versión evita continuar cuando falta el material necesario.
¿Por qué no recibió un CVE?
El propio proyecto explica que no considera esta situación suficientemente significativa para asignarle un CVE porque un servidor malicioso ya dispone de múltiples formas de impedir que el cliente funcione correctamente.
Es decir:
Servidor malicioso
|
v
puede impedir la conexión
de todas formas
La corrección sigue siendo útil porque hace el código más robusto y evita que un estado inesperado continúe propagándose durante el handshake.
Para Linux, las grandes mejoras están en DCO
Los administradores de servidores Linux deberían prestar especial atención a las correcciones relacionadas con:
Data Channel Offload — DCO.
DCO permite mover una parte importante del procesamiento del tráfico VPN desde el espacio de usuario hacia el kernel.
El esquema tradicional es:
Paquete | v OpenVPN userspace | cifrar / descifrar | v kernel
Con DCO:
Control | OpenVPN userspace | v kernel DCO | datos cifrados
Esto reduce cambios de contexto y puede aumentar considerablemente el rendimiento.
Linux incorpora DCO directamente desde el kernel 6.16
OpenVPN explica que desde:
Linux 6.16el soporte DCO está integrado dentro del kernel upstream.
OpenVPN 2.7 puede utilizar directamente esa infraestructura.
Para kernels anteriores puede emplearse el módulo externo correspondiente.
Eso hace que las correcciones de DCO sean particularmente relevantes para servidores Linux modernos.
OpenVPN 2.7.8 corrige carreras de Netlink en Linux
Una de las correcciones más importantes está relacionada con la comunicación entre OpenVPN en espacio de usuario y el módulo DCO del kernel.
Linux utiliza:
Netlinkpara intercambiar determinados mensajes entre procesos de usuario y componentes del kernel.
OpenVPN estaba utilizando operaciones:
- Síncronas.
- Asíncronas.
sobre esa comunicación.
En determinadas circunstancias podía aparecer una carrera entre ambos tipos de mensajes.
Ahora OpenVPN utiliza dos sockets Netlink separados
La solución implementada en 2.7.8 consiste en separar estrictamente ambos flujos.
OpenVPN
|
+---- Netlink socket 1
| |
| +--> operaciones síncronas
|
+---- Netlink socket 2
|
+--> notificaciones asíncronas
Esto reduce la posibilidad de que una respuesta esperada por una operación sea confundida o interferida por una notificación generada desde el kernel.
Para un servidor que mantiene cientos o miles de sesiones VPN, eliminar este tipo de carreras puede resultar mucho más importante que cualquier función nueva visible.
Las reconexiones rápidas también podían provocar problemas
OpenVPN utiliza iroutes para asociar determinadas redes con clientes específicos.
En versiones anteriores, cuando un cliente abandonaba una sesión, ciertas rutas podían eliminarse durante una fase tardía de limpieza.
Imagine:
Cliente A se desconecta
|
v
cleanup pendiente
|
+--------+
|
Cliente A reconecta
|
v
nueva ruta instalada
|
v
cleanup antiguo elimina ruta
El resultado podía dejar al sistema sin las rutas correctas para ese cliente.
OpenVPN 2.7.8 elimina las iroutes en el momento correcto
La nueva versión mueve esa operación al momento de salida real del cliente y no espera a la limpieza diferida de la instancia.
Esto evita una carrera especialmente incómoda en servidores donde los usuarios:
- Pierden conectividad temporalmente.
- Cambian de red.
- Alternan Wi-Fi y datos móviles.
- Reconectan automáticamente.
En todos esos escenarios puede existir una rápida sucesión de desconexión y reconexión.
Un fallo de un peer ya no debería tumbar todo el servidor
Este puede ser uno de los cambios operativos más importantes de OpenVPN 2.7.8.
Durante la configuración de DCO pueden ocurrir fallos cuando OpenVPN intenta:
- Crear un nuevo peer.
- Instalar material criptográfico.
- Actualizar claves.
Anteriormente, algunas de estas condiciones podían convertirse en un:
fatal errorcapaz de finalizar el proceso OpenVPN.
En un servidor multipunto esto es excesivo.
Ahora se reinicia la instancia problemática, no todo OpenVPN
La lógica de 2.7.8 pasa a ser:
Cliente tiene problema DCO
|
v
Error al crear peer
o instalar clave
|
v
NO finalizar servidor completo
|
v
propagar error
|
v
reiniciar instancia del cliente
Esto mejora la disponibilidad general.
Un usuario con una sesión problemática no debería provocar que todos los demás clientes pierdan el servicio.
¿Por qué podían ocurrir esos errores?
El handshake entre userland y DCO tiene inevitablemente ciertas condiciones de carrera.
Por ejemplo:
kernel elimina peer
por timeout
|
v
userspace todavía
no recibió notificación
|
v
intenta instalar nueva clave
|
v
peer ya no existe
Eso no significa necesariamente que exista una corrupción del sistema.
Puede tratarse simplemente de una diferencia temporal entre el estado que conoce el kernel y el que todavía conoce el proceso OpenVPN.
OpenVPN 2.7.8 trata ahora mejor esta situación.
También deja de consultar estadísticas inútiles al desconectar clientes
La versión anterior intentaba solicitar estadísticas del peer durante su desconexión.
El problema era que en ese momento el peer ya había sido eliminado dentro del kernel.
Por tanto, la consulta:
pedir estadísticas
|
v
peer ya eliminado
|
v
error
no proporcionaba realmente la información esperada.
Además, generaba operaciones innecesarias sobre todos los peers.
OpenVPN 2.7.8 elimina ese comportamiento.
Menos consultas innecesarias puede significar mejor eficiencia
En un servidor con diez usuarios probablemente la diferencia sea mínima.
Pero en una infraestructura donde se producen constantemente:
- Conexiones.
- Desconexiones.
- Reconexiones.
- Cambios de claves.
evitar consultas que nunca iban a devolver información útil simplifica el código y reduce trabajo innecesario.
También se corrige un posible deadlock en servidores p2mp
OpenVPN 2.7.8 mejora el tratamiento de listas de buffers en servidores:
p2mpo point-to-multipoint.
Este es precisamente el modelo utilizado habitualmente cuando muchos clientes se conectan a un mismo servidor.
La versión corrige un problema que, bajo circunstancias muy específicas, podía provocar un:
server queue deadlockdurante la salida de un cliente.
Broadcast y multicast también reciben mejoras
La corrección está relacionada con cómo OpenVPN administra listas de buffers cuando existe tráfico:
- Broadcast.
- Multicast.
Estos escenarios pueden provocar que el mismo paquete deba manejarse para múltiples destinos.
El código de 2.7.8 mejora la administración de esas estructuras y evita condiciones donde la cola pudiera quedar bloqueada.
Qué significa todo esto para un servidor Linux
En conjunto, las correcciones pueden parecer extremadamente técnicas.
Pero operativamente tienen un significado muy sencillo.
OpenVPN 2.7.8 intenta reducir situaciones como:
cliente reconecta
|
v
ruta desaparece
peer DCO falla
|
v
servidor completo termina
Netlink recibe mensajes
en orden inesperado
|
v
estado inconsistente
cliente sale
|
v
cola del servidor bloqueada
En un servidor VPN empresarial, cualquiera de estos problemas puede terminar afectando a numerosos usuarios.
DCO sigue siendo una de las mejoras más importantes de OpenVPN moderno
Durante muchos años OpenVPN procesó prácticamente todo el canal de datos desde userspace.
DCO cambia esa arquitectura.
Al mover el procesamiento de datos al kernel puede proporcionar:
- Mayor rendimiento.
- Menor carga de CPU.
- Menos cambios user/kernel.
- Mejor escalabilidad.
Pero la integración también requiere que el estado del kernel y el del proceso OpenVPN permanezcan perfectamente sincronizados.
Las correcciones de 2.7.8 demuestran que esta capa continúa madurando.
OpenVPN 2.7 y Linux 6.16 simplifican DCO
En sistemas con kernel Linux 6.16 o posterior normalmente ya no es necesario instalar un módulo DCO externo.
Para verificar el kernel:
uname -rY para conocer la versión de OpenVPN:
openvpn --versionUn resultado actualizado debería comenzar con algo similar a:
OpenVPN 2.7.8¿Debo actualizar un servidor Linux?
Sí, especialmente si ya utiliza la rama OpenVPN 2.7.
La actualización combina una corrección de seguridad multiplataforma con varias mejoras específicamente relevantes para servidores Linux que utilizan DCO.
La prioridad aumenta si el servidor:
- Gestiona muchos clientes simultáneos.
- Utiliza certificados X.509 personalizados.
- Utiliza DCO.
- Presenta reconexiones frecuentes.
- Funciona como infraestructura VPN empresarial.
Primero comprueba qué versión tienes instalada
Ejecuta:
openvpn --versionTambién puedes consultar el paquete de la distribución.
Debian y Ubuntu:
apt policy openvpnFedora, RHEL, Rocky Linux o AlmaLinux:
dnf info openvpnNo todas las distribuciones publican la nueva versión al mismo tiempo
Este punto es fundamental.
Que OpenVPN haya publicado 2.7.8 no significa que todos los repositorios Linux tengan inmediatamente ese mismo paquete.
Las distribuciones pueden:
- Actualizar a 2.7.8.
- Mantener una versión anterior.
- Aplicar únicamente los parches de seguridad mediante backport.
Por ello no debe decidirse si un sistema está protegido únicamente observando:
2.7.8Los mantenedores de Debian, Ubuntu, RHEL y otras distribuciones pueden incorporar correcciones manteniendo un número de versión diferente.
OpenVPN mantiene repositorios oficiales para Linux
El proyecto proporciona además repositorios propios para diferentes distribuciones.
Para Debian y Ubuntu existen repositorios específicos de:
stable testing release/2.6 release/2.7
y paquetes para arquitecturas:
amd64 arm64
Para RHEL existe además un repositorio COPR dedicado a OpenVPN 2.7.
En servidores empresariales conviene mantener una política coherente: utilizar los paquetes oficiales de la distribución o un repositorio OpenVPN gestionado explícitamente, evitando mezclas improvisadas.
Actualizar desde los repositorios de la distribución
En Debian o Ubuntu:
sudo apt update
sudo apt upgradeEn Fedora o distribuciones basadas en RHEL:
sudo dnf upgradeDespués debemos volver a comprobar:
openvpn --versionSi la distribución mantiene una versión anterior con parches retroportados, conviene consultar su correspondiente aviso de seguridad.
Antes de reiniciar un servidor VPN, comprueba la configuración
OpenVPN permite validar una configuración mediante la ejecución controlada del servicio y revisión de logs.
En sistemas administrados por systemd conviene consultar primero:
systemctl status openvpn-server@servero, dependiendo de la distribución y nombre de instancia:
systemctl status openvpnDespués de actualizar:
sudo systemctl restart openvpn-server@servery verificar:
journalctl -u openvpn-server@server -n 100El nombre exacto de la unidad puede variar según la distribución y configuración.
No hagas una actualización crítica sin conocer cómo volver atrás
En un servidor VPN remoto existe un problema evidente.
Si OpenVPN es precisamente el mecanismo utilizado para administrar el servidor y la actualización falla:
administrador
|
v
actualiza VPN
|
v
VPN no inicia
|
v
pierde acceso remoto
Por eso en infraestructuras importantes conviene mantener:
- Consola alternativa.
- Acceso fuera de banda.
- Snapshot cuando corresponda.
- Backup de configuración.
- Ventana de mantenimiento.
Guarda las configuraciones y certificados
Antes de realizar cambios significativos, deberíamos conocer exactamente dónde se encuentran:
- Configuraciones del servidor.
- CA.
- Certificados.
- Claves.
- CRL.
- Scripts.
- Configuraciones de firewall.
Una copia de seguridad debe proteger especialmente las claves privadas.
No deberían almacenarse sin cifrado en repositorios públicos, sistemas de tickets ni carpetas compartidas abiertas.
CVE-2026-84790 hace especialmente importante revisar la PKI
Una VPN empresarial basada en certificados no depende solamente de que OpenVPN esté actualizado.
También requiere una infraestructura PKI bien administrada.
Conviene revisar:
- Quién puede emitir certificados.
- Qué CA son aceptadas.
- Certificados revocados.
- Nombres utilizados para identificar usuarios.
- Validez temporal.
- Protección de la clave de la CA.
La vulnerabilidad demuestra que los detalles del contenido del certificado pueden tener consecuencias de autorización y no solo criptográficas.
Una VPN no debería confiar únicamente en certificados
Dependiendo del riesgo, una organización puede combinar:
certificado del dispositivo
+
credencial del usuario
+
MFA
Esto proporciona varias capas de autenticación.
Si una de ellas presenta un problema, las demás pueden reducir el impacto.
También debemos limitar qué puede hacer un usuario después de conectarse
Autenticarse correctamente en la VPN no debería significar acceso completo a toda la red.
Una arquitectura más segura puede dividir:
VPN usuarios
|
+--> aplicaciones internas
VPN administradores
|
+--> servidores
VPN proveedores
|
+--> sistemas específicos
La segmentación sigue siendo importante incluso cuando la propia VPN está correctamente protegida.
Puede leer también | ¿Necesitas una VPN si utilizas Linux?
OpenVPN 2.7.8 frente a OpenVPN 2.7.7
| Área | OpenVPN 2.7.8 |
|---|---|
| Certificados con NUL | Ahora son rechazados |
| CVE-2026-84790 | Corregida |
| CVE-2026-88964 | Corregida |
| CVE-2026-84256 | Endurecimiento adicional |
| tls-crypt-v2 | Mejor tratamiento cuando falta material de clave |
| DCO Linux | Corrección de carreras Netlink |
| DCO peer errors | Ya no deberían finalizar todo el servidor |
| Reconexiones | Mejor gestión de iroutes |
| p2mp | Corrección de posible bloqueo de cola |
Las correcciones de estabilidad son tan importantes como los CVE
En ocasiones una actualización se evalúa únicamente contando vulnerabilidades.
Pero en infraestructura VPN existen otros riesgos operativos.
Un servidor puede ser perfectamente seguro frente a una vulnerabilidad determinada y aun así provocar una interrupción porque:
- Una carrera elimina rutas.
- Un error termina el proceso completo.
- La cola queda bloqueada.
- Kernel y userspace pierden sincronización.
OpenVPN 2.7.8 corrige precisamente varios escenarios de ese tipo.
Una sola conexión problemática no debería afectar a cientos de usuarios
Este principio explica buena parte del trabajo realizado en DCO.
En un servidor empresarial queremos:
Cliente A falla
|
v
Cliente A reconecta
y no:
Cliente A falla
|
v
OpenVPN termina
|
v
500 usuarios desconectados
La nueva gestión de errores avanza justamente hacia esa separación.
¿OpenVPN sigue siendo una buena alternativa para servidores Linux?
OpenVPN continúa siendo uno de los proyectos VPN open source con mayor trayectoria.
Su principal fortaleza está en una combinación de:
- Compatibilidad multiplataforma.
- PKI con certificados.
- Amplia documentación.
- Configuración flexible.
- TCP y UDP.
- Integración empresarial.
- Años de despliegues reales.
WireGuard ofrece un diseño mucho más reducido y moderno para numerosos escenarios, pero OpenVPN continúa siendo especialmente útil cuando se necesitan configuraciones avanzadas, compatibilidad heredada o determinados mecanismos empresariales de autenticación.
OpenVPN y WireGuard no tienen que ser enemigos
Muchas organizaciones utilizan ambos.
Por ejemplo:
WireGuard | +--> administradores +--> site-to-site sencillo OpenVPN | +--> usuarios corporativos +--> certificados +--> MFA +--> clientes heterogéneos
La elección depende de los requisitos concretos.
Lo importante es mantener cualquiera de las tecnologías correctamente actualizada y configurada.
Checklist para administradores de OpenVPN
- Comprobar la versión con openvpn --version.
- Revisar si la distribución ya incorpora las correcciones de 2.7.8.
- Actualizar servidores que utilizan OpenVPN 2.7 cuando corresponda.
- Comprobar especialmente instalaciones con DCO.
- Revisar certificados y políticas de identidad.
- Actualizar también clientes administrados.
- Comprobar logs después de reiniciar.
- Verificar reconexiones de clientes.
- Comprobar iroutes y rutas internas.
- Validar acceso DNS.
- Mantener una vía administrativa alternativa durante la actualización.
- Realizar backups de configuraciones y PKI.
- Segmentar la red accesible desde la VPN.
- Utilizar MFA cuando el riesgo lo justifique.
Recomendamos
- OpenVPN Connect Client: una herramienta de software libre para VPN
- ¿Necesitas una VPN si utilizas Linux?
- Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
- Las mejores herramientas de código abierto para proteger su servidor Linux
En resumen
OpenVPN 2.7.8 ya está disponible como una actualización centrada principalmente en seguridad y estabilidad.
La versión corrige CVE-2026-84790, que permitía situaciones de suplantación mediante caracteres NUL introducidos dentro del subject de determinados certificados.
También corrige CVE-2026-88964, un integer underflow relacionado con opciones DNS enviadas mediante PUSH_UPDATE que afecta principalmente a clientes Windows y Android.
El proyecto incorpora además un endurecimiento adicional relacionado con CVE-2026-84256 en Windows y corrige un problema de handshake con tls-crypt-v2 que no recibió identificador CVE.
Para administradores Linux, OpenVPN 2.7.8 destaca especialmente por sus mejoras en DCO: corrige carreras de Netlink, problemas de iroutes durante reconexiones, manejo de errores al crear peers o instalar claves y un posible bloqueo de cola en servidores multipunto.
Conclusión editorial
OpenVPN 2.7.8 es un buen ejemplo de una actualización que probablemente no llame demasiado la atención de un usuario doméstico, pero que puede ser muy importante para quien administra una VPN empresarial.
Las tres referencias CVE son relevantes, pero la verdadera historia de esta versión está también en las correcciones silenciosas que mantienen un servidor funcionando cuando las cosas no ocurren exactamente en el orden esperado.
DCO ha permitido que OpenVPN moderno aproveche mucho mejor el kernel Linux y pueda ofrecer un rendimiento significativamente superior al modelo histórico completamente basado en userspace.
Pero trasladar parte del canal de datos al kernel también implica mantener perfectamente sincronizados dos mundos: el estado que conoce OpenVPN y el estado que mantiene DCO.
OpenVPN 2.7.8 corrige precisamente varias situaciones donde esa coordinación podía fallar.
Una reconexión rápida ya no debería terminar eliminando la ruta de un cliente recién conectado.
Un peer que desaparece del kernel en el momento equivocado no debería derribar todo el servidor.
Y las operaciones Netlink síncronas y las notificaciones asíncronas ahora disponen de canales separados para reducir carreras.
Estas son mejoras poco visibles, pero exactamente el tipo de cambios que importan cuando una VPN conecta oficinas, administradores, trabajadores remotos o infraestructura crítica.
Si mantiene servidores OpenVPN 2.7 en Linux, especialmente con DCO habilitado, 2.7.8 es una actualización que merece ser revisada y desplegada siguiendo los procedimientos habituales de prueba, respaldo y verificación.
Fuentes: OpenVPN Community — Release History, OpenVPN — Release 2.7.8, OpenVPN — CVE-2026-84790, OpenVPN — CVE-2026-88964 y OpenVPN — repositorios para Linux.
