CVE-2026-24904: TrustTunnel VPN Auth Bypass Vulnerability

CVE-2026-24904 Overview

CVE-2026-24904 is an authorization bypass vulnerability in TrustTunnel, an open-source VPN protocol. The vulnerability exists in versions prior to 0.9.115 and allows attackers to bypass security rules by exploiting improper handling of fragmented TLS ClientHello messages. When the client_random field cannot be extracted due to parsing failures, rules dependent on client_random_prefix matching are silently skipped, allowing unauthorized connections to pass through the rules engine.

Critical Impact

Attackers can bypass VPN access control rules by sending fragmented or malformed TLS handshakes, potentially gaining unauthorized access to protected network resources.

Affected Products

• TrustTunnel versions prior to 0.9.115

Discovery Timeline

• 2026-01-29 - CVE CVE-2026-24904 published to NVD
• 2026-01-29 - Last updated in NVD database

Technical Details for CVE-2026-24904

Vulnerability Analysis

This vulnerability stems from an improper access control issue (CWE-284) in TrustTunnel's TLS listener and rules engine components. The flaw resides in how the VPN protocol handles TLS ClientHello parsing and subsequent rule evaluation.

In the tls_listener.rs file, the TlsListener::listen() function peeks at 1024 bytes from incoming connections and calls extract_client_random(...) to parse TLS handshake data. When a client sends a fragmented or partial ClientHello that is split across multiple TCP writes, the parse_tls_plaintext function fails, causing extract_client_random to return None.

The critical issue manifests in the rules.rs file where RulesEngine::evaluate only evaluates client_random_prefix conditions when client_random is Some(...). When extraction fails and client_random equals None, any rule relying on client_random_prefix matching is completely skipped, and evaluation falls through to subsequent rules.

An important semantic consideration is that client_random_prefix functions as a match condition only—it does not inherently mean "block non-matching prefixes." A rule with client_random_prefix = ... triggers its action only when the prefix matches and the field is available for evaluation. Non-matches or None values simply do not match that rule and continue falling through the rule chain.

Root Cause

The root cause is the absence of a fail-safe mechanism in the rules evaluation logic. When the client_random field cannot be extracted from a TLS handshake, the rules engine silently bypasses rules that depend on this field rather than denying the connection or requiring successful extraction. This design flaw allows attackers to craft network traffic that intentionally causes extraction failures, effectively bypassing security controls.

Attack Vector

An attacker can exploit this vulnerability over the network without authentication by deliberately fragmenting TLS ClientHello messages across multiple TCP segments. By ensuring the initial 1024-byte peek window does not contain a complete, parseable ClientHello, the attacker forces extract_client_random to return None. This causes any access control rules dependent on client_random_prefix matching to be bypassed, potentially allowing unauthorized access to VPN-protected resources.

    /// Evaluate connection against all rules
    /// Returns the action from the first matching rule, or Allow if no rules match
    pub fn evaluate(&self, client_ip: &IpAddr, client_random: Option<&[u8]>) -> RuleEvaluation {
+        if client_random.is_none()
+            && self
+                .rules
+                .rule
+                .iter()
+                .any(|r| r.client_random_prefix.is_some())
+        {
+            return RuleEvaluation::Deny;
+        }
+
        for rule in &self.rules.rule {
            if rule.matches(client_ip, client_random) {
                return match rule.action {

Source: GitHub TrustTunnel Commit

Detection Methods for CVE-2026-24904

Indicators of Compromise

• Unusual TLS handshake patterns with abnormally small or fragmented ClientHello messages
• Repeated connection attempts from the same source with varying TCP segmentation patterns
• Log entries showing successful connections that bypassed expected client_random_prefix rules
• Connections where client_random extraction consistently fails from specific sources

Detection Strategies

• Monitor TLS handshake logs for connections where client_random extraction returns None
• Implement network-level detection for deliberately fragmented TLS ClientHello packets
• Audit VPN access logs for connections that should have been denied by client_random_prefix rules
• Deploy packet inspection to identify TCP streams with unusual segmentation during TLS handshakes

Monitoring Recommendations

• Enable verbose logging in TrustTunnel to capture TLS parsing failures and rule evaluation details
• Configure alerts for elevated rates of client_random extraction failures
• Review connection logs correlating source IPs with rule bypass events
• Monitor for reconnaissance activity probing VPN endpoints with malformed TLS traffic

How to Mitigate CVE-2026-24904

Immediate Actions Required

• Upgrade TrustTunnel to version 0.9.115 or later immediately
• Review VPN access logs for potential exploitation attempts prior to patching
• Audit existing rules that rely on client_random_prefix matching for potential bypass exposure
• Consider implementing additional network-layer access controls as defense-in-depth

Patch Information

The vulnerability is fixed in TrustTunnel version 0.9.115. The patch modifies the RulesEngine::evaluate function to explicitly deny connections when client_random is None and any rule in the configuration relies on client_random_prefix matching. This ensures that parsing failures result in a secure-by-default denial rather than a rule bypass.

For detailed patch information, refer to the GitHub TrustTunnel Commit and the GitHub Security Advisory GHSA-fqh7-r5gf-3r87.

Workarounds

• Remove or replace rules that depend solely on client_random_prefix matching until the patch can be applied
• Implement IP-based allowlisting as an additional layer of access control
• Deploy network segmentation to limit exposure of TrustTunnel endpoints to trusted networks
• Use a reverse proxy or firewall to normalize TLS traffic before it reaches TrustTunnel

# Upgrade TrustTunnel to patched version
cargo update -p trusttunnel
# Or rebuild from the fixed commit
git fetch origin
git checkout aa5060145506952b9431b0ed3edb52bb6c08d9a6
cargo build --release