Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact The requests.utils.extractzippedpaths() utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Affected usages Standard usage of the Requests library is not affected by this vulnerability. Only applications that call extractzippedpaths() directly are impacted. Remediation Upgrade to at least Requests 2.33.0, where the library now extracts files to a non-deterministic location. If developers are unable to upgrade, they can set TMPDIR in their environment to a directory with restricted write access.
Recommended action: Upgrade to 2.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Workarounds For older versions of Requests, use of the .netrc file can be disabled with trustenv=False on your Requests Session (docs). References https://github.com/psf/requests/pull/6965 https://seclists.org/fulldisclosure/2025/Jun/2
Recommended action: Upgrade to 2.32.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Since Requests v2.3.0, Requests has been vulnerable to potentially leaking Proxy-Authorization headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how rebuildproxies is used to recompute and reattach the Proxy-Authorization header to requests when redirected. Note this behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. https://username:password@proxy:8080). Current vulnerable behavior(s): 1. HTTP → HTTPS: leak 2. HTTPS → HTTP: no leak 3. HTTPS → HTTPS: leak 4. HTTP → HTTP: no leak For HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the Proxy-Authorization header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to…
Recommended action: Upgrade to 2.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Requests (aka python-requests) before 2.3.0 allows remote servers to obtain a netrc password by reading the Authorization header in a redirected request.
Recommended action: Upgrade to 2.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Requests (aka python-requests) before 2.3.0 allows remote servers to obtain sensitive information by reading the Proxy-Authorization header in a redirected request.
Recommended action: Upgrade to 2.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The resolveredirects function in sessions.py in requests 2.1.0 through 2.5.3 allows remote attackers to conduct session fixation attacks via a cookie without a host value in a redirect.
Recommended action: Upgrade to 2.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Requests package through 2.19.1 before 2018-09-14 for Python sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
Recommended action: Upgrade to 2.20.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.