Authorization Header Leakage in scrapy/scrapy on Scheme Change Redirects
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 2.11.2, 2.0.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: yes
- Technical impact: partial
Summary
In scrapy/scrapy, an issue was identified where the Authorization header is not removed during redirects that only change the scheme (e.g., HTTPS to HTTP) but remain within the same domain. This behavior contravenes the Fetch standard, which mandates the removal of Authorization headers in cross-origin requests when the scheme, host, or port changes. Consequently, when a redirect downgrades from HTTPS to HTTP, the Authorization header may be inadvertently exposed in plaintext, leading to potential sensitive information disclosure to unauthorized actors. The flaw is located in the _build_redirect_request function of the redirect middleware.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: poc · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- scrapy scrapy/scrapy
fixed in 2.11.2
- scrapyPyPI
fixed in 2.0.0; From 2.0.0 · fixed in 2.11.2
- scrapyPyPI
fixed in 2.11.2