CVE-2026-97689 is a high severity (CVSS 7.5) resource exhaustion flaw in the Python urllib3 library from 1.10.3 until 2.8.0. The streaming chunked reader can buffer an unlimited chunk size line from a malicious server. The fix is urllib3 2.8.0, which rejects oversized chunk size fields.
What's affected
The urllib3 advisory lists versions from 1.10.3 up to but not including 2.8.0 as affected, and 2.8.0 as patched. The weakness is CWE-770, allocation of resources without limits.
The advisory says the problem is in read_chunked and stream on the HTTPResponse object. When decoding a chunked response, the reader buffers each chunk size field until it sees a newline or the end of the stream. A malicious server can send a very long run of bytes with no newline, and the client buffers all of it before it can reject the size as invalid. The requests library's streaming API uses urllib3 and is affected too.
The fix rejects chunk size fields larger than 65536 bytes, as the non streaming path already did. The advisory text gives the number as 65536 in one place and 66536 in another. The first is the figure the standard library uses, and it is the one to rely on.
How to check if you're exposed
Find the urllib3 version in every Python environment.
pip show urllib3
pip freeze | grep -i urllib3
Then find code that streams responses from servers you do not control: calls to stream, read_chunked, or requests with stream set to true that read from third party hosts. Servers you control and trust are a lower concern than public endpoints, user supplied URLs or webhooks.
What to do now
- Upgrade urllib3 to 2.8.0 or later and refresh lock files and container images.
- Run workers that fetch user supplied URLs with a memory limit and a restart policy.
- Set timeouts on all outbound fetches and avoid following user supplied URLs without validation.
- Update packages that vendor urllib3, since a copy inside another package is not fixed by upgrading yours.
- Check that requests, other libraries that depend on urllib3 resolve to the fixed version after the upgrade.
- Paste your lockfile or manifest into the free in-browser dependency scan to see whether the affected package is in your tree, then use reachability analysis to separate code paths you call from ones you never touch.
Why it matters
HTTP clients trust servers more than they should. A server that answers is allowed to send anything, and a client that buffers without a limit hands it control over the client's memory. CWE-770 is the general fault. The standard library already refused such lines on the non streaming path, so the streaming path was an inconsistency rather than a design choice.
The damage is denial of service in the client process. For a crawler, webhook sender or proxy service that fetches many URLs, one hostile response can take a worker down. The record does not mark exploitation and the CVE is not in CISA's catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does it affect requests?
Yes. The advisory says the requests streaming API uses urllib3 and is also affected.
Does this matter for servers I trust?
The risk comes from a malicious server. Trusted internal services are a lower concern, but upgrade anyway.
Sources
Last reviewed: 18 October 2026.
