CVE-2026-35058: OpenVPN DoS Vulnerability via TLS-Crypt

CVE-2026-35058 Overview

CVE-2026-35058 is a denial-of-service vulnerability in OpenVPN 2 that stems from improper packet length validation during tls-crypt-v2 client key extraction. The flaw affects OpenVPN versions 2.6.0 through 2.6.19 and 2.7_alpha1 through 2.7.1. An authenticated attacker can send a specially crafted packet to trigger a fatal assertion in the OpenVPN process, terminating the service. The issue is tracked under CWE-617: Reachable Assertion and was disclosed in coordination with Cisco Talos vulnerability report TALOS-2026-2381.

Critical Impact
Authenticated attackers can crash OpenVPN servers and clients with a single malformed tls-crypt-v2 packet, disrupting VPN availability for all connected users.

Affected Products

OpenVPN 2.6.0 through 2.6.19
OpenVPN 2.7_alpha1 through 2.7.1
Deployments using the tls-crypt-v2 feature for client key wrapping

Discovery Timeline

2026-06-08 - CVE-2026-35058 published to NVD
2026-06-09 - Last updated in NVD database

Technical Details for CVE-2026-35058

Vulnerability Analysis

The vulnerability resides in OpenVPN's handling of tls-crypt-v2 client key material. The tls-crypt-v2 feature wraps a per-client key inside a control channel packet sent during the initial handshake. When the server extracts the wrapped key, it parses length fields embedded in the packet to locate the encrypted payload and metadata. The affected code path fails to fully validate that the declared length fits within the actual packet boundaries before proceeding. When the parser encounters an inconsistent length value, it reaches an ASSERT() macro instead of returning a clean error, terminating the process. Because OpenVPN aborts on assertion failure, a single malformed packet halts the daemon and disconnects every active tunnel. The flaw is reachable by any peer that has completed the lightweight tls-crypt-v2 authentication step, so it is classified as authenticated.

Root Cause

The root cause is a missing or insufficient bounds check during tls-crypt-v2 key extraction. The OpenVPN code uses defensive assertions to catch internal invariants, but attacker-controlled input reaches one of these assertions instead of being filtered by a prior length validation. This converts what should be a recoverable parse error into a fatal abort.

Attack Vector

The attacker must hold a valid tls-crypt-v2 client key, which makes the attack post-authentication. After establishing the initial encrypted control channel, the attacker transmits a crafted packet with manipulated internal length fields. The server reaches the vulnerable extraction routine, the assertion fires, and the OpenVPN process exits. In multi-client deployments the entire VPN concentrator goes down until restarted. No verified public exploit or proof-of-concept code is available at the time of disclosure.

Detection Methods for CVE-2026-35058

Indicators of Compromise

Unexpected termination of the openvpn process with assertion failure messages in system logs or syslog.
Repeated VPN client disconnects originating from the same authenticated peer immediately after handshake completion.
Log entries referencing tls-crypt-v2 parsing followed by an immediate daemon exit.

Detection Strategies

Monitor OpenVPN server logs for ASSERT messages and abnormal process exits correlated with inbound control-channel traffic.
Track restarts of the openvpn systemd unit or service wrapper, especially clusters of restarts within short time windows.
Correlate authenticated peer identifiers with crash events to identify the originating client certificate or tls-crypt-v2 key.

Monitoring Recommendations

Forward OpenVPN logs to a centralized logging or SIEM platform and alert on assertion-related strings.
Enable process supervision metrics that count daemon restarts per hour and threshold them.
Audit which clients possess valid tls-crypt-v2 keys and revoke any keys associated with anomalous crash patterns.

How to Mitigate CVE-2026-35058

Immediate Actions Required

Upgrade to OpenVPN 2.6.20 or 2.7.2, both released 22 April 2026, which contain the fix per the OpenVPN release history.
Inventory all OpenVPN deployments using tls-crypt-v2 and prioritize internet-facing concentrators.
Review the OpenVPN CVE-2026-35058 advisory for vendor-specific guidance.

Patch Information

OpenVPN addressed the issue in versions 2.6.20 and 2.7.2. Both releases correct the length validation logic in the tls-crypt-v2 key extraction path so that malformed packets are rejected without triggering an assertion. Operators running source-built or distribution-packaged binaries should confirm that their package version matches or exceeds these fixed releases.

Workarounds

Disable tls-crypt-v2 and revert to tls-crypt or tls-auth for control-channel protection until patching is possible.
Restrict which clients receive tls-crypt-v2 keys and revoke unused keys to reduce the authenticated attack surface.
Place OpenVPN behind a process supervisor that restarts the daemon on exit to limit downtime, recognizing this is not a fix.

bash

# Verify installed OpenVPN version on Linux
openvpn --version | head -n 1

# Example Debian/Ubuntu upgrade once distro packages are available
sudo apt update && sudo apt install --only-upgrade openvpn

# Temporary workaround: switch server.conf from tls-crypt-v2 to tls-crypt
# tls-crypt-v2 /etc/openvpn/server/tls-crypt-v2-server.key
tls-crypt /etc/openvpn/server/tls-crypt.key