---
id: CVE-2026-70367
title: >-
  Stunnel: ssrf bypass in stunnel socks proxy via ipv4-mapped ipv6 loopback and
  unspecified addresses allows access to loopback-only services
summary: >-
  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.…
severity: medium
cvss: 5.4
cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N'
cvssSource: cna
cwe:
  - CWE-918
vendor: Mobi-Com Polska Sp. z o.o.
product: stunnel
affected:
  - stunnel >= 5.25 < 5.80
  - stunnel (all versions)
  - stunnel
  - stunnel
  - stunnel (all versions)
  - stunnel (all versions)
ssvc:
  exploitation: poc
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-08-04T14:50:26.922087Z'
exploitAvailable: true
published: '2026-08-04'
updated: '2026-11-05'
sourceUpdated: '2026-11-05T22:51:54.689Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-70367'
references:
  - url: 'https://access.redhat.com/security/cve/CVE-2026-70367'
  - url: 'https://bugzilla.redhat.com/show_bug.cgi?id=2462083'
    label: RHBZ#2462083
tags:
  - cve.org
  - exploit-available
epss: 0.00224
epssPercentile: 0.13104
ingestedAt: '2026-11-05T23:41:31.939Z'
---

## Overview

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.

## Affected

- `stunnel >= 5.25 < 5.80`
- `stunnel (all versions)`
- `stunnel`
- `stunnel`
- `stunnel (all versions)`
- `stunnel (all versions)`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

### Workarounds

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.