Copyright © 2012 Red Hat, Inc. All rights reserved. Moderate 2026-08-04T10:29:57 stunnel: SSRF bypass in stunnel SOCKS proxy via IPv4-mapped IPv6 loopback and unspecified addresses allows access to loopback-only services 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N CWE-918

A Server-Side Request Forgery (SSRF) bypass vulnerability exists in “stunnel” 5.79 and lower when configured in SOCKS proxy mode. This flaw allows a client to bypass intended localhost restrictions by using IPv4-mapped IPv6 addresses (e.g., “::ffff:127.0.0.1”) or unspecified addresses ("0.0.0.0", "::"), enabling access to loopback-only services on the "stunnel" host that should not be network-reachable.

A Server-Side Request Forgery (SSRF) bypass vulnerability exists in “stunnel” 5.79 and lower when configured in SOCKS proxy mode. This flaw allows a client to bypass intended localhost restrictions by using IPv4-mapped IPv6 addresses (e.g., “::ffff:127.0.0.1”) or unspecified addresses ("0.0.0.0", "::"), enabling access to loopback-only services on the "stunnel" host that should not be network-reachable.

When configured with "protocol = socks", which is a non-default setting, an attacker able to reach the SOCKS server can send requests that will get proxied to localhost. This potentially exposes services bound to the local interface of the "stunnel" host. Exploitation depends on the presence and security of such local services. A SOCKS proxy is intentionally a general-purpose network access facility and should always be deployed with appropriate firewall policies and client authorization, i.e., there should be no untrusted users accessing a SOCKS proxy. This issue was discovered by Found by AISLE in partnership with Red Hat. To mitigate this issue, if SOCKS proxying functionality is not required, disable the "protocol = socks" configuration in "stunnel". If SOCKS proxying is necessary, restrict access to the SOCKS listener by binding it to a trusted management network or localhost, and enforce client authentication or network ACL controls. Run "stunnel" in a container or network namespace where no other services are bound to localhost, or add firewall rules to restrict outgoing connections from "stunnel" to localhost. Red Hat Enterprise Linux 10 Fix deferred stunnel Red Hat Enterprise Linux 6 Not affected stunnel Red Hat Enterprise Linux 7 Not affected stunnel Red Hat Enterprise Linux 8 Fix deferred stunnel Red Hat Enterprise Linux 9 Fix deferred stunnel https://www.cve.org/CVERecord?id=CVE-2026-70367 https://nvd.nist.gov/vuln/detail/CVE-2026-70367