CVE-2024-35195Medium· 5.6▾ SunlitRequests `Session` object does not verify requests after making first request with verify=False
▾ Sunlit zone — Low / medium · no exploitation signal
impact 30.8 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 8.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
0.3%
Last analysed / modified upstream
When using a requests.Session, if the first request to a given origin is made with verify=False, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if verify=True is explicitly specified later.
This occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity.
This behavior affects versions of requests prior to 2.32.0.
requests < 2.32.0Upgrade to a patched release:
requests 2.32.0Connected by shared product, vendor, weakness, or advisory.
CVE-2023-32681Medium· 6.1Unintended leak of Proxy-Authorization header in requests
CVE-2026-25645Medium· 4.4Requests has Insecure Temp File Reuse in its extract_zipped_paths() utility function
CVE-2024-47081Medium· 5.3Requests vulnerable to .netrc credentials leak via malicious URLs