Came across something in uv.lock around line 1 that looked worth flagging.
AIOHTTP version 3.13.3 contains a flaw in its C response‑header parser that permits null bytes (\0) and other control characters in HTTP response headers. An attacker-controlled server could exploit this to inject malformed headers, potentially causing crashes, header injection, or bypassing security checks that rely on header integrity. While the reported severity is LOW, the ability to corrupt header parsing can lead to denial‑of‑service or further exploitation in a broader attack chain, so it should be treated as a critical issue in production environments. The fix is included in AIOHTTP 3.13.4.
Something like this might fix it:
*** Begin Patch
*** Update File: uv.lock
@@
- "aiohttp": {
- "version": "==3.13.3",
+ "aiohttp": {
+ "version": "==3.13.4",
*** End Patch
For reference: rule CVE-2026-34520. Rated critical.
I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Came across something in
uv.lockaround line 1 that looked worth flagging.AIOHTTP version 3.13.3 contains a flaw in its C response‑header parser that permits null bytes (\0) and other control characters in HTTP response headers. An attacker-controlled server could exploit this to inject malformed headers, potentially causing crashes, header injection, or bypassing security checks that rely on header integrity. While the reported severity is LOW, the ability to corrupt header parsing can lead to denial‑of‑service or further exploitation in a broader attack chain, so it should be treated as a critical issue in production environments. The fix is included in AIOHTTP 3.13.4.
Something like this might fix it:
For reference: rule
CVE-2026-34520. Rated critical.I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.