<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 05 Oct 2026 10:51:08 +0000</lastBuildDate>
    <item>
      <title>BREW-scrapy-CVE-2024-3574 — Authorization Header Leak During Cross-Domain Redirect in scrapy/scrapy</title>
      <link>https://cve.radiocsirt.org/vuln/brew-scrapy-cve-2024-3574</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: scrapy&lt;/p&gt;
&lt;p&gt;In scrapy version 2.10.1, an issue was identified where the Authorization header, containing credentials for server authentication, is leaked to a third-party site during a cross-domain redirect. This vulnerability arises from the failure to remove the Authorization header when redirecting across domains. The exposure of the Authorization header to unauthorized actors could potentially allow for account hijacking.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: scrapy&lt;/p&gt;
&lt;p&gt;In scrapy version 2.10.1, an issue was identified where the Authorization header, containing credentials for server authentication, is leaked to a third-party site during a cross-domain redirect. This vulnerability arises from the failure to remove the Authorization header when redirecting across domains. The exposure of the Authorization header to unauthorized actors could potentially allow for account hijacking.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-scrapy-cve-2024-3574</guid>
    </item>
    <item>
      <title>CVE-2024-3574 — Authorization Header Leak During Cross-Domain Redirect in scrapy/scrapy</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2024-3574</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; scrapy/scrapy, scrapy&lt;/p&gt;
&lt;p&gt;In scrapy version 2.10.1, an issue was identified where the Authorization header, containing credentials for server authentication, is leaked to a third-party site during a cross-domain redirect. This vulnerability arises from the failure to remove the Authorization header when redirecting across domains. The exposure of the Authorization header to unauthorized actors could potentially allow for account hijacking.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; scrapy/scrapy, scrapy&lt;/p&gt;
&lt;p&gt;In scrapy version 2.10.1, an issue was identified where the Authorization header, containing credentials for server authentication, is leaked to a third-party site during a cross-domain redirect. This vulnerability arises from the failure to remove the Authorization header when redirecting across domains. The exposure of the Authorization header to unauthorized actors could potentially allow for account hijacking.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2024-3574</guid>
    </item>
    <item>
      <title>GHSA-cw9j-q3vf-hrrv — Scrapy authorization header leakage on cross-domain redirect</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-cw9j-q3vf-hrrv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: scrapy&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Scrapy’s built-in redirect middleware creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.&lt;/p&gt;
&lt;p&gt;The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Upgrade to Scrapy 2.11.1.&lt;/p&gt;
&lt;p&gt;If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.11.1 is not an option, you may upgrade to Scrapy 1.8.4 instead.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade, make sure that you are not using the `Authentication` header, either directly or through some third-party plugin.&lt;/p&gt;
&lt;p&gt;If you need to use that header in some requests, add `&amp;#34;dont_redirect&amp;#34;: True` to the `request.meta` dictionary of those requests to disable following redirects for them.&lt;/p&gt;
&lt;p&gt;If you need to keep (same domain) redirect support on those requests, make sure you trust the target website not to redirect your requests to a different domain.&lt;/p&gt;
&lt;p&gt;### Acknowledgements&lt;/p&gt;
&lt;p&gt;This security issue was reported by @ranjit-git  [through huntr.com](https://huntr.com/bounties/49974321-2718-43e3-a152-62b16eed72a9/).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: scrapy&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Scrapy’s built-in redirect middleware creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.&lt;/p&gt;
&lt;p&gt;The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Upgrade to Scrapy 2.11.1.&lt;/p&gt;
&lt;p&gt;If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.11.1 is not an option, you may upgrade to Scrapy 1.8.4 instead.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade, make sure that you are not using the `Authentication` header, either directly or through some third-party plugin.&lt;/p&gt;
&lt;p&gt;If you need to use that header in some requests, add `&amp;#34;dont_redirect&amp;#34;: True` to the `request.meta` dictionary of those requests to disable following redirects for them.&lt;/p&gt;
&lt;p&gt;If you need to keep (same domain) redirect support on those requests, make sure you trust the target website not to redirect your requests to a different domain.&lt;/p&gt;
&lt;p&gt;### Acknowledgements&lt;/p&gt;
&lt;p&gt;This security issue was reported by @ranjit-git  [through huntr.com](https://huntr.com/bounties/49974321-2718-43e3-a152-62b16eed72a9/).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-cw9j-q3vf-hrrv</guid>
    </item>
  </channel>
</rss>
