OpenVPN 2.7.8 Ships With Hardening for Certificates, TLS Handshakes, and the In-Kernel Data Channel
OpenVPN has published version 2.7.8 of its open-source community software, shipping four security fixes across the code paths that power the project's largest deployments. Three of those carry CVE identifiers, and one is deliberately missing one on policy grounds.
The release was tagged on 6 October by maintainer Gert "cron2" Doering, landing the day before its official 7 October date. It's a small, targeted update: about 22 commits across 40 files from 11 contributors, riding on top of the substantial architectural overhaul that 2.7.0 delivered back in February.
What 2.7.8 actually does
This isn't a feature release. There's no new protocol, no flashy capability bolted onto the side. The point of 2.7.8 is to lock down and stabilize things that already exist, specifically the multi-client server path and the kernel-accelerated Data Channel Offload setup known as DCO, where the data-plane work gets pushed into a Linux kernel driver for speed.
The security section of the release notes lists four items. The first is CVE-2026-84790, a fix for NULL bytes embedded in certificate subjects. Certificates now get their subject strings checked for those zero bytes, and any cert containing one is refused as invalid.
The flaw closes an attack surface where a crafted or rogue certificate could exploit parsers that simply stop at the first NULL byte.
Reported by Vivek Parikh of BreachX and implemented by Max Fillinger, the change matters mainly for OpenSSL builds. mbedTLS builds had always rejected those NULL-byte certificates, so this mostly brings the OpenSSL path in line. If you have a cert with an embedded null sitting in some archive, it may stop working. Worth a look before you push this to production.
The second security item gets no CVE at all. In a TLS handshake using tls-crypt-v2, OpenVPN used to try and add a wrapped client key even when no key material was available. Lev Stipakov stopped it blindly trusting a peer's request to resend that key, which addresses a scenario where a misbehaving, or outright malicious, server could disrupt a client.
Why no identifier? Per the guidelines of Italy's CRA, the Computer Resilience Agency, a "malicious server can stop the client from working properly" just doesn't qualify as a CVE-worthy breach. It's counted as robustness degradation rather than a confidentiality or integrity failure. That's a policy call, not a statement that the fix is weak.
The third is CVE-2026-88964, an unsigned integer underflow in the domain search list, caught and fixed by Cole Munz. Underflows like this are the classic setup for buffer miscalculations and potential over-reads or over-writes, so it's the kind of thing you'd rather not have running in the wild.
The fourth lands on CVE-2026-84256: hardening the Windows CreateProcess command-line quoting so characters special to cmd.exe can't trigger variable expansion in quoted arguments. Lev Stipakov implemented it, and Darren Carreras reported it. There's a footnote here worth your attention. The same CVE number was first addressed in the previous release, 2.7.7, so 2.7.8 is continuing the hardening around the identical quoting path. Sometimes a single issue has multiple facets, and this one apparently did.
Oh, and while putting together 2.7.8, the maintainers noticed one security fix had quietly been missing from the 2.7.7 notes: CVE-2026-84471, a double-free catch in the "lame duck" case. They've since added it to the record.
Beyond the security list
Most of the rest of 2.7.8 points at the DCO path and a handful of protocol edge cases, which is exactly where operators running large servers will care.
One fix, for instance, removes per-client routes at actual client-exit time rather than during delayed multi-instance cleanup. The old approach raced with reconnecting clients and could, at worst, leave a system with no routes installed at all. Bug was reported by OpenVPN Inc.'s own Access Server team.
Another adds a second, dedicated netlink socket to separate synchronous work from asynchronous notifications. There was a redundant re-entrancy guard that got dropped along the way.
The change you'll probably hear people talk about is the one that stops the whole server from dying when a peer or key operation fails. Under a racy handshake, a peer may already be gone from the kernel before you try to install its key. OpenVPN used to exit with a fatal error. Now it signals the problem up the call chain and restarts just that single instance, Linux and Windows alike.
Not cheap. Restarting a whole server because one peer misbehaved was never great engineering.
Two other user-facing changes show up. Duplicate fields on a certificate, like a second Common Name, are now handled identically across OpenSSL and mbedTLS builds. And the p2mp mbuf handling under broadcast traffic got tightened up, including a client-exit deadlock fix.
The context that matters
For perspective, 2.7.8 sits on a line that's been unusually busy on the security front. Its immediate predecessor, 2.7.7 from 3 September, carried a large batch of CVE-addressed fixes, and the ones before it are littered with contributions from BreachX, Fox-IT, and Nexory. That pattern of external researchers and bug-bounty houses feeding the project is worth remembering.
The repeated involvement of those outside groups highlights how much OpenVPN leans on responsible-disclosure contributions. So does its habit of publishing detailed release notes with reporter names and private-issue numbers attached. It's a fairly transparent advisory style, and honestly, in a space where people quietly drop security patches, transparency is a feature.
The tradeoff? 2.7.8 is a maintenance release, and maintenance releases rarely excite. If you're expecting a headline change, you'll be underwhelmed. The value here is incremental but real, and it concentrates heavily on the paths that break under load, which is where a VPN either holds up or doesn't.
What you should do
If you run a multi-client server or a kernel-accelerated DCO setup, upgrade. Several 2.7.8 fixes, the instance-restart-on-peer-failure behavior, the iroute race, the netlink socket split, all of them directly affect availability when things get busy.
Certificate-tooling teams should double-check that no certs with embedded NULL bytes are still in rotation. They'll be refused on OpenSSL now, even though mbedTLS has been rejecting them all along. And if you're on Windows, the continued hardening of the cmd.exe quoting path is a genuine win.
One more thing. Because 2.7.8 builds on the 2.7.0 architectural changes, make sure your whole stack stays in step. That means the kernel driver, your client implementations, and any Access Server or management integration. A patch only helps as far as the rest of the stack lets it.
Head here to the GitHub release page.
