Possible fix(deps): urllib3 2.6.3 → 2.7.0 (CVE-2026-44432) in uv.lock

[begininvoke]

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

Vulnerability: CVE-2026-44432 (HIGH severity, fix available). The lock file exploitation/n8n_RCE_via_file_write/uv.lock pins urllib3 2.6.3, which falls in the affected range (2.6.0 to <2.7.0). In these versions, urllib3 decompresses an entire HTTP response body instead of only the requested portion when (1) the response is Brotli-compressed and HTTPResponse.read(amt=N) is called a second time, or (2) HTTPResponse.drain_conn() is invoked after a partially read/decompressed response. A malicious or compromised HTTP server can weaponize this as a decompression bomb: a small, highly compressed payload that expands massively on the client, causing high CPU usage and huge memory allocation in a single operation. Impact: client-side denial of service for any code path issuing HTTP requests to untrusted or attacker-influenced endpoints (directly relevant here, as the n8n exploitation tooling communicates with remote targets). The trigger is purely server-controlled response data — no credentials or privileges are needed. Risk: HIGH. Remediation: upgrade urllib3 to >= 2.7.0, which restricts decompression to the requested amount of data.

Something like this might fix it:

uv.lock is a generated file — regenerate it rather than hand-editing. From exploitation/n8n_RCE_via_file_write/, run:

    uv lock --upgrade-package urllib3
    uv sync

Expected lock file change (hashes are filled in automatically by uv):

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

If pyproject.toml pins urllib3, update the constraint to match:

--- a/exploitation/n8n_RCE_via_file_write/pyproject.toml
+++ b/exploitation/n8n_RCE_via_file_write/pyproject.toml
@@
-    "urllib3>=2.6.3,<3",
+    "urllib3>=2.7.0,<3",

Verify afterwards with `uv pip list | grep urllib3` (expect 2.7.0) and re-run the scanner to confirm CVE-2026-44432 is resolved. As defense-in-depth, any code streaming large/unknown server responses should use bounded read(amt) loops and avoid drain_conn() on partially consumed compressed responses.

For reference: rule CVE-2026-44432. 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.