https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 15:38:18 +0000 https://cve.radiocsirt.org/vuln/brew-scrapy-cve-2024-1968 <p><strong>Affected:</strong> Homebrew: scrapy</p> <p>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.</p> <p><strong>Affected:</strong> Homebrew: scrapy</p> <p>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.</p> https://cve.radiocsirt.org/vuln/brew-scrapy-cve-2024-1968 https://cve.radiocsirt.org/vuln/euvd-2026-1781 EUVD-2026-1781 https://cve.radiocsirt.org/vuln/euvd-2026-1781 https://cve.radiocsirt.org/vuln/fkie_cve-2024-1968 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-1968 https://cve.radiocsirt.org/vuln/ghsa-4qqq-9vqf-3h3f <p><strong>Affected:</strong> PyPI: Scrapy</p> <p>### Impact</p> <p>Since version 2.11.1, Scrapy drops the `Authorization` header when a request is redirected to a different domain. However, it keeps the header if the domain remains the same but the scheme (http/https) or the port change, all scenarios where the header should also be dropped.</p> <p>In the context of a man-in-the-middle attack, this could be used to get access to the value of that `Authorization` header</p> <p>### Patches</p> <p>Upgrade to Scrapy 2.11.2.</p> <p>### Workarounds</p> <p>There is no easy workaround for unpatched versions of Scrapy. You can replace the built-in redirect middlewares with custom ones patched for this issue, but you have to patch them yourself, manually.</p> <p>### References</p> <p>This security issue was reported and fixed by @szarny at https://huntr.com/bounties/27f6a021-a891-446a-ada5-0226d619dd1a/.</p> <p><strong>Affected:</strong> PyPI: Scrapy</p> <p>### Impact</p> <p>Since version 2.11.1, Scrapy drops the `Authorization` header when a request is redirected to a different domain. However, it keeps the header if the domain remains the same but the scheme (http/https) or the port change, all scenarios where the header should also be dropped.</p> <p>In the context of a man-in-the-middle attack, this could be used to get access to the value of that `Authorization` header</p> <p>### Patches</p> <p>Upgrade to Scrapy 2.11.2.</p> <p>### Workarounds</p> <p>There is no easy workaround for unpatched versions of Scrapy. You can replace the built-in redirect middlewares with custom ones patched for this issue, but you have to patch them yourself, manually.</p> <p>### References</p> <p>This security issue was reported and fixed by @szarny at https://huntr.com/bounties/27f6a021-a891-446a-ada5-0226d619dd1a/.</p> https://cve.radiocsirt.org/vuln/ghsa-4qqq-9vqf-3h3f https://cve.radiocsirt.org/vuln/gsd-2024-1968 gsd-2024-1968 https://cve.radiocsirt.org/vuln/gsd-2024-1968 https://cve.radiocsirt.org/vuln/opensuse-su-2024:14130-1 <p>python-Scrapy-doc-2.11.2-1.1 on GA media</p> <p>python-Scrapy-doc-2.11.2-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:14130-1 https://cve.radiocsirt.org/vuln/pysec-2024-258 <p><strong>Affected:</strong> PyPI: scrapy</p> <p>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.</p> <p><strong>Affected:</strong> PyPI: scrapy</p> <p>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.</p> https://cve.radiocsirt.org/vuln/pysec-2024-258 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-1968 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: python-scrapy, Ubuntu:Pro:18.04:LTS: python-scrapy, Ubuntu:Pro:20.04:LTS: python-scrapy, Ubuntu:Pro:22.04:LTS: python-scrapy, Ubuntu:Pro:24.04:LTS: python-scrapy</p> <p>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.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: python-scrapy, Ubuntu:Pro:18.04:LTS: python-scrapy, Ubuntu:Pro:20.04:LTS: python-scrapy, Ubuntu:Pro:22.04:LTS: python-scrapy, Ubuntu:Pro:24.04:LTS: python-scrapy</p> <p>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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-1968