[icanhasmath]

Security release pip 26.0.1.post3 for the Python 3.9 line, also bundled by 3.10.22.1. It follows up the review of ActiveState/cpython#110: moving 3.10 from pip 26.2.2 to 26.0.1.post2 also moved its vendored urllib3 back to an unpatched 1.26.20.

Changes

Vendored urllib3 1.26.20 → ActiveState urllib3 1.26.20.post4. That release carries 1.26-line ports of these fixes:

CVE	Advisory	Issue
CVE-2025-66418	GHSA-gm62-xv2j-4w53	unbounded Content-Encoding decoder chain
CVE-2025-66471	GHSA-2xpw-w6gg-jr37	streaming API fully decompresses highly compressed data
CVE-2026-21441	GHSA-38jv-5279-wg99	redirect bodies decompressed while draining
CVE-2026-44431	GHSA-qccp-gfcp-xxvc	sensitive headers forwarded on cross-origin redirects
CVE-2026-97687	GHSA-8988-9cw3-xx77	HTTPS proxy TLS used the target's TLS settings
CVE-2026-97689	GHSA-vxq7-64xx-v4gw	unbounded chunk-size and trailer lines
CVE-2025-50181	GHSA-pq67-6m6q-mj2v	PoolManager retries did not limit redirects

• How it was vendored: I took the fork's src/urllib3 from the 1.26.20.post4 sdist and replayed pip's existing vendoring diff on top: the pip._vendor import paths, Brotli disabled, and LICENSE.txt. Every hunk applied cleanly. The fork's new Brotli code is all behind if brotli is not None.
• Version check: urllib3.__version__ stays 1.26.20, so requests' version check doesn't warn.

Vendored requests 2.32.5: CVE-2026-25645 (GHSA-gc5v-m9x4-r6x2)

• This backports upstream's fix (psf/requests 66d21cb07b, released in 2.33.0). extract_zipped_paths() extracted to a predictable name in the shared temporary directory and reused any file already there. It now extracts to a new mkstemp file.
• It also ports upstream's companion commit e331a288f3 (9dac45c). HTTPAdapter.cert_verify() now uses the default CA bundle path directly instead of passing it through extract_zipped_paths().
• pip didn't reach the vulnerable path. pip's vendored certifi extracts cacert.pem to a real file itself, so extract_zipped_paths() returned early even when pip runs from a zip. Both changes are defense in depth.

Validation

urllib3's own test suite, in python:3.9-slim and python:3.10-slim, comparing the fork's sdist with upstream urllib3 1.26.20 and without Brotli, as in pip:

• Fork: 1456 pass, 5 fail.
• Upstream: 1385 pass, 4 fail.
• Shared failures: four fail on both and come from the container setup: test_recent_date, two test_tunneling_proxy_request_timeout cases and test_ssl_read_timeout.
• Fork-only failure: test_proxy_https_target_tls_error[https-True]. That test expects an SSLError for forwarding through an HTTPS proxy, which only happened because of CVE-2026-97687: the target's TLS context was applied to the proxy. Upstream 2.7.0 skips that case as a known bug (urllib3#2577), and 2.8.0, which has the fix, drops it. So it's a stale test in the fork, not a regression. I'll fix that test in ActiveState/urllib3 separately.

pip wheel, built with python -m build, in python:3.9-slim and python:3.10-slim:

• Versions: pip reports 26.0.1.post3, with vendored urllib3 1.26.20 (the fork), requests 2.32.5 and certifi 2026.10.23. requests emits no RequestsDependencyWarning, even under -W error.
• Running from a zip: python pip-26.0.1.post3-py3-none-any.whl/pip download six==1.16.0 works with the companion change.
• CVE-2026-25645 check: with a planted cacert.pem in the temp directory, extract_zipped_paths() returns a new file with the zip's content, not the planted file, and a different path on every call.
• Network: pip download six==1.16.0 and a pip install --dry-run requests==2.32.3 resolution against PyPI both work.
• Diff from the 26.0.1.post2 release asset: the wheel differs only in pip/__init__.py, vendor.txt, requests/utils.py and five urllib3 files, plus RECORD and the metadata version. The urllib3 files in the wheel are identical to the vendored tree in this PR.

After merge: tag 26.0.1.post3 and publish the release. Then bundle it in CPython 3.9.25.1 and 3.10.22.1 (ActiveState/cpython#110).

[ezequielp-activestate]

No blockers.

• Vendored urllib3: I replayed pip's own vendoring diff (upstream urllib3 1.26.20 against the vendored copy on 26.0.1.x) onto src/urllib3 from the ActiveState urllib3 1.26.20.post4 release sdist. All 8 hunks apply cleanly, and the result is byte-identical to src/pip/_vendor/urllib3 in this PR. LICENSE.txt is unchanged. The five files that differ from the base are exactly the five post4 changes relative to upstream 1.26.20.
• requests CVE-2026-25645: the extract_zipped_paths() change is identical to upstream psf/requests 66d21cb07b, and upstream hasn't changed that function since.
• Through pip on Python 3.9: pip reports 26.0.1.post3, and importing it under -W error raises no RequestsDependencyWarning. The vendored urllib3 refuses a 6-link Content-Encoding chain ('Too many content encodings in the chain: 6 > 5'), and a 64 MiB deflate bomb through stream(65536) yields pieces of at most 65,536 bytes. pip download six==1.16.0 works.

⚪ Two small notes:

• The description overstates the zip case. It says the requests fix matters when pip runs from a zip, but on 3.9 that path isn't reached. Run from a zip, pip's vendored certifi extracts cacert.pem to a real file itself, so extract_zipped_paths() returns early. Three HTTPAdapter.cert_verify() calls created no temp files. The fix is still correct to carry.
• Optional companion commit. Upstream's companion commit e331a288f3 (also in 2.33.0) drops that extract_zipped_paths(DEFAULT_CA_BUNDLE_PATH) call from HTTPAdapter.cert_verify (adapters.py:300 here). Porting it would remove the path entirely, but nothing reaches it today.

[icanhasmath]

Both notes are addressed in 9dac45c.

• Zip case: you're right, pip never reached the path. The NEWS entry and the PR description now say the vendored certifi already extracts its bundle, so the fix is defense in depth.
• Companion commit: I ported e331a288f3. cert_verify() now uses DEFAULT_CA_BUNDLE_PATH directly, with upstream's comment in utils.py. Nothing else in the vendored code calls extract_zipped_paths().
• Re-checked in python:3.9-slim and python:3.10-slim: versions, no RequestsDependencyWarning, the extract_zipped_paths() planted-file check, pip download, and a --dry-run resolution all pass. python pip-26.0.1.post3-py3-none-any.whl/pip download six==1.16.0 (pip running from the zip) also works.

[ezequielp-activestate]

Re-review of 9dac45c: still approved. Both notes are addressed:

• e331a288f3: the adapters.py and utils.py changes are identical to upstream's. cert_verify() now uses DEFAULT_CA_BUNDLE_PATH directly. extract_zipped_paths() is still defined, but nothing in pip calls it any more.
• NEWS: the entry now describes the requests fix as defense in depth, which matches what pip actually reaches.

Running pip from a zip of this tree, on Python 3.9 and 3.10, under -W error: pip 26.0.1.post3 imports with vendored urllib3 1.26.20 (the fork) and requests 2.32.5. DEFAULT_CA_BUNDLE_PATH is the real temp file certifi extracts, and pip download six==1.16.0 works.