CVE-2024-3219: Python socket Module Race Condition Flaw

CVE-2024-3219 Overview

CVE-2024-3219 is a race condition vulnerability in Python's socket module that affects the pure-Python fallback implementation of socket.socketpair() on platforms lacking AF_UNIX support, primarily Windows. The vulnerability allows a malicious local peer to exploit a connection race condition during socket pair creation, potentially enabling unauthorized access to socket communications.

The socket.socketpair() function provides a pure-Python fallback for platforms that don't support AF_UNIX sockets. This fallback uses AF_INET or AF_INET6 to create a local connected pair of sockets. However, the connection between the two sockets was not verified before being returned to the user, leaving the server socket vulnerable to connection hijacking from a malicious local process.

Critical Impact

Local attackers on Windows systems can exploit a connection race condition to intercept or inject data into socket pairs created by Python applications, potentially compromising inter-process communications.

Affected Products

• CPython 3.5 and later versions on Windows
• CPython 3.5 and later versions on other platforms without AF_UNIX support
• Python applications using socket.socketpair() on affected platforms

Discovery Timeline

• July 29, 2024 - CVE-2024-3219 published to NVD
• May 2, 2025 - Last updated in NVD database

Technical Details for CVE-2024-3219

Vulnerability Analysis

This vulnerability falls under CWE-306 (Missing Authentication for Critical Function). The root cause is the lack of connection verification in the socket.socketpair() fallback implementation. When socket.socketpair() is called on Windows, the pure-Python fallback creates a listening socket, accepts a connection, and returns the socket pair without validating that the connection actually came from the intended client socket.

The vulnerable window exists between when the client socket initiates a connection and when the server accepts it. During this brief period, a malicious local process could race to connect to the listening socket first, effectively hijacking the socket pair. This is particularly concerning for applications that rely on socket.socketpair() for secure inter-process communication, as the assumption of a trusted connection is violated.

Platforms that support AF_UNIX such as Linux and macOS are not affected by this vulnerability because they use native AF_UNIX sockets for socketpair(). Additionally, versions prior to CPython 3.5 are not affected because the vulnerable API was not included in those versions.

Root Cause

The vulnerability stems from missing authentication in the socket.socketpair() fallback implementation. The original code did not verify that the accepted connection on the server socket actually originated from the corresponding client socket created in the same function call. This created a Time-of-Check Time-of-Use (TOCTOU) race condition where an attacker could substitute their own connection.

Attack Vector

The attack requires local access to the target system. An attacker must be able to:

1. Monitor for socket.socketpair() calls on the local system
2. Predict or discover the ephemeral port used by the listening socket
3. Race to establish a connection before the legitimate client socket connects

The fix implements proper socket authentication by verifying that the peer addresses match between the socket pair:

# Authenticating avoids using a connection from something else
# able to connect to {host}:{port} instead of us.
# We expect only AF_INET and AF_INET6 families.
try:
    if (
        ssock.getsockname() != csock.getpeername()
        or csock.getsockname() != ssock.getpeername()
    ):
        raise ConnectionError("Unexpected peer connection")
except:
    # getsockname() and getpeername() can fail
    # if either socket isn't connected.
    ssock.close()
    csock.close()
    raise

Source: GitHub CPython Commit #06fa244

Detection Methods for CVE-2024-3219

Indicators of Compromise

• Unexpected connections to ephemeral ports used by Python applications on Windows
• Anomalous local network activity during Python application startup or socket pair creation
• Failed socket operations with "Unexpected peer connection" errors after patching

Detection Strategies

• Monitor Python applications for usage of socket.socketpair() on Windows systems
• Implement network monitoring for unusual local loopback traffic patterns
• Review application logs for socket-related errors or connection anomalies
• Use SentinelOne's behavioral detection to identify suspicious local network activity

Monitoring Recommendations

• Enable enhanced logging for Python applications using socket communications on Windows
• Monitor for multiple rapid connection attempts to local ephemeral ports
• Audit Python version inventories across Windows systems to identify unpatched installations
• Implement process monitoring to detect unusual inter-process communication patterns

How to Mitigate CVE-2024-3219

Immediate Actions Required

• Update Python to the latest patched version for your major release (3.9.x, 3.10.x, 3.11.x, 3.12.x, or 3.13.x)
• Audit applications using socket.socketpair() on Windows for potential exposure
• Consider implementing additional application-level authentication for socket communications
• Review and update Python installations across all Windows environments

Patch Information

The Python Security Team has released patches across multiple supported branches. The fix adds connection authentication by verifying that ssock.getsockname() matches csock.getpeername() and vice versa before returning the socket pair.

Patches are available in the following commits:

• Python 3.9: Commit 06fa244
• Python 3.10: Commit 0b65c8b
• Python 3.12: Commit 220e31a

For complete details, refer to the Python Security Announcement and GitHub Issue #122133.

Workarounds

• Where possible, use AF_UNIX sockets directly instead of relying on socket.socketpair() fallback
• Implement application-level authentication for socket pair communications as an additional layer
• Consider using alternative IPC mechanisms on Windows that don't rely on TCP sockets
• Restrict local user access on Windows systems running sensitive Python applications

# Check Python version for vulnerability assessment
python --version

# Update Python using pyenv (if applicable)
pyenv install 3.12.5
pyenv global 3.12.5

# Or update using system package manager on Windows
# Download latest installer from python.org