cmd.exe. And the new Windows installers carry a separate, security-fixed kernel driver that the headline CVE count leaves out.Here's what changed, which builds are affected, and what to check before you roll it out.
The three CVEs
Linuxiac's report counts three security vulnerabilities, along with DCO, certificate-validation and server-reliability fixes. The official release notes match that. Here's each one in turn.
CVE-2026-84790: NULL bytes in certificate subjects
The release notes say OpenVPN will now check for NULL-Bytes in certificate subjects - refuse all such certificates now as "invalid". As Linuxiac puts it, this makes validation stricter on OpenSSL-based builds. mbedTLS already rejected such certificates.
Why does a NULL byte inside a certificate field matter? Here's some general background from industry practice, not from OpenVPN's notes. Many C programs treat a NULL byte as "end of string." A certificate name with one in the middle can look like one name to one piece of code and a different name to another. Identity checks are exactly where you don't want that kind of disagreement.
The project lists this under user-visible changes. It warns that the stricter check may break existing installations that use such certificates on OpenSSL builds. A normal PKI should never issue a certificate like that, but old or home-grown CAs sometimes do odd things. The bug was reported by Vivek Parikh.
CVE-2026-88964: underflow in domain_search_list
The fix description is short: options: fix unsigned underflow when clearing domain_search_list (CVE-2026-88964). Cole Munz reported the bug and contributed the fix.
OpenVPN's own advisory fills in the rest:
- Platforms: Windows and Android.
- Who can trigger it: a remote, authenticated server. That means the VPN server a client connects to, not an anonymous attacker on the internet.
- Impact: denial of service or memory disclosure through crafted domain-search options.
- Affected versions: 2.7_alpha3 through 2.7.7. Fixed in 2.7.8.
The advisory's title ties the bug to a malicious PUSH_UPDATE from the server. The threat model is a hostile or compromised server attacking its clients. That matters for anyone whose users connect to third-party or less-trusted VPN endpoints.
CVE-2026-84256: cmd.exe and quoted arguments on Windows
The 2.7.8 notes list win32: stop cmd.exe from expanding variables in quoted arguments (CVE-2026-84256). OpenVPN's advisory describes the underlying problem more broadly. OpenVPN 2.x on Windows didn't correctly quote command lines passed to CreateProcess() when they contained characters that are special to cmd.exe. Combined with a validation script and a rogue CA, that could make OpenVPN misbehave.
The version history is the confusing part. The advisory lists affected versions as 2.1_rc10 through 2.6.22 and 2.7_alpha1 through 2.7.6, and says the issue is fixed in 2.7.7. That advisory credits Clouditera Security. The 2.7.8 entry credits a different reporter, Darren Carreras, which suggests 2.7.8 extends the earlier quoting fix to handle variable expansion. If you already installed 2.7.7, you weren't exposed to the originally documented bug. 2.7.8 still closes the remaining gap.
Summary: One CVE tightens certificate checks. One protects Windows and Android clients from hostile servers. One finishes a hardening job on Windows command-line quoting.
A fourth fix, deliberately without a CVE
The release also fixes the tls-crypt-v2 handshake. OpenVPN will no longer try to add a wrapped client key when no key material is available. The project calls this a client bug that shows up in response to a misbehaving server. It explained why no CVE was assigned: "a malicious server can stop the client from working properly" is not considered a CVE-worthy security issue according to the CRA guidelines.
That's worth noting beyond OpenVPN. The EU Cyber Resilience Act is starting to shape how open-source projects decide what gets a CVE. Linux Compatible's coverage counts four security fixes in this release, with three of them carrying CVE identifiers, and that's a fair way to describe it.
The Windows installer also patches the driver
This part is easy to miss if you only read the CVE headlines. The 2.7.8 Windows MSI installers update included dco-win driver to v2.8.13. That driver update fixes CVE-2026-105390. According to the release page, a locking flaw let a local user with access to the driver's device cause a system deadlock and denial of service, hanging the host until it was power-cycled.
OpenVPN's advisory lists ovpn-dco-win versions 0.6.5 through 1.3.3 and 2.4.0 through 2.8.7 as affected. The fixes are in 1.3.4 and 2.8.13. This is separate from the three CVEs in the OpenVPN 2.7.8 code itself. It ships in the Windows installer package, not in the source release.
The MSI also updates bundled components:
| Component | Version in 2.7.8-I001 MSI |
|---|---|
| ovpn-dco-win driver | 2.8.13 |
| OpenSSL | 3.6.5 |
| Easy-RSA | 3.2.7 |
The release page also mentions performance improvements by moving to multi-core data processing in the driver update.
If you're still on the 2.6 branch, the same download page has news for you too. The project originally planned no Windows installer for 2.6.23. It later released one (2.6.23-I002) on October 7 so it could include the dco-win 1.3.4 security update.
DCO and server reliability fixes
Linux Compatible says the release targets the multi-client server path and the kernel-accelerated Data Channel Offload setup known as DCO. The main fixes:
- Stale iroutes: DCO now removes installed iroutes when a client exits, instead of waiting for delayed cleanup. Under the old timing, a reconnecting client could race the cleanup and leave the system with no iroutes installed at all. OpenVPN Inc.'s Access Server team reported it.
- Linux Netlink races: DCO on Linux now uses a second netlink socket and strictly separating sync/async operations.
- Peer and key setup failures: On both Linux and Windows DCO, failing to set up a new peer or install its keys no longer kills OpenVPN with a fatal error. The error is passed back up and only the affected (multi) instance restarts. The release notes explain that the handshake is inherently racy when the kernel removes a peer that user space still thinks is alive. Losing that one client is acceptable. Losing the whole server isn't.
- Disconnect statistics: DCO no longer queries peer stats during client disconnect. By that point the kernel peer is already gone, so the query only produced errors, and it was polling every peer to get them. Correct end-of-session counters are planned for a later patch using data carried in the kernel's
DEL_PEERnotification. - Pushed cipher configurations: Clients now refuse incoming pushed option combination of epoch data format with non-AEAD ciphers (restart session instead of aborting with a fatal error).
- Point-to-multipoint queue: Better handling of mbuf lists during broadcast and multicast traffic, plus a fix for a client-exit bug that could deadlock the server queue in very specific scenarios.
- Duplicate certificate fields: When a certificate has, say, multiple CNs, OpenSSL builds used the last one and mbedTLS builds used the first. mbedTLS now matches OpenSSL. This is separate from the NULL-byte rejection.
Linux Compatible describes the scale as about 22 commits across 40 files from 11 contributors, and it isn't a feature release.
Summary: A large share of these fixes makes sure one misbehaving client can't take down every other user's tunnel.
What to do
- Find out what you're running. List Windows endpoints and servers on 2.7.x below 2.7.8. Also look for any 2.6.x Windows installs that still have an older dco-win driver.
- Get the right installer. The 2.7.8 MSIs are
OpenVPN-2.7.8-I001-amd64.msi,-arm64.msiand-x86.msi, plus theopenvpn-2.7.8.tar.gzsource archive. Each one has a GnuPG signature, so verify it before pushing the installer through Intune, SCCM or any other tool. - Test certificates first. Before a wide rollout on OpenSSL builds, run a pilot group against your production CA. If clients that used to connect now fail certificate validation, check their subject fields for embedded NULL bytes. The project expects that failure mode.
- Prioritize by exposure. Multi-client servers using DCO get the most from the stability fixes. Windows and Android clients that connect to servers you don't fully control get the most from the CVE-2026-88964 fix. Any shared Windows machine where local users could reach the driver device should get the new dco-win driver.
- Check third-party bundles. Products that embed OpenVPN update on their own schedule. Tunnelblick, for example, notes in its release notes that a recent beta includes OpenVPN 2.7.7, replacing 2.7.6, so packaged clients may lag behind the community release.
The bigger picture
This is a busy period for OpenVPN security fixes. Linuxiac's previous OpenVPN story covered 2.7.7 with seven security fixes, about a month before this release. OpenVPN 2.6.23, released September 23, fixed a separate batch of Windows issues, including NULL-DACL handling, a DHCP buffer off-by-one, and tapctl calling netsh.exe without a full path.
That can look alarming, but a steady flow of advisories with named reporters and published version ranges usually means a project is being actively audited and is responding quickly. Admins still have to install the updates, and here that means paying attention to the version numbers. The 2.7.8 application release and the 2.8.13 Windows driver inside its MSI are separate fixes, and Windows machines need both.
References
- OpenVPN 2.7.8 Released with Certificate and Windows Security Fixes - Linuxiac Linuxiac · 2026-10-07T14:33:39+00:00
- CVE-2026-88964 – community wiki community.openvpn.net
- OpenVPN 2.7.8 Released: Security Hardening for Certificates, TLS, and Kernel Data Channel linuxcompatible.org