Spotted what might be an issue in requirements.txt around line 2.
HIGH — CVE-2025-66418: Unbounded decompression chain in urllib3 (Remote DoS)
requirements.txt (line 2) pins urllib3==1.26.19, which falls within the affected range (>=1.24, <2.6.0). In these versions, the length of the response decompression chain is unbounded. A malicious or compromised HTTP server can respond with a virtually unlimited number of stacked compression layers; because urllib3 decompresses responses automatically by default, it will process every layer, allowing the attacker to force extreme CPU consumption and massive memory allocation (a decompression-bomb attack).
Impact: Remote denial of service. Any application that makes HTTP requests to servers it does not fully trust (external APIs, user-supplied URLs, proxies, or a network position susceptible to MITM) can be made unresponsive or crash via CPU/memory exhaustion. No authentication or user interaction is required, and exploitation is trivially automatable — hence the HIGH risk rating.
Remediation: Upgrade to urllib3>=2.6.0, which caps the number of decompression steps. Two follow-ups:
- urllib3 2.x requires a newer Python runtime than 1.26.x — verify compatibility and run your test suite after upgrading.
- Check transitive dependencies (e.g.,
requests, botocore, docker) for version constraints that could pin urllib3 below 2.6.0.
Something like this might fix it:
```diff
--- requirements.txt
+++ requirements.txt
@@ -1,3 +1,3 @@
requests==2.31.0
-urllib3==1.26.19
+urllib3>=2.6.0,<3.0
certifi==2024.2.2
```
Alternatively, if the project pins exact versions, use `urllib3==2.6.0`. After updating, regenerate the lockfile (if present) with `pip-compile` or `pip freeze > requirements.txt`, and validate with:
```bash
pip install -r requirements.txt
pip list | grep urllib3 # must show 2.6.0 or later
```
For reference: rule CVE-2025-66418. Rated high.
If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Spotted what might be an issue in
requirements.txtaround line 2.HIGH — CVE-2025-66418: Unbounded decompression chain in urllib3 (Remote DoS)
requirements.txt(line 2) pinsurllib3==1.26.19, which falls within the affected range (>=1.24, <2.6.0). In these versions, the length of the response decompression chain is unbounded. A malicious or compromised HTTP server can respond with a virtually unlimited number of stacked compression layers; because urllib3 decompresses responses automatically by default, it will process every layer, allowing the attacker to force extreme CPU consumption and massive memory allocation (a decompression-bomb attack).Impact: Remote denial of service. Any application that makes HTTP requests to servers it does not fully trust (external APIs, user-supplied URLs, proxies, or a network position susceptible to MITM) can be made unresponsive or crash via CPU/memory exhaustion. No authentication or user interaction is required, and exploitation is trivially automatable — hence the HIGH risk rating.
Remediation: Upgrade to
urllib3>=2.6.0, which caps the number of decompression steps. Two follow-ups:requests,botocore,docker) for version constraints that could pin urllib3 below 2.6.0.Something like this might fix it:
For reference: rule
CVE-2025-66418. Rated high.If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.