Last updated 6 July 2026

Stack-based buffer overflow in socat 1.3.0.0 through 1.7.2.2 and 2.0.0-b1 through 2.0.0-b6 allows local users to cause a denial of service (segmentation fault) via a long server name in the PROXY-CONNECT address in the command line.

The OpenSSL address implementation in Socat 1.7.3.0 and 2.0.0-b8 does not use a prime number for the DH, which makes it easier for remote attackers to obtain the shared secret.

socat 1.2.0.0 before 1.7.2.2 and 2.0.0-b1 before 2.0.0-b6, when used for a listen type address and the fork option is enabled, allows remote attackers to cause a denial of service (file descriptor consumption) via multiple request that are refused based on the (1) sourceport, (2) lowport, (3) range, or (4) tcpwrap restrictions.

Socat upstream, released an advisory: [1] http://www.dest-unreach.org/socat/contrib/socat-secadv2.html

describing a stack overflow flaw, present in Socat bidirectional data relay, when processing command line arguments (address specifications, host names, file names), longer than 512 bytes. An attacker, able to inject data into sockat's command line (potentially remotely via CGI script invocation), could use this flaw to execute arbitrary code with the privileges of the socat process.

References: [2] http://bugs.gentoo.org/showbug.cgi?id=330785

Upstream patch against v1.7.2: [3] http://www.dest-unreach.org/socat/download/socat-1.7.1.3.patch

Credit: Issue discovered and reported by Felix Gröbert of Google Security Team

CVE Request: [4] http://www.openwall.com/lists/oss-security/2010/08/02/3

Heap-based buffer overflow in the xioscanreadline function in xio-readline.c in socat 1.4.0.0 through 1.7.2.0 and 2.0.0-b1 through 2.0.0-b4 allows local users to execute arbitrary code via the READLINE address.

Gerhard Rieger reports:

Socat security advisory 6 - Possible DoS with fork

Overview socats signal handler implementations are not async-signal-safe and can cause crash or freeze of socat processes

Vulnerability Id: (pending)

Severity: Low

Details Socats signal handler implementations are not asnyc-signal-safe. When a signal is triggered while the process is within a non async-signal-safe function the signal handler will call a non sync-signal-safe function too. POSIX specifies the behaviour in this situation as undefined. Dependend on involved functions, libraries, and operating system, the process can continue, freeze, or crash. Mostly this issue occurs when socat is in listening mode with fork option and a couple of child processes terminate at the same time.

Testcase none

Affected versions 1.0.0.0 - 1.7.2.4 2.0.0-b1 - 2.0.0-b7

Not affected or corrected versions 1.7.3.0 and later 2.0.0-b8 (to be released) and later

Workaround none

Download The updated sources can be downloaded from:

http://www.dest-unreach.org/socat/download/socat-1.7.3.0.tar.gz

Credits Credits to Peter Lobsinger