https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 14 Oct 2026 19:22:27 +0000 https://cve.radiocsirt.org/vuln/brew-scrapy-ghsa-23j4-mw76-5v7h <p><strong>Affected:</strong> Homebrew: scrapy</p> <p>### Impact</p> <p>Scrapy was following redirects regardless of the URL protocol, so redirects were working for `data://`, `file://`, `ftp://`, `s3://`, and any other scheme defined in the `DOWNLOAD_HANDLERS` setting.</p> <p>However, HTTP redirects should only work between URLs that use the `http://` or `https://` schemes.</p> <p>A malicious actor, given write access to the start requests (e.g. ability to define `start_urls`) of a spider and read access to the spider output, could exploit this vulnerability to: - Redirect to any local file using the `file://` scheme to read its contents. - Redirect to an `ftp://` URL of a malicious FTP server to obtain the FTP username and password configured in the spider or project. - Redirect to any `s3://` URL to read its content using the S3 credentials configured in the spider or project.</p> <p>For `file://` and `s3://`, how the spider implements its parsing of input data into an output item determines what data would be vulnerable. A spider that always outputs the entire contents of a response would be completely vulnerable, while a spider that extracted only fragments from the response could significantly limit vulnerable data.</p> <p>### Patches</p> <p>Upgrade to Scrapy 2.11.2.</p> <p>### Workarounds</p> <p>Replace the built-in retry middlewares (`RedirectMiddleware` and `MetaRefreshMiddleware`) with custom ones that implement the fix from Scrapy 2.11.2, and verify that they work as intended.</p> <p>### References</p> <p>This security issue was reported by @mvsantos at https://github.com/scr…</p> <p><strong>Affected:</strong> Homebrew: scrapy</p> <p>### Impact</p> <p>Scrapy was following redirects regardless of the URL protocol, so redirects were working for `data://`, `file://`, `ftp://`, `s3://`, and any other scheme defined in the `DOWNLOAD_HANDLERS` setting.</p> <p>However, HTTP redirects should only work between URLs that use the `http://` or `https://` schemes.</p> <p>A malicious actor, given write access to the start requests (e.g. ability to define `start_urls`) of a spider and read access to the spider output, could exploit this vulnerability to: - Redirect to any local file using the `file://` scheme to read its contents. - Redirect to an `ftp://` URL of a malicious FTP server to obtain the FTP username and password configured in the spider or project. - Redirect to any `s3://` URL to read its content using the S3 credentials configured in the spider or project.</p> <p>For `file://` and `s3://`, how the spider implements its parsing of input data into an output item determines what data would be vulnerable. A spider that always outputs the entire contents of a response would be completely vulnerable, while a spider that extracted only fragments from the response could significantly limit vulnerable data.</p> <p>### Patches</p> <p>Upgrade to Scrapy 2.11.2.</p> <p>### Workarounds</p> <p>Replace the built-in retry middlewares (`RedirectMiddleware` and `MetaRefreshMiddleware`) with custom ones that implement the fix from Scrapy 2.11.2, and verify that they work as intended.</p> <p>### References</p> <p>This security issue was reported by @mvsantos at https://github.com/scr…</p> https://cve.radiocsirt.org/vuln/brew-scrapy-ghsa-23j4-mw76-5v7h