| Affected_by_vulnerabilities |
| 0 |
|
| 1 |
| url |
VCID-4yce-5hbd-4kbx |
| vulnerability_id |
VCID-4yce-5hbd-4kbx |
| summary |
Cookie-setting is not restricted based on the public suffix list
Responses from domain names whose public domain name suffix contains 1 or more periods (e.g. responses from `example.co.uk`, given its public domain name suffix is `co.uk`) are able to set cookies that are included in requests to any other domain sharing the same domain name suffix. |
| references |
|
| fixed_packages |
|
| aliases |
GHSA-mfjm-vh54-3f96, GMS-2022-230
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-4yce-5hbd-4kbx |
|
| 2 |
| url |
VCID-atnw-pnvj-zkhp |
| vulnerability_id |
VCID-atnw-pnvj-zkhp |
| summary |
A Regular Expression Denial of Service (ReDoS) vulnerability exists in the XMLFeedSpider class of the scrapy/scrapy project, specifically in the parsing of XML content. By crafting malicious XML content that exploits inefficient regular expression complexity used in the parsing process, an attacker can cause a denial-of-service (DoS) condition. This vulnerability allows for the system to hang and consume significant resources, potentially rendering services that utilize Scrapy for XML processing unresponsive. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2024-1892, PYSEC-2024-162
|
| risk_score |
3.0 |
| exploitability |
0.5 |
| weighted_severity |
5.9 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-atnw-pnvj-zkhp |
|
| 3 |
|
| 4 |
| url |
VCID-meje-5upu-mqen |
| vulnerability_id |
VCID-meje-5upu-mqen |
| summary |
Scrapy 1.4 allows remote attackers to cause a denial of service (memory consumption) via large files because arbitrarily many files are read into memory, which is especially problematic if the files are then individually written in a separate thread to a slow storage resource, as demonstrated by interaction between dataReceived (in core/downloader/handlers/http11.py) and S3FilesStore. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2017-14158, GHSA-h7wm-ph43-c39p, PYSEC-2017-83
|
| risk_score |
4.0 |
| exploitability |
0.5 |
| weighted_severity |
8.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-meje-5upu-mqen |
|
| 5 |
| url |
VCID-meu9-utc1-43bf |
| vulnerability_id |
VCID-meu9-utc1-43bf |
| summary |
Scrapy before 2.6.2 and 1.8.3 vulnerable to one proxy sending credentials to another
### Impact
When the [built-in HTTP proxy downloader middleware](https://docs.scrapy.org/en/2.6/topics/downloader-middleware.html#module-scrapy.downloadermiddlewares.httpproxy) processes a request with `proxy` metadata, and that `proxy` metadata includes proxy credentials, the built-in HTTP proxy downloader middleware sets the `Proxy-Authentication` header, but only if that header is not already set.
There are third-party proxy-rotation downloader middlewares that set different `proxy` metadata every time they process a request.
Because of request retries and redirects, the same request can be processed by downloader middlewares more than once, including both the built-in HTTP proxy downloader middleware and any third-party proxy-rotation downloader middleware.
These third-party proxy-rotation downloader middlewares could change the `proxy` metadata of a request to a new value, but fail to remove the `Proxy-Authentication` header from the previous value of the `proxy` metadata, causing the credentials of one proxy to be leaked to a different proxy.
If you rotate proxies from different proxy providers, and any of those proxies requires credentials, you are affected, unless you are handling proxy rotation as described under **Workarounds** below. If you use a third-party downloader middleware for proxy rotation, the same applies to that downloader middleware, and installing a patched version of Scrapy may not be enough; patching that downloader middlware may be necessary as well.
### Patches
Upgrade to Scrapy 2.6.2.
If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.6.2 is not an option, you may upgrade to Scrapy 1.8.3 instead.
### Workarounds
If you cannot upgrade, make sure that any code that changes the value of the `proxy` request meta also removes the `Proxy-Authorization` header from the request if present.
### For more information
If you have any questions or comments about this advisory:
* [Open an issue](https://github.com/scrapy/scrapy/issues)
* [Email us](mailto:opensource@zyte.com) |
| references |
|
| fixed_packages |
|
| aliases |
GHSA-9x8m-2xpf-crp3, GMS-2022-3357
|
| risk_score |
3.1 |
| exploitability |
0.5 |
| weighted_severity |
6.2 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-meu9-utc1-43bf |
|
| 6 |
| url |
VCID-n6z2-awrh-7kbg |
| vulnerability_id |
VCID-n6z2-awrh-7kbg |
| 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. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2024-1968, PYSEC-2024-258
|
| risk_score |
null |
| exploitability |
0.5 |
| weighted_severity |
0.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-n6z2-awrh-7kbg |
|
|
|---|