The two vulnerabilities fixed in OpenVPN 2.7.8 are ordinary mistakes in unusual places. Reading them as code-review prompts helps teams check their own software for the same shapes.

Shape one: unsigned arithmetic on attacker-controlled lengths

CVE-2026-88964 began as an unsigned underflow, CWE-191. A length or an index was decremented below zero, wrapped to a huge value, and the following read used it. The companion weakness is CWE-125, an out-of-bounds read.
Review prompt: every subtraction on a length that originates from a peer message needs a guard. In C and C++, unsigned wrap is defined behaviour, so the compiler will not warn. Static analysis rules for unsigned comparisons after subtraction catch some cases, and a targeted review of parsers that handle wire-format strings catches the rest.
The disposition when the value is wrong should be a rejected message and a closed connection, not a truncated read.

Shape two: string comparison without length discipline

CVE-2026-84790 combined CWE-290, authentication bypass through spoofing, with CWE-158, improper handling of a null byte. Certificate subject fields are byte strings with length; C string functions stop at the first NUL. Any component that converts a length-prefixed value into a C string for comparison introduces the mismatch.
Review prompt: find every place where an identity value is converted between representations. If the source carries a length, both the validator and the consumer must use it. If one side uses a terminator and the other uses a length, a crafted value satisfies both differently.
The same shape appears in HTTP headers, JSON string handling through C libraries, and file path comparisons on Windows.

Where the two shapes meet

Both flaws are parser defects triggered by a peer. Both were invisible to the user and required an authenticated relationship. Neither produced a clear error that an operator would notice.
That combination is why the advisory impact language is modest and the CVSS scores are high: availability or confidentiality loss with no user interaction, from a position the attacker already holds.

Applying the review to the VPN path

For a team that builds VPN-adjacent tooling, the checklist has four entries:

  1. 1.

    Any parser that consumes a server-pushed configuration option treats every field as untrusted.

  2. 2.

    Any comparison of a certificate attribute uses a length-aware API on both sides.

  3. 3.

    Any unsigned value derived by subtraction is checked before use.

  4. 4.

    Any authorization decision keyed to a subject field is recorded with the certificate fingerprint.

The numbers, and why they do not answer the question

ZoomEye reports 2,181,390 assets matching app="OpenVPN", a fingerprint population rather than a vulnerable-host count. The fixed release is 2.7.8, and neither advisory documents a workaround.
The durable output of this incident is not the version number. It is the review prompt that finds the same two shapes elsewhere. A NUL byte and an unsigned subtraction are small things to look for, and they keep turning up.