CVE-2026-24902: TrustTunnel SSRF Vulnerability

CVE-2026-24902 Overview

TrustTunnel, an open-source VPN protocol, contains a Server-Side Request Forgery (SSRF) vulnerability combined with a private network restriction bypass in versions prior to 0.9.114. The vulnerability exists in the tcp_forwarder.rs module where SSRF protection configured via allow_private_network_connections = false was only enforced for hostname-based destinations. Attackers can bypass this security control by supplying numeric IP addresses directly, allowing unauthorized access to loopback interfaces and private network resources.

Critical Impact

Authenticated attackers can bypass private network restrictions to reach internal services, loopback addresses, and private network targets through the VPN tunnel, potentially exposing sensitive internal infrastructure.

Affected Products

• TrustTunnel versions prior to 0.9.114

Discovery Timeline

• January 29, 2026 - CVE-2026-24902 published to NVD
• January 29, 2026 - Last updated in NVD database

Technical Details for CVE-2026-24902

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The flaw stems from inconsistent security control enforcement across two code paths that handle TCP connection destinations. While the TcpDestination::HostName(peer) path properly validates connections against the allow_private_network_connections setting using functions like is_global_ip and is_loopback, the TcpDestination::Address(peer) path bypassed these checks entirely and proceeded directly to TcpStream::connect().

An authenticated attacker exploiting this vulnerability could access internal services that should be restricted, including localhost-bound administrative interfaces, internal APIs, cloud metadata services, and other private network resources. The network-based attack vector with low complexity makes this vulnerability particularly concerning for organizations relying on TrustTunnel's network isolation features.

Root Cause

The root cause is an incomplete implementation of the private network connection restriction. The security check for allow_private_network_connections was only applied when the destination was specified as a hostname (TcpDestination::HostName), but not when specified as a direct IP address (TcpDestination::Address). This created a control bypass where supplying a numeric IP address (e.g., 127.0.0.1 or 192.168.1.1) instead of a hostname would skip the validation logic entirely.

Attack Vector

The attack vector is network-based and requires low-privileged authenticated access. An attacker with valid credentials to the TrustTunnel VPN can craft TCP forwarding requests using numeric IP addresses targeting private network ranges (RFC 1918) or loopback addresses. This bypasses the intended allow_private_network_connections = false security configuration, enabling the attacker to reach internal services that should be inaccessible through the VPN tunnel.

         meta: forwarder::TcpConnectionMeta,
     ) -> Result<(Box<dyn pipe::Source>, Box<dyn pipe::Sink>), tunnel::ConnectionError> {
         let peer = match meta.destination {
-            TcpDestination::Address(peer) => peer,
+            TcpDestination::Address(peer) => {
+                let peer_ip = peer.ip();
+                if !self.context.settings.allow_private_network_connections
+                    && !net_utils::is_global_ip(&peer_ip)
+                {
+                    if peer_ip.is_loopback() {
+                        return Err(tunnel::ConnectionError::DnsLoopback);
+                    }
+                    return Err(tunnel::ConnectionError::DnsNonroutable);
+                }
+
+                peer
+            }
             TcpDestination::HostName(peer) => {
                 log_id!(trace, id, "Resolving peer: {:?}", peer);

Source: GitHub Commit Update

The patch adds proper IP validation to the TcpDestination::Address code path, ensuring that both hostname and direct IP address destinations are subject to the same private network connection restrictions. The fix checks if the destination IP is non-global when allow_private_network_connections is disabled, returning appropriate errors for loopback (DnsLoopback) or other non-routable addresses (DnsNonroutable).

Detection Methods for CVE-2026-24902

Indicators of Compromise

• TCP forwarding requests targeting private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or loopback addresses (127.0.0.0/8)
• Unusual connection patterns from VPN clients to internal services not typically accessed via VPN
• Connection attempts to cloud metadata endpoints (169.254.169.254) through the VPN tunnel
• Increased TCP forwarding activity from specific authenticated users targeting internal infrastructure

Detection Strategies

• Monitor VPN server logs for TCP forwarding requests containing numeric IP addresses in private or loopback ranges
• Implement network-level detection for SSRF patterns, specifically connections from VPN infrastructure to sensitive internal services
• Audit connection logs for attempts to reach administrative interfaces or metadata services through the VPN tunnel
• Deploy anomaly detection for authenticated users making unusual internal network access requests

Monitoring Recommendations

• Enable verbose logging in TrustTunnel to capture all TCP destination requests including the destination type (hostname vs address)
• Configure alerts for any connection attempts to RFC 1918 addresses or loopback when allow_private_network_connections should be disabled
• Review access patterns for authenticated VPN users accessing internal resources
• Monitor for connections to sensitive endpoints such as localhost management interfaces or cloud metadata services

How to Mitigate CVE-2026-24902

Immediate Actions Required

• Upgrade TrustTunnel to version 0.9.114 or later immediately
• Audit VPN server logs for any suspicious TCP forwarding activity to private network addresses
• Review network segmentation to limit potential impact if exploitation has occurred
• Temporarily disable TCP forwarding functionality if upgrade is not immediately possible and the feature is not critical

Patch Information

The vulnerability is fixed in TrustTunnel version 0.9.114. The security patch adds proper IP validation to the TcpDestination::Address code path in lib/src/tcp_forwarder.rs, ensuring that both hostname and direct IP address destinations are validated against the allow_private_network_connections configuration setting. Organizations should upgrade to version 0.9.114 or later as soon as possible. Additional details are available in the GitHub Security Advisory.

Workarounds

• Implement network-level firewall rules to block VPN server egress to private network ranges if internal access is not required
• Deploy additional network segmentation between VPN infrastructure and sensitive internal services
• Use external monitoring to detect and alert on anomalous internal connection patterns from VPN endpoints
• Consider temporarily restricting TCP forwarding capabilities until the patch can be applied

# Configuration example
# Example network-level mitigation using iptables
# Block VPN server from connecting to private networks
iptables -A OUTPUT -s <vpn_server_ip> -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -s <vpn_server_ip> -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -s <vpn_server_ip> -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -s <vpn_server_ip> -d 127.0.0.0/8 -j DROP