Possible fix(deps): 3 vulnerable dependencies in uv.lock

[begininvoke]

Spotted what might be an issue in exploitation/agent0/uv.lock around line 1.

HIGH severity vulnerability in a locked dependency: exploitation/agent0/uv.lock pins urllib3==2.5.0, which is affected by CVE-2025-66418 (vulnerable range: >=1.24, <2.6.0). The flaw: urllib3 does not bound the number of links in the Content-Encoding decompression chain. A malicious or compromised HTTP server can respond with an arbitrarily long chain of Content-Encoding layers (e.g., gzip -> deflate -> brotli -> ...), causing urllib3 to perform a virtually unlimited number of decompression passes. Impact: denial of service via CPU exhaustion (decompression amplification) and massive memory allocation for the fully decompressed payload — a classic decompression-bomb attack. Risk is elevated in this context because the dependency belongs to an agent framework ('agent0') that likely performs automated HTTP requests to external/untrusted endpoints, which is exactly the attacker-controlled scenario this CVE exploits. No code execution or data exfiltration is involved; the risk is availability/DoS, rated HIGH. Remediation: upgrade to urllib3 2.6.0, which caps the decompression chain. Since uv.lock pins exact versions and integrity hashes, do not hand-edit the lock file — regenerate it with uv, and optionally add a version floor in pyproject.toml to prevent regression.

Something like this might fix it:

Recommended: regenerate the lock file (uv rewrites the full [[package]] block with correct 2.6.0 URLs and sha256 hashes):

```bash
cd exploitation/agent0
uv lock --upgrade-package urllib3
uv sync
# verify: uv pip show urllib3  ->  Version: 2.6.0
# then rebuild container images / re-run the scanner to confirm the CVE is cleared
```

Resulting diff in exploitation/agent0/uv.lock (hashes are placeholders; regeneration fills them in):

```diff
--- a/exploitation/agent0/uv.lock
+++ b/exploitation/agent0/uv.lock
@@
 [[package]]
 name = "urllib3"
-version = "2.5.0"
+version = "2.6.0"
 source = { registry = "https://pypi.org/simple" }
-sdist = { url = "https://files.pythonhosted.org/packages/.../urllib3-2.5.0.tar.gz", hash = "sha256:<old-hash>" }
+sdist = { url = "https://files.pythonhosted.org/packages/.../urllib3-2.6.0.tar.gz", hash = "sha256:<new-hash>" }
 wheels = [
-    { url = "https://files.pythonhosted.org/packages/.../urllib3-2.5.0-py3-none-any.whl", hash = "sha256:<old-hash>" },
+    { url = "https://files.pythonhosted.org/packages/.../urllib3-2.6.0-py3-none-any.whl", hash = "sha256:<new-hash>" },
 ]
```

Optional hardening in exploitation/agent0/pyproject.toml to pin the floor and prevent regression in future lock updates:

```diff
--- a/exploitation/agent0/pyproject.toml
+++ b/exploitation/agent0/pyproject.toml
@@
 [project]
 dependencies = [
+    # CVE-2025-66418: unbounded decompression chain fixed in 2.6.0
+    "urllib3>=2.6.0",
     # ... existing dependencies
 ]
```

Note: if urllib3 is only a transitive dependency, the `uv lock --upgrade-package urllib3` command alone is sufficient; adding the pyproject.toml floor is optional defense-in-depth.

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.