CVE-2024-35195

What it actually does

In affected versions of the Python Requests library before 2.32.0, TLS certificate verification state can persist incorrectly within a Session connection pool. If a Session first connects to a host with verify=False, the pooled connection for that host may continue to skip certificate validation for later requests even when verify is changed back to True or a certificate bundle is supplied. The flaw weakens HTTPS trust guarantees and can allow a man-in-the-middle attacker, in the right network position, to read or modify traffic that the application developer expected to be certificate-validated.

Why it matters to the business

Applications using vulnerable Requests versions may silently send sensitive API calls, credentials, tokens, or business data over HTTPS connections that are not actually verifying the remote server identity. Because Requests is widely used across Python applications, the operational risk is mainly hidden exposure in internal services, automation, integrations, and scripts where developers temporarily disabled verification and assumed later calls were safe. The vulnerability is not listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, so prioritization should be risk-based, with higher urgency for software that handles secrets, payments, customer data, administrative APIs, or runs on untrusted networks.

How an attack unfolds

An attacker cannot generally exploit this flaw by sending a simple remote request to an application. The vulnerable pattern requires an application to use a persistent requests.Session, make an initial HTTPS request to a target host with verify=False, and then reuse the same Session and pooled connection for later requests to that same host while expecting certificate verification to be enabled. If an attacker can observe or intercept network traffic between the application and that host, they can present a spoofed or untrusted certificate and still have the client accept the connection because the pooled connection remains in an unverified state. The attacker can then inspect sensitive data in transit, alter responses, inject malicious payloads into API responses, or capture authentication material depending on what the application sends over the affected connection.

How to fix it

Upgrade Python Requests to version 2.32.0 or later wherever it is installed directly or bundled transitively. For source-based deployments, include the upstream fix at commit d6ebc4a2f1f68b7e355fb7e4dd5ffc0845547f9f or a later release containing it. Regenerate lockfiles and container images so the fixed package is actually deployed, not only declared. Remove avoidable uses of verify=False from application code; where custom trust is needed, configure verify with an explicit CA bundle path rather than disabling verification. Avoid reusing a Session across mixed trust modes; if verification must be disabled for a specific diagnostic or controlled endpoint, isolate it in a separate short-lived Session and close it immediately after use. Ensure urllib3, certifi, and related HTTP dependencies are kept current as part of normal dependency hygiene.

How to confirm the fix worked

Confirm the installed package version at runtime and in build artifacts using commands such as python -m pip show requests, pip freeze, poetry show requests, pipenv graph, or SBOM/dependency scanner output; the effective version should be 2.32.0 or later. Search code for requests.Session usage combined with verify=False, especially where the same Session object is reused for multiple calls to the same host. Validate container images, serverless packages, virtual environments, and vendored dependencies because Python applications often carry their own dependency copies. As a functional regression test, create a Session, make a first request to a test HTTPS endpoint with verify=False, then make a subsequent request through the same Session to the same host with verify=True while presenting an invalid certificate; fixed versions should reject the invalid certificate on the verified request.

Typical attack path

1. Identify or infer a Python application, automation job, or service that uses the Requests library before 2.32.0.
2. Find a code path where a persistent requests.Session is used and an initial request to a host is made with verify=False.
3. Position on the network path between the application and the target host, such as through compromised Wi-Fi, proxy infrastructure, DNS manipulation, routing control, or a hostile internal network segment.
4. Wait for the application to reuse the same Session connection pool for later HTTPS requests to the same host that the developer expects to be certificate-validated.
5. Present a forged, self-signed, expired, or otherwise invalid certificate while intercepting the connection.
6. Read sensitive request or response data, capture tokens or credentials, or modify responses returned to the application.

How to detect it

There are no universal network or host indicators proving exploitation because abuse appears as HTTPS traffic to legitimate destinations and depends on application behavior. Investigate whether vulnerable applications both used Requests before 2.32.0 and executed code paths containing verify=False. Review application logs, debug logs, proxy logs, TLS inspection logs, and EDR/network telemetry for failed or unusual certificate validation events, unexpected certificate issuers, self-signed certificates, hostname mismatches, expired certificates, or HTTPS connections to sensitive API hosts through unusual proxies or network paths. Search source repositories, deployed artifacts, container layers, and runtime logs for verify=False and InsecureRequestWarning messages. For suspected compromise, compare server certificate fingerprints observed by the client/proxy against known-good certificates from the destination service during the relevant time window, and review downstream API audit logs for suspicious actions, token use, or data access following affected outbound requests.

• verify=False
• requests.Session(
• Session()
• InsecureRequestWarning
• Unverified HTTPS request is being made
• CERTIFICATE_VERIFY_FAILED
• certificate verify failed
• self signed certificate
• hostname mismatch
• certificate has expired
• requests==2.31.0
• requests==2.30.0
• requests==2.29.0
• requests==2.28.0
• requests<2.32.0

What your security team should do

• Inventory all Python applications, scripts, CI/CD jobs, notebooks, serverless functions, and containers that include Requests before 2.32.0.
• Prioritize upgrades for workloads that transmit credentials, API tokens, customer data, payment data, administrative commands, or service-to-service authentication over HTTPS.
• Patch by upgrading Requests to 2.32.0 or later and rebuilding lockfiles, virtual environments, containers, and deployed artifacts.
• Perform targeted code review for requests.Session combined with verify=False and require security approval for any remaining certificate-verification bypasses.
• Add static analysis or repository rules that flag verify=False in requests calls and fail builds for new unsafe uses unless explicitly waived.
• Where immediate upgrade is not possible, avoid mixed verification states in the same Session, use separate short-lived Sessions, close Sessions after unverified calls, and restrict network paths to trusted segments.
• Monitor dependency management systems for transitive reintroduction of vulnerable Requests versions.