OpenVPN 2.7.6 Released with Security Fixes for Windows and mbedTLS

The two CVEs target different threat surfaces. CVE-2026-63649 lives in openvpnserv on Windows, where the control socket passes a command line to the main process without sufficient validation, letting users circumvent administrator restrictions on which directories may hold configuration files. The developers are explicit that this does not grant access to files the OS would otherwise deny, so the practical impact is policy bypass, not data exfiltration. CVE-2026-63650 affects only mbedTLS builds and only under certificate authority configurations capable of producing matching certificates, making exploitation conditional on an unusual setup that the developers classify as low priority.

Several behavioral changes will affect existing configurations. OpenVPN now assumes --dev tun when --dev is omitted, so configs that relied on a different default or expected an error on omission need review. The --ping and --keepalive values are capped at 24 hours to prevent 32-bit integer overflow in the DCO kernel implementation, meaning any deployment using values beyond that ceiling will see them clamped. TCP_NODELAY is now set unconditionally, disabling Nagle's algorithm on TCP connections; this changes latency characteristics for small-packet traffic and may alter throughput behavior on lossy links.

The networking fixes address correctness rather than security per se. When both sides of a connection run OpenVPN 2.7 or newer, the epoch packet format calculation was underestimating the packet identifier size by four bytes, which could corrupt packet handling. Servers now reject HARD RESET packets with non-zero sequence identifiers, closing a vector for interfering with TLS handshake establishment in point-to-point TLS mode. With --client-nat enabled, the minimum packet-length check for IEEE 802.1Q-tagged VLAN packets was off by up to four bytes, allowing reads past the reported end of a packet.

DCO key-state synchronization has been improved, though the material does not specify the prior failure mode in detail. The combination of the 24-hour cap on keepalive values and the DCO key-state fix suggests the offload path was accumulating state or integer-overflow risk under long-lived or extreme configurations. Operators using DCO should treat this release as a required update rather than optional maintenance.

Only one feed carried this event, so there is no independent corroboration of the details. The material is drawn entirely from the Linuxiac article and its summary of the changelog. Engineers should consult the official OpenVPN changelog directly before deploying, particularly to confirm whether the behavioral changes, default --dev tun, unconditional TCP_NODELAY, and the keepalive cap, interact with existing automation or hardened configs.