CVE Tools

CVE-2023-45803

Request body not stripped after redirect in urllib3

No known exploitation. EPSS puts it in the 43rd percentile. A vendor fix is available.

Published Updated Sources: CVE.org, NVD, GitHub, BDU

What to do

The vendor has published a fix. Version details are below where the sources state them.

What it is

From the CVE record

urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.

In plain language

No plain-language summary for this CVE yet.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS43rd
CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.5% chance of exploitation activity in the next 30 days, which ranks it in the 43rd percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

6 events over 982 days, from the signal feeds we watch.

  1. OpenVAS check added
  2. Patch availablerecord updated
  3. Publishedweakness classified, att&ck mapped

Affected products

Technical detail

CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N

Scored 4.2 by NVD.

How it is reached

  • Attack Vector AdjacentRequires access to the local network (e.g. same Wi-Fi, Bluetooth)
  • Attack Complexity HighRequires specific conditions like a race condition or non-default configuration
  • Privileges Required HighRequires admin or elevated privileges
  • User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

  • Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

  • Confidentiality HighTotal information disclosure — all data in the component is compromised
  • Integrity NoneNo integrity impact
  • Availability NoneNo availability impact

Weaknesses

ATT&CK techniques

Mapped from the weaknesses above (CWE to ATT&CK), not observed in attacks.

Sources

Watch the software you run.

My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.

We'll flag the next CVE, public exploit or patch for ООО «РусБИТех-Астра», not every advisory.

We use analytics cookies to see which pages and articles actually help people. Decline and none of them run — the site works the same. What we store