The OpenVPN project has released version 2.7.6, a security and maintenance update addressing two vulnerabilities in the Windows service and mbedTLS-based builds, along with several fixes for DCO, TLS handshakes, packet sizing, and VLAN traffic.
The first vulnerability, tracked as CVE-2026-63649, affects openvpnserv, the OpenVPN service used on Windows. The problem was caused by insufficient validation of the command line passed from the service’s control socket to the main OpenVPN process.
Under certain circumstances, this could allow users to bypass administrator-defined restrictions on which directories may contain OpenVPN configuration files. However, the developers clarify that the issue did not allow users to read files without the necessary operating system permissions.
The second security issue, CVE-2026-63650, concerns the --x509-username-field option when OpenVPN is built with mbedTLS. In highly specific certificate authority configurations capable of creating matching certificates, the flaw could result in OpenVPN accepting a certificate that should have been rejected.
The OpenVPN developers classify this as a low-priority security issue because exploiting it requires an unusual combination of certificate and CA settings. Still, the behavior was serious enough to receive a CVE identifier and has now been fixed in OpenVPN 2.7.6.
Another security-related change improves how OpenVPN handles key-state synchronization when using Data Channel Offload, or DCO.
Beyond the security fixes, the release introduces several user-visible changes. OpenVPN now assumes --dev tun when the --dev option is omitted, so configurations using a standard TUN interface no longer need to specify it explicitly.
Values supplied through the --ping and --keepalive settings are now limited to 24 hours. According to the developers, this restriction avoids adding complexity to the DCO kernel implementation when handling extremely large values without overflowing 32-bit integers.
Moreover, the TCP_NODELAY socket flag is now enabled unconditionally, thus disabling Nagle’s algorithm for TCP connections, allowing small packets to be sent immediately instead of being grouped together.
OpenVPN 2.7.6 also fixes several lower-level networking problems. Servers now reject incoming HARD RESET packets with a sequence identifier other than zero. Such packets represent invalid client behavior and could previously interfere with establishing TLS handshakes in point-to-point TLS configurations.
A packet-size calculation error affecting the epoch packet format has also been fixed. When both sides of a connection used OpenVPN 2.7 or newer, the calculated packet identifier size was four bytes too small.
Lastly, the release corrects the minimum packet-length validation for IEEE 802.1Q-tagged VLAN packets. With --client-nat enabled, OpenVPN could access up to four bytes beyond the reported end of a packet.
For additional details, see the changelog.
