OpenVPN 2.7.8 fixes two CVEs, but the trust assumptions behind them outlast the patch

What the 2.7.8 update fixes

OpenVPN 2.7.8 closes two vulnerabilities, CVE-2026-88964 and CVE-2026-84790, and both stem from trust assumptions rather than a single implementation slip. According to a dev.to analysis by sorrelthorncroft, the flaws expose two beliefs that a version bump does not remove: that a connecting server should be free to configure a client, and that a certificate's subject field is a dependable identity.

The affected ranges differ. CVE-2026-84790 covers OpenVPN 2.3.0 through 2.7.7 across platforms, while CVE-2026-88964 covers 2.7_alpha3 through 2.7.7 on Windows and Android. Both dev.to posts note that neither advisory documents a workaround, which leaves the fixed release as the only vendor-side remedy.

A crafted domain search option

CVE-2026-88964 is triggered when a server sends crafted domain search options to a client. OpenVPN 2.7.8 corrects the parser involved, but as sorrelthorncroft points out, the underlying design still lets a connecting server shape much of a client's configuration. The controls worth keeping afterwards are a policy limiting which servers clients will accept — especially on mobile devices and for profiles issued to contractors — and a review of any profile that points at a third-party provider.

A NUL byte that fakes an identity

CVE-2026-84790 used an embedded NUL character in a certificate's subject field to make one certificate masquerade as another identity. Version 2.7.8 closes that comparison path inside OpenVPN, but a dev.to post by andreagomez argues the enabling condition sits earlier in the chain: the moment a certificate authority signs a request whose subject contains a null byte. According to that post, the vulnerability scores 7.6 in CVSS 4.0, with high attack complexity and attack requirements present.

Validate at issuance

The enrollment-side rule andreagomez proposes covers the flaw's shape: refuse any subject attribute containing a non-printing character such as NUL, and refuse attributes whose encoded length disagrees with the decoded string. Common names matter most, since that is the attribute most tools treat as identity.

Leak points are ordinary. Self-service portals that only check whether an input field is empty will forward a null byte pasted in from elsewhere, and automation that builds subject strings from directory usernames inherits whatever the directory permits. A validation step between input and signing, applied to every attribute the policy covers, costs far less than learning of the problem after a server has accepted the certificate.

Existing estates need a sweep as well: inventory the certificate authorities, export subject attributes for inspection, and revoke and reissue any certificate containing non-printing characters. Version 2.7.8 removes the identity-confusion path in OpenVPN itself, but an attacker holding an old copy keeps it until revocation.

What the exposure numbers do and do not say

ZoomEye reports 2,181,390 assets matching app="OpenVPN", and 1,737,572 for app="OpenVPN" on port 1194. As sorrelthorncroft observes, these are fingerprint populations — useful for spotting forgotten internet-facing services, but silent about client builds and certificate configuration. A vulnerability-scoped ZoomEye query for CVE-2026-88964 returned zero results on the search date, a reminder that what an index covers is not a measurement of risk.

Checking a version string is likewise necessary but thin. A stronger close-out is a regression test that presents a crafted certificate to a server and confirms rejection, kept in the suite so that a later downgrade or a swapped binary gets caught.

Why it matters

The patch repairs OpenVPN's code, not the ecosystem around it. Authorization plugins, portals and monitoring tools built alongside the VPN read the same subject fields, and their own handling of NUL bytes is unknown; cleaning up issuance removes the input those readers could misinterpret. With the affected range for CVE-2026-84790 stretching back to 2.3.0, older installations are easy to miss for teams tracking only recent releases. Since neither advisory offers a workaround, the practical evidence of closure is a written record: endpoints at 2.7.8, issuance validation in place, subject-based authorization rules reviewed, and a test proving a malformed subject is rejected. That record, both posts argue, is what separates a handled risk from a deferred one.