stunnel EUVD-2026-52687

Exploitation requires stunnel to be explicitly configured in SOCKS proxy mode - this is not the default stunnel operating mode and must be deliberately enabled via the 'protocol = socks' directive in the stunnel configuration. The CVSS PR:L metric indicates that the attacker must have low-privilege access to the stunnel SOCKS proxy endpoint (i.e., be a permitted SOCKS client, which may mean simply having network reachability to the port if the SOCKS service has no credential enforcement, or holding valid SOCKS credentials if authentication is configured). No user interaction is required and attack complexity is low once access is obtained. Exploitation is limited to stunnel version 5.79 and earlier. Impact is further bounded by what loopback services exist and are listening on the stunnel host - environments where no sensitive services bind exclusively to 127.0.0.1 face negligible practical risk despite meeting the configuration prerequisite.

The CVSS 3.1 score of 5.4 Medium with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N reflects a network-reachable, low-complexity exploit requiring low-privilege SOCKS client access, with limited confidentiality and integrity impact and no availability impact. Real-world risk depends heavily on two factors: whether stunnel is deployed in SOCKS proxy mode (a non-default, explicitly configured operating mode) and whether sensitive loopback services co-reside on the stunnel host. In environments where stunnel acts as a hardened gateway with localhost services (e.g., Redis, internal admin APIs, metadata endpoints), this vulnerability materially raises the blast radius. No CISA KEV listing and no public POC reduce urgency, suggesting no active opportunistic exploitation at this time. EPSS data was not provided; given the configuration prerequisite and PR:L requirement, exploitation probability is expected to be low-to-moderate. The absence of a S:C (scope change) in the CVSS vector is consistent - impact is bounded to the stunnel host itself.

An attacker with legitimate SOCKS client credentials connects to the exposed stunnel SOCKS proxy port and issues a CONNECT or UDP ASSOCIATE request targeting ::ffff:127.0.0.1 on a privileged port (e.g., port 6379 for Redis or port 8080 for an internal admin console). stunnel's address filter, expecting only dotted-decimal 127.0.0.1 to be blocked, forwards the connection to the loopback interface, granting the attacker access to a service intended to be reachable only from the local host. No public POC exists at time of analysis, but the technique is well-documented in dual-stack SSRF research.