CVE-2026-70367: stunnel SSRF Bypass Vulnerability

CVE-2026-70367 Overview

CVE-2026-70367 is a Server-Side Request Forgery (SSRF) vulnerability affecting stunnel version 5.79 and earlier when configured in SOCKS proxy mode. The flaw allows an authenticated client to bypass localhost access restrictions by supplying IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1 or unspecified addresses like 0.0.0.0 and ::. These alternate address representations resolve to loopback interfaces on the stunnel host, granting network-based clients access to services intended to be reachable only from local processes. The vulnerability is classified under CWE-918: Server-Side Request Forgery.

Critical Impact
Remote clients can reach loopback-only services on the stunnel host, exposing internal APIs, admin interfaces, and metadata endpoints that were assumed unreachable.

Affected Products

stunnel 5.79 and earlier versions configured in SOCKS proxy mode
Linux distributions packaging vulnerable stunnel releases (see Red Hat advisory)
Any deployment relying on stunnel SOCKS mode to enforce loopback-only egress restrictions

Discovery Timeline

2026-08-04 - CVE-2026-70367 published to NVD
2026-08-06 - Last updated in NVD database

Technical Details for CVE-2026-70367

Vulnerability Analysis

The stunnel daemon in SOCKS proxy mode enforces destination filters that are intended to block clients from proxying connections to the loopback interface. The filter logic inspects the requested destination address and rejects literal loopback values such as 127.0.0.1 and ::1. However, the address-parsing routine does not normalize alternate representations of loopback and unspecified addresses before evaluating the ACL. As a result, an authenticated SOCKS client that submits ::ffff:127.0.0.1 reaches the loopback interface because the kernel treats IPv4-mapped IPv6 addresses as equivalent to their IPv4 form during socket connect operations.

The same bypass applies to the unspecified addresses 0.0.0.0 and ::, which the operating system routes to a local interface. Attackers can enumerate administrative services, internal HTTP APIs, database sockets bound to 127.0.0.1, and cloud instance metadata endpoints. The vulnerability requires SOCKS authentication (PR:L) and delivers limited confidentiality and integrity impact per the published CVSS vector.

Root Cause

The root cause is incomplete address canonicalization before ACL evaluation. stunnel compares the requested destination against string or narrow binary forms of loopback and unspecified addresses without collapsing IPv4-mapped IPv6 forms or treating 0.0.0.0 and :: as local-equivalent. The mismatch between filter semantics and kernel routing behavior creates the SSRF bypass.

Attack Vector

An attacker who can authenticate to the stunnel SOCKS proxy submits a CONNECT request specifying an IPv4-mapped IPv6 destination such as ::ffff:127.0.0.1 on a chosen port. The stunnel filter accepts the address as non-loopback, opens a TCP socket, and the kernel routes the connection to the local loopback interface. The client then interacts directly with the loopback-bound service through the proxied tunnel. Additional bypass strings include 0.0.0.0 and ::, which similarly reach local interfaces.

No verified proof-of-concept code has been published. Refer to the Red Hat CVE-2026-70367 Advisory and the Red Hat Bug #2462083 Report for vendor technical detail.

Detection Methods for CVE-2026-70367

Indicators of Compromise

SOCKS CONNECT requests in stunnel logs containing IPv4-mapped IPv6 destinations such as ::ffff:127.0.0.1 or ::ffff:0:0.
Proxy sessions targeting 0.0.0.0 or :: as the destination address.
Unexpected inbound traffic to loopback-bound services (admin ports, metadata endpoints on 169.254.169.254) originating from the local stunnel process.

Detection Strategies

Enable verbose logging (debug = 7) in stunnel.conf and alert on any destination address containing ::ffff: prefixes or unspecified address literals.
Correlate stunnel process network activity with connections to 127.0.0.0/8 or link-local metadata endpoints that should not receive proxied traffic.
Deploy host-based rules that flag SOCKS proxy destinations resolving to loopback after kernel-level normalization.

Monitoring Recommendations

Ingest stunnel access and error logs into a centralized SIEM and build detections for the address patterns listed above.
Monitor authentication anomalies on SOCKS credentials; the bypass requires a valid client identity.
Track outbound connections from the stunnel host to internal management interfaces and alert on new patterns.

How to Mitigate CVE-2026-70367

Immediate Actions Required

Upgrade stunnel to a version later than 5.79 that includes the address normalization fix once distributed by your vendor.
Audit all stunnel.conf files for SOCKS proxy configurations and inventory who holds valid client credentials.
Rotate SOCKS proxy credentials if logs show any of the bypass address patterns.

Patch Information

Consult the Red Hat CVE-2026-70367 Advisory for distribution-specific package updates. Upstream stunnel releases beyond 5.79 address the missing canonicalization by normalizing IPv4-mapped IPv6 and unspecified addresses before ACL evaluation. Apply vendor packages through your standard patch management process and restart the stunnel service to load the fixed binary.

Workarounds

Disable SOCKS proxy mode in stunnel.conf if it is not required, removing protocol = socks from affected service definitions.
Bind sensitive services to non-loopback interfaces protected by firewall rules rather than relying on 127.0.0.1 binding.
Restrict client access to the stunnel SOCKS listener with host-level firewall rules and require strong client certificates.
Apply egress filtering on the stunnel host to block outbound connections from the stunnel process to loopback and link-local ranges.

bash

# Example: remove SOCKS mode and enforce host firewall restrictions
# /etc/stunnel/stunnel.conf
[secure-tunnel]
client = no
accept = 0.0.0.0:8443
connect = backend.internal:443
# protocol = socks   # disable SOCKS mode until patched

# Block stunnel process from reaching loopback via iptables owner match
iptables -A OUTPUT -m owner --uid-owner stunnel -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner stunnel -d 169.254.169.254 -j REJECT