CVE-2024-47081

What it actually does

Requests versions prior to 2.32.4 contain a URL parsing flaw that can cause credentials sourced from a .netrc file to be attached to HTTP requests sent to an unintended third-party destination when an application follows or fetches a maliciously crafted URL. The issue affects confidentiality only: an attacker who can cause a vulnerable Python application to request a crafted URL may receive Basic Authentication credentials that Requests automatically loaded from .netrc. The flaw requires the vulnerable application to use Requests with environment trust enabled, to have relevant .netrc credentials available, and to process attacker-influenced URLs.

Why it matters to the business

Applications that fetch user-supplied or externally controlled URLs with vulnerable Requests versions may unintentionally disclose service credentials, API credentials, or automation account secrets to an attacker-controlled host. Exposed credentials can enable unauthorized access to internal or third-party services, data theft, supply-chain compromise, or follow-on lateral movement depending on what the leaked credentials can access. This is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, but Requests is widely used in Python ecosystems, so dependency inventory and remediation should still be prioritized for internet-facing services, automation, CI/CD workers, and systems that store .netrc credentials.

How an attack unfolds

An attacker first identifies an application or workflow that accepts or processes externally influenced URLs using a vulnerable Requests release. The attacker then supplies a specially crafted URL that triggers the URL parsing confusion. When the application makes the outbound HTTP request, Requests may consult the local .netrc file and attach credentials intended for a different host or context. The request is directed to a server the attacker controls or can observe, allowing the attacker to capture the Authorization header or equivalent credential material. The attacker can then attempt to reuse the leaked credentials against the service for which they were originally valid. Successful exploitation is most likely in URL-fetching services, webhook processors, build/release automation, internal scripts, and applications that run with user or service-account .netrc files.

How to fix it

Upgrade Requests to version 2.32.4 or later wherever it is used directly or transitively. For source builds from the psf/requests Git repository, ensure the code includes fixed commit 021dc729f0b71a3030cefdbec7fb57a0e80a6cfd or a later revision. Where immediate upgrade is not possible, disable .netrc/environment credential use by creating sessions with trust_env=False, for example by setting session.trust_env = False on Requests Session objects. Remove unnecessary .netrc entries from application, service, CI/CD, and developer environments. Avoid using .netrc for privileged service credentials in automated workloads; prefer scoped secret managers and explicit authentication per destination. Add allowlists or strict validation for any externally supplied URLs and block redirects or requests to unapproved schemes, hosts, and IP ranges. Rotate any credentials that may have been available in .netrc on systems that processed untrusted URLs while running vulnerable versions.

How to confirm the fix worked

Confirm installed Requests versions with package inventory tools such as pip show requests, pip freeze, poetry show requests, pipenv graph, conda list requests, SBOM scanners, container image scanners, and dependency lockfile review. Validate that all resolved direct and transitive dependencies use Requests 2.32.4 or later, or a patched Git revision at or after 021dc729f0b71a3030cefdbec7fb57a0e80a6cfd. Search code for Requests Session usage and verify trust_env=False is set where .netrc must not be consulted. Confirm application runtimes, containers, virtual environments, CI runners, and serverless packages were rebuilt after dependency updates. Test representative URL-fetching paths with controlled .netrc credentials and confirm credentials are not sent to unexpected hosts or after crafted/ambiguous URL input. Review egress controls to ensure applications that process external URLs can only contact approved destinations.

Typical attack path

1. Find or induce a vulnerable Python application, script, CI job, or service to fetch attacker-controlled URLs using Requests prior to 2.32.4.
2. Confirm the application environment uses .netrc-based authentication or inherits environment configuration through Requests' default trust_env behavior.
3. Provide a maliciously crafted URL designed to trigger the parsing issue and cause credential selection for the wrong destination.
4. Receive the outbound request on attacker-controlled infrastructure and capture authentication material such as a Basic Authorization header.
5. Replay or validate the exposed credential against the intended upstream service.
6. Use any successful access for data retrieval, persistence, privilege escalation, or movement to other connected systems.

How to detect it

There is no universal exploit signature because exploitation depends on attacker-supplied URLs and environment-specific .netrc contents. Investigate systems that ran Requests versions prior to 2.32.4 and had .netrc files while processing untrusted URLs. Review outbound proxy logs, web gateway logs, DNS logs, EDR network telemetry, application HTTP client logs, CI/CD runner logs, and server access logs for unexpected external destinations contacted by Python Requests clients. Look for requests to unfamiliar domains that include Authorization headers, especially Basic authentication, from services that normally authenticate only to known internal or vendor endpoints. Compare outbound destinations around user-submitted URL, webhook, redirect, or URL-preview events. Inspect application and proxy logs for crafted or ambiguous URLs, embedded userinfo, unusual host delimiters, percent-encoding, or redirects that precede credential-bearing requests. If a possible leak is found, treat the corresponding .netrc entries as compromised, rotate them, and review downstream service logs for subsequent successful logins or API calls from unfamiliar IP addresses or user agents.

• .netrc
• _netrc
• Authorization: Basic
• python-requests/
• requests/2.32.3
• requests/2.32.2
• requests/2.32.1
• requests/2.32.0
• trust_env = True
• trust_env=True
• session.trust_env
• NETRC
• netrc.netrc

What your security team should do

• Inventory all Python applications, containers, CI/CD jobs, automation scripts, and serverless packages that include psf/requests prior to 2.32.4.
• Prioritize remediation for systems that process untrusted URLs, follow redirects, act as webhook consumers, perform URL previewing/fetching, or run with .netrc files present.
• Upgrade to Requests 2.32.4 or later and rebuild/redeploy affected artifacts rather than only updating source manifests.
• Where upgrades are delayed, set Requests sessions to trust_env=False and remove or restrict .netrc files from service accounts and build agents.
• Rotate credentials stored in .netrc on any host or runner that used vulnerable Requests versions to fetch untrusted or externally supplied URLs.
• Add outbound proxy, DNS, or egress monitoring for unexpected destinations contacted by Python Requests clients, especially where Authorization headers are present.
• Harden URL ingestion with host allowlists, scheme restrictions, redirect controls, and protections against ambiguous, encoded, or userinfo-containing URLs.
• Document and enforce a policy discouraging .netrc-based authentication for production workloads and CI/CD systems handling untrusted input.