osbytes

Search

Find posts, projects, and members.

← back to blog

OpenVPN 2.7.5 fixes seven CVEs; most need timed packets on the control channel

2026-07-02by@osbytes7 min read
#security #cve #vpn #openvpn #open-source #tls #linux #windows

TL;DR

  • OpenVPN 2.7.5 published today with seven CVEs and a pile of non-CVE fixes in the same tarball.
  • CVE-2026-12996 and CVE-2026-13117 are use-after-frees in the control channel: the first in ack_write_buf() needs a well-timed mix of control and authentication packets; the second in tls_wrap_reneg() needs a suitable sequence of dynamic tls-crypt packets.
  • CVE-2026-12932 and CVE-2026-13698 are tls-crypt-v2 memory leaks that can drive the server out of memory and crash it.
  • CVE-2026-13379 corrupts Windows DNS SearchList state on connect/disconnect when --dns config and local DNS settings interact badly.
  • CVE-2026-13122 crashes a server running --auth-gen-token external-auth on a malformed auth-token. CVE-2026-11771 is a one-byte overrun in NTLMv2 proxy responses.

Why this release is more than a version bump

OpenVPN patch releases often land a mix of crashers and memory bugs. 2.7.5 is heavier than usual: seven tracked CVEs, several found by overlapping researchers (章鱼哥, Haiyang Huang, Trace37 Labs, Valton Tahiri, Max Fillinger, Tristan Madani). What stands out is the shape: half the CVEs are not "parse this buffer wrong once." They are state-machine races on the VPN control channel or resource leaks in tls-crypt-v2 that only show up under sustained or sequenced traffic.

If you run an OpenVPN server, especially with tls-crypt or tls-crypt-v2, or you push DNS options to clients, this is a read-the-changelog upgrade, not a defer-to-next-maintenance-window one.

The timing bugs

CVE-2026-12996 (ack_write_buf()): an attacker who can send OpenVPN control traffic to your server can trigger a use-after-free with a carefully timed sequence of control-channel and authentication packets. That is a different threat model from a single malformed packet at connect time; it implies an active session or repeated handshake attempts where packet ordering matters.

CVE-2026-13117 (tls_wrap_reneg()): same family, but the trigger is a sequence of dynamic tls-crypt control-channel packets during renegotiation. If you enabled tls-crypt on the data channel, this is the CVE to map against your exposure: internet-facing UDP listeners with tls-crypt reneg in play.

OpenVPN's own release notes do not spell out remote pre-auth vs post-auth preconditions for every CVE. Treat both as reachable from the network until your deployment's topology proves otherwise (management interfaces firewalled, clients-only mode, etc.).

tls-crypt-v2: leaks that become crashes

CVE-2026-12932 and CVE-2026-13698 are separate memory leaks in tls-crypt-v2 handling. The symptom in both cases is the same operational failure mode: memory grows until the process hits OOM and the server crashes. Valton Tahiri reported one path; Max Fillinger reported another that OpenVPN believes overlaps with the same fix.

For operators, the lesson is boring and useful: a leak on a long-lived VPN daemon is a availability incident waiting for enough client churn. You do not need a clever exploit chain if the process dies on its own.

DNS: two different failure modes in one release

CVE-2026-13379 is Windows-specific. On connect or disconnect, certain combinations of --dns entries plus the machine's existing DNS configuration can pollute the DNS SearchList that openvpnserv maintains, breaking VPN DNS resolution or leaving the host in a bad state after teardown.

Separately, bugfix #1060 (not classified as a CVE) is a double free / use-after-free when a server config uses --dns or --dhcp-option DNS options locally (applied to the server process itself, not pushed to clients). That can crash the server on client connect. If you run split-DNS or server-side resolver options in the same file you push client routes from, read that issue before assuming only Windows clients are affected.

Smaller CVEs and what OpenVPN chose not to call security

CVE-2026-13122: malformed auth-token while --auth-gen-token external-auth is active → server crash.

CVE-2026-11771: one-byte buffer overrun in NTLMv2 proxy response handling.

The release also documents bugs OpenVPN explicitly declined to rate as security:

  • A plugin trusted-directory prefix bypass on Windows (exploitation needs admin or social engineering).
  • A server pushing tun-mtu below TUN_MTU_MIN that makes the client ASSERT (maintainers note the server already can break clients in other ways).
  • Multi-socket tls-crypt-v2 RESET replies going to the wrong client IP or out the wrong socket (fixed synchronously in mudp).

That split is worth skimming: it tells you where OpenVPN draws the "attacker on the wire" line versus "server operator misconfiguration" or "client must trust the server anyway."

What to do

  1. Upgrade servers and clients to 2.7.5 (or your distro's packaged equivalent). The GitHub release links tarball, changelog, and Windows MSI paths.
  2. Inventory tls-crypt / tls-crypt-v2 on internet-facing listeners; prioritize those instances first.
  3. Search server configs for --auth-gen-token external-auth, local --dns / --dhcp-option DNS blocks, and Windows --dns server ... stanzas that might interact with local resolver state.
  4. Watch memory on busy servers until the upgrade lands; tls-crypt-v2 leak CVEs present as slow OOM, not a single failed handshake.

Community packages and ports (FreeBSD, Linux distros) were already picking up 2.7.5 within hours of the tag; verify the build you install is actually the new version, not a rebuild of 2.7.4 with a stale CVE list.

Sources