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

[begininvoke]

Small change to exploitation/n8n_RCE_via_file_write/uv.lock — a scan flagged the code below and it looked genuine. It is 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.

Updated urllib3 lockfile version from 2.6.3 to 2.7.0 and adjusted associated URLs to reference the new version, ensuring the lockfile remains syntactically valid and reflects the required upgrade to address the CVE.

For reference: rule CVE-2026-44432. Rated high.

I do not know the codebase, so please check the change fits how the rest of it works. Happy to adjust it or close this if the reasoning is off.

---

Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.