CVE-2026-70367

Vendor solution

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 statement

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.

Red Hat mitigation

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.