Requests (Python) Security Guide (2026)

Requests is the library almost every Python developer reaches for to make an HTTP call. Its tagline — "HTTP for Humans" — undersells how central it is: it is a dependency of a huge portion of PyPI, sees enormous download volume through pip, and is embedded in CLIs, data pipelines, web backends, and internal automation everywhere. Because Requests is the layer that carries your credentials, tokens, and cookies out onto the network, the bugs that matter most are the ones where it sends those secrets somewhere it should not. That is exactly the shape of its CVE history.

The notable historical CVEs

Requests has a small but consistent set of real, published advisories, and they cluster around credential handling during redirects and sessions:

• CVE-2018-18074 — before 2.20.0, Requests would forward the Authorization header when a request was redirected to a different host, leaking credentials to the redirect target. Fixed in 2.20.0.
• CVE-2023-32681 — in versions 2.3.0 through 2.30.0, Requests leaked the Proxy-Authorization header to the destination server on HTTPS redirects (and when the header was configured via environment). Fixed in 2.31.0.
• CVE-2024-35195 — if a Session made its first request with verify=False, subsequent requests to the same host would continue skipping certificate verification even when verify=True was passed. Fixed in 2.32.0.
• CVE-2024-47081 — a maliciously crafted URL could cause Requests to leak .netrc credentials to a third party. Fixed in 2.32.4.

The recurring theme is credential and trust leakage: an Authorization header, a Proxy-Authorization header, .netrc credentials, or TLS verification behaving differently than the caller expected. None of these are "your code is wrong" bugs — they are cases where the library's default behavior sent a secret or dropped a check in a way most developers never anticipated.

Common misuse and risks

Beyond the CVEs, the most damaging Requests problems are usage patterns:

• verify=False. Disabling certificate verification to "make it work" turns every HTTPS call into an unauthenticated channel vulnerable to interception. It is the single most common dangerous pattern in Python HTTP code.
• No timeout. requests.get(url) with no timeout will hang indefinitely if the server stalls, which is a denial-of-service and resource-exhaustion vector in any service that calls out to third parties.
• Server-Side Request Forgery (SSRF). Passing a user-controlled URL straight into requests.get() lets an attacker probe internal metadata endpoints and services. Requests will not stop you.
• Trusting redirects blindly. With allow_redirects=True (the default), a request can be bounced to an attacker-controlled host — the exact substrate for the credential-leak CVEs above.

How to use Requests safely

Set the version floor first. Run Requests 2.32.4 or later, which carries fixes for the Authorization, Proxy-Authorization, session-verification, and .netrc leak issues above. Pin it in your lockfile and make sure transitive copies resolve to a patched version too.

Then adopt safe defaults in code:

• Always pass an explicit timeout (a connect/read tuple is best): requests.get(url, timeout=(3.05, 10)).
• Never set verify=False in production. If you use a private certificate authority, point Requests at its CA bundle with verify='/path/to/ca.pem'.
• For any URL that originates from user input, validate the scheme and host against an allowlist before calling out, and block requests to private/link-local address ranges to prevent SSRF.
• Consider allow_redirects=False for sensitive calls, or inspect the redirect chain, so a rogue redirect cannot bounce credentials to an unexpected host.
• Prefer a Session for connection reuse — but be deliberate about verify on the first call, given CVE-2024-35195.

How to monitor Requests with SCA and reachability

Requests appears in almost every Python project's dependency tree, so a version-based scanner will flag it constantly. What you want to know is narrower: are you on a patched version, and does your code path actually exercise the risky behavior — do you follow redirects with credentials attached, or pass user input into a request URL?

Safeguard's software composition analysis resolves your full Python dependency graph from requirements.txt, poetry.lock, or Pipfile.lock and adds call-path reachability, so a Requests CVE that touches code you actually run is separated from one that sits in a dev-only dependency. When a fix is available, autonomous auto-fix opens a pull request that bumps Requests to the safe version and re-runs your tests. If you are weighing this against another scanner, the Safeguard vs Snyk comparison lays out the differences, and developers run the same analysis locally with the Safeguard CLI.

Bring continuous, prioritized dependency analysis to your Python services — get started free or read the documentation.

Frequently Asked Questions

Which version of Requests is safe in 2026?

Run Requests 2.32.4 or later. That release includes the fix for the .netrc credential leak (CVE-2024-47081) and builds on 2.32.0 and 2.31.0, which fixed the session-verification bug (CVE-2024-35195) and the Proxy-Authorization leak (CVE-2023-32681) respectively. Anything older than 2.32.4 is missing at least one credential-handling fix.

Is it ever OK to use verify=False with Requests?

Only in throwaway local testing, never in production. Disabling verification removes the protection that makes HTTPS meaningful and exposes the connection to interception. If you have a private certificate authority, pass its bundle to verify instead of disabling the check.

Why does Requests leak credentials on redirects?

Historically, Requests forwarded sensitive headers like Authorization and Proxy-Authorization when following a redirect to a different host, and could expose .netrc credentials for crafted URLs. Those specific behaviors are fixed in current versions, but the durable defense is to validate redirect targets and be cautious with allow_redirects on authenticated calls.

Does Requests protect me from SSRF?

No. Requests will fetch whatever URL you give it, including internal addresses and cloud metadata endpoints. If any part of the URL comes from user input, you must validate the scheme and host and block private address ranges yourself before making the call.

How do I know if a Requests CVE is actually reachable in my code?

Use reachability-aware SCA. It traces whether your application actually invokes the affected behavior — for example following redirects with credentials attached, or passing external input into a request URL — so you can prioritize the CVEs that are genuinely exploitable in your codebase.