urllib3 is an HTTP client library for Python

CVE-2026-44432 is a client-side decompression-bomb DoS in urllib3 affecting PyPI versions >=2.6.0 and <2.7.0. When an application uses urllib3's streaming API against compressed HTTP responses, two edge paths can cause the library to decompress far more data than requested: the second partial read with the official brotli package, or a call to HTTPResponse.drain_conn() after partial decompression has already started. Result: a tiny compressed response can expand into high CPU and large memory allocation on the client process.

The vendor's HIGH label matches the *theoretical* availability impact, but it overshoots for enterprise prioritization. This is not a generic unauthenticated server-side DoS against every host running urllib3; it requires a victim application to both fetch attacker-controlled or otherwise untrusted compressed content and to hit one of two specific streaming code paths. That combination is real, but narrow enough that this belongs in MEDIUM, not your top patch queue.

Why this verdict

• Downward adjustment: requires attacker-controlled upstream content — the attacker is not hammering your server directly; they need your application to fetch a malicious or untrusted HTTP response first. In many estates that implies a pre-existing business feature such as URL fetch, crawler behavior, webhook retrieval, or a weak egress policy.
• Downward adjustment: only specific runtime paths are vulnerable — ordinary use of urllib3 is not enough. You need the streaming API plus either a second partial read with the official brotli package or an explicit drain_conn() call after decompression starts.
• Downward adjustment: narrow affected population — only urllib3 versions 2.6.0 through 2.6.3 are in play, and major distro tracks like Debian stable lines and Amazon Linux show not-affected status. That is a much smaller patch surface than 'all urllib3 everywhere'.
• Downward adjustment: availability only — there is no code execution, credential theft, or privilege gain here. The blast radius is usually the consuming worker or service instance.
• Downward adjustment: no exploitation pressure — no KEV listing, no public campaign reporting, and no obvious weaponized PoC means there is no evidence of broad attacker demand.

Why not higher?

If this were a generic server-side unauthenticated DoS against every host exposing a service, HIGH would be fair. But the attack chain compounds friction at every stage: outbound fetch requirement, untrusted upstream requirement, streaming API requirement, and either Brotli-specific behavior or explicit drain_conn() usage. That is too much narrowing for a top-tier patch emergency.

Why not lower?

This is still a real remote availability issue when the application pattern exists. Enterprises do run scrapers, collectors, URL validators, and third-party integration workers that ingest untrusted content, and those roles can be knocked over cheaply with a small compressed payload. If you own those patterns, this deserves active cleanup rather than backlog amnesia.

1. Inventory urllib3 2.6.x consumers — Use SBOM/SCA and environment introspection to find Python runtimes shipping urllib3 >=2.6.0,<2.7.0, then separate internet-facing fetchers and untrusted-content workers from ordinary internal clients. This is a MEDIUM verdict, so there is no noisgate mitigation SLA; do the triage as part of normal remediation planning and prioritize the exposed fetch paths first.
2. Disable or constrain untrusted outbound fetches — Where the application does not need arbitrary URL retrieval, tighten egress allowlists, SSRF guardrails, proxy policy, or destination validation so attackers cannot steer the client at a malicious origin. This meaningfully breaks step 1 of the chain and is the best compensating control when patch rollout is slow.
3. Prefer safer decompression behavior — If you cannot upgrade immediately and you specifically rely on the Brotli path, follow the maintainer guidance and prefer brotlicffi over the official brotli package until urllib3 is upgraded. That only mitigates one branch, but it is a clean tactical reduction in exposure.
4. Stop calling drain_conn() on partially decompressed responses — If your code explicitly uses HTTPResponse.drain_conn() after partial reads, switch to HTTPResponse.close() where connection reuse is not important. That removes the second vulnerable branch entirely and is a straightforward application-level workaround.
5. Enforce worker resource ceilings — Set container memory limits, request timeouts, and restart policies around fetcher or ingestion workers so a decompression bomb kills a small unit of work instead of starving a node. This does not patch the flaw, but it keeps the blast radius process-local while you move to the fixed version inside the 365-day remediation window.

Run this on the target host or inside the exact Python virtualenv/container image that ships the application. Invoke it with the same interpreter the app uses, for example: python3 verify_urllib3_cve_2026_44432.py. No admin rights are required unless you need access to a restricted virtualenv or container filesystem.

#!/usr/bin/env python3
# verify_urllib3_cve_2026_44432.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import re
import sys
from importlib import metadata

CVE = "CVE-2026-44432"
PKG = "urllib3"
VULN_INTRO = (2, 6, 0)
VULN_FIXED = (2, 7, 0)


def normalize(v):
    if v is None:
        return None
    m = re.match(r"^(\d+)\.(\d+)\.(\d+)", str(v))
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def has_dist(name):
    try:
        metadata.version(name)
        return True
    except metadata.PackageNotFoundError:
        return False
    except Exception:
        return False


def main():
    try:
        version = metadata.version(PKG)
    except metadata.PackageNotFoundError:
        print(f"UNKNOWN: {PKG} is not installed in this interpreter; cannot assess {CVE}")
        sys.exit(2)
    except Exception as exc:
        print(f"UNKNOWN: failed to read {PKG} version: {exc}")
        sys.exit(2)

    parsed = normalize(version)
    if parsed is None:
        print(f"UNKNOWN: could not parse {PKG} version '{version}'")
        sys.exit(2)

    brotli_present = has_dist("brotli")
    brotlicffi_present = has_dist("brotlicffi")

    extra = []
    if brotli_present:
        extra.append("official brotli installed")
    if brotlicffi_present:
        extra.append("brotlicffi installed")
    extra_text = "; ".join(extra) if extra else "no Brotli helper package detected"

    if VULN_INTRO <= parsed < VULN_FIXED:
        print(
            f"VULNERABLE: {PKG} {version} is in the affected range for {CVE} ({extra_text}). "
            "Actual exploitability is higher if the app uses streaming reads against untrusted compressed responses "
            "or calls HTTPResponse.drain_conn() after partial decompression."
        )
        sys.exit(1)

    print(
        f"PATCHED: {PKG} {version} is outside the affected range for {CVE} ({extra_text})."
    )
    sys.exit(0)


if __name__ == "__main__":
    main()

Sources

1. GitHub Security Advisory GHSA-mf9v-mfxr-j63j
2. NVD CVE-2026-44432
3. GitHub Advisory Database JSON
4. urllib3 2.7.0 release notes
5. PyPI urllib3 2.7.0 package page
6. Debian security tracker
7. Ubuntu CVE search results
8. CISA Known Exploited Vulnerabilities Catalog