CVE-2024-35195: Requests Library Cert Bypass Vulnerability

CVE-2024-35195 Overview

CVE-2024-35195 is a Certificate Validation Bypass vulnerability in the Python Requests HTTP library, a widely-used package for making HTTP requests. Prior to version 2.32.0, when making requests through a Requests Session, if the first request is made with verify=False to disable certificate verification, all subsequent requests to the same host will continue to ignore certificate verification regardless of changes to the value of verify. This behavior persists for the lifecycle of the connection in the connection pool.

Critical Impact

Applications that initially disable SSL/TLS certificate verification for specific requests may inadvertently maintain insecure connections for all subsequent requests to the same host, exposing sensitive communications to potential man-in-the-middle attacks.

Affected Products

• Python Requests library versions prior to 2.32.0
• Applications and services using affected Requests versions with Session objects
• Fedora packages containing vulnerable Requests versions

Discovery Timeline

• May 20, 2024 - CVE-2024-35195 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2024-35195

Vulnerability Analysis

This vulnerability stems from improper state management within the Requests library's connection pooling mechanism. When a Session object is used to make HTTP requests, connections are pooled and reused for performance optimization. The flaw occurs because the TLS/SSL verification settings from the first request to a host become "sticky" for subsequent connections to that same host within the connection pool.

The issue is classified under CWE-670 (Always-Incorrect Control Flow Implementation), indicating that the control flow logic for handling the verify parameter was incorrectly implemented. When a developer explicitly sets verify=False for a single request (perhaps for a known internal endpoint), then changes verify=True for subsequent requests to the same host, the library incorrectly continues to skip certificate verification.

This creates a dangerous security gap where developers believe they have re-enabled certificate verification, but the underlying connection continues operating without proper TLS certificate validation.

Root Cause

The root cause lies in how the Requests library's connection adapter manages TLS verification state within pooled connections. The verify parameter's effect was being cached at the connection pool level rather than being applied per-request. Once a connection was established with verify=False, that setting persisted for the connection's lifecycle in the pool, overriding any subsequent per-request verify=True settings.

Attack Vector

An attacker positioned to perform a man-in-the-middle attack could exploit this vulnerability when:

1. A target application uses the Requests Session object for HTTP communications
2. The application initially makes a request with verify=False (perhaps for development/testing, internal APIs, or specific trusted endpoints)
3. Subsequent requests to the same host are made with the expectation of certificate verification
4. The attacker intercepts these "supposedly secure" subsequent requests, which lack actual certificate validation

The local attack vector combined with high privilege requirements indicates exploitation requires significant access to influence the application's request flow or network positioning.

# Vulnerable code pattern - subsequent requests remain unverified
import requests

session = requests.Session()

# First request disables verification
session.get('https://example.com/api', verify=False)

# Developer expects this to be verified, but it remains unverified
# due to connection pool state retention
session.get('https://example.com/secure-api', verify=True)  # Still unverified!

The security patch addressed this by ensuring the verify parameter is properly evaluated for each request rather than being cached at the connection pool level.

 
 import os.path
 import socket  # noqa: F401
+import typing
 
 from urllib3.exceptions import ClosedPoolError, ConnectTimeoutError
 from urllib3.exceptions import HTTPError as _HTTPError

Source: GitHub Commit

Detection Methods for CVE-2024-35195

Indicators of Compromise

• Applications using Requests library versions below 2.32.0 with Session objects
• Code patterns showing verify=False followed by subsequent requests to the same host
• Unexpected certificate validation failures or successes in application logs
• Network traffic showing unencrypted or improperly validated TLS connections

Detection Strategies

• Audit Python dependencies using pip list or pip freeze to identify Requests library versions below 2.32.0
• Perform static code analysis to identify usage patterns combining Session objects with verify=False parameters
• Review application logs for TLS/SSL certificate validation anomalies
• Use software composition analysis (SCA) tools to flag vulnerable dependency versions

Monitoring Recommendations

• Implement continuous dependency scanning in CI/CD pipelines to detect vulnerable library versions
• Monitor network traffic for unexpected certificate validation bypasses
• Enable verbose logging for TLS handshakes in critical applications
• Set up alerts for applications making requests without proper certificate chain validation

How to Mitigate CVE-2024-35195

Immediate Actions Required

• Upgrade the Python Requests library to version 2.32.0 or later immediately
• Audit all applications using Session objects with mixed verify parameter usage
• Review code for patterns that disable certificate verification, even temporarily
• Consider creating new Session objects when verification requirements change rather than reusing existing sessions

Patch Information

The vulnerability has been fixed in Requests version 2.32.0. The fix ensures that the verify parameter is properly evaluated per-request rather than being cached at the connection pool level. Organizations should update using:

pip install --upgrade requests>=2.32.0

For detailed information about the fix, refer to the GitHub Security Advisory and the associated pull request.

Fedora users should check the Fedora Package Announcements for updated packages.

Workarounds

• Avoid using verify=False in Session objects entirely; instead, create separate Session instances when certificate verification must be disabled
• If disabling verification is necessary, create a new Session object immediately after for subsequent verified requests
• Use separate connection pools for trusted and untrusted endpoints
• Implement application-level certificate validation as an additional security layer

# Configuration example - Check and upgrade Requests library
pip show requests | grep Version
pip install --upgrade 'requests>=2.32.0'

# Verify the upgrade
python -c "import requests; print(requests.__version__)"