Patch release: 2.0.2 — backport toolchain CVE fixes from #3708

[kpark-hrp]

What version of rules_python do you want to patch?

2.0.x (currently 2.0.1). The default toolchain mapping on release/2.0 is:

MINOR_MAPPING = {
    "3.10": "3.10.19",
    "3.11": "3.11.14",
    "3.12": "3.12.12",
    "3.13": "3.13.11",
    "3.14": "3.14.2",
}

The release/2.0 branch ships Python toolchain versions with several known high-severity CVEs that have already been fixed on main but were not backported. Bumping the 2.0 series would let downstream users pick up these fixes without a major-version migration.

What pull requests do you want to backport?

• feat(toolchains): Add 3.10.20, 3.11.15, 3.12.13, 3.13.{12,13} 3.14.{3,4}, 3.15.0a8 #3708 — feat(toolchains): Add 3.10.20, 3.11.15, 3.12.13, 3.13.{12,13}, 3.14.{3,4}, 3.15.0a8

---

Why (security context)

The interpreter binary and the setuptools/_vendor/* bundle shipped inside the python-build-standalone archives that current release/2.0 toolchains point at are flagged with the following CVEs. Each row shows the minimum Python patch release that contains a fix, and whether the release/2.0 default mapping currently satisfies it.

CVE	Severity	Component	Fixed in (per branch)	release/2.0 default status
CVE-2025-13836	High	CPython http.client — memory DoS on attacker-controlled Content-Length	3.10.20, 3.11.15, 3.12.13, 3.13.11, 3.14.1	3.10/3.11/3.12 vulnerable; 3.13/3.14 OK
CVE-2026-24049	High	wheel (vendored at setuptools/_vendor/wheel-*) — affected >=0.40.0, <=0.46.1	python-build-standalone bundle with setuptools ≥ 80.10 (vendors wheel 0.46.3); i.e. ≥ release 20260414, which maps to 3.10.20 / 3.11.15 / 3.12.13 / 3.13.12 / 3.14.3	vulnerable on every minor (current bundles ship wheel 0.45.1)
CVE-2026-23949	High	jaraco.context (vendored at setuptools/_vendor/jaraco.context-*) — affected >=5.2.0, <6.1.0	Same as above (setuptools ≥ 80.10 vendors jaraco.context 6.1.0)	vulnerable on every minor

All three are remediated together by the toolchain bumps introduced in #3708, since the newer python-build-standalone releases pulled in by that PR ship both the patched interpreter and an updated setuptools bundle.

What this would unblock

A 2.0.2 patch release containing #3708 would let release/2.0 consumers move from 3.11.14 → 3.11.15, 3.12.12 → 3.12.13, 3.10.19 → 3.10.20 (and matching 3.13/3.14 minor bumps) by just bumping bazel_dep(name = "rules_python", version = "2.0.2") and updating minor_mapping.

[aignas]

Feel free creating a PR against the release/2.0 branch with the changes you would like to see. That may speed things up, because there are then more maintainers that can approve. Reason for PRs - we would also need some changes to the changelog. So, in summary:

• Create a PR to main to create a new section for 2.0.2 for the related change.
• Then create a PR to release/2.0 branch with the changelog and the toolchain bump changes.

Until this is done users will have to use single_version_override to get the new versions.

[kevinpark1217]

• feat(toolchains): backport 20260325/20260414 Python toolchains for 2.0.2 (#3708) #3775 — backport #3708 → release/2.0 (2.0.2)
• feat(toolchains): backport 20260325/20260414 Python toolchains for 1.9.1 (#3708) #3776 — backport #3708 → release/1.9 (1.9.1)
• docs: split toolchain bumps from #3708 into 2.0.2 and 1.9.1 changelog sections #3777 — main CHANGELOG carve-out

[aignas]

I see that the CI is failing in https://buildkite.com/bazel/rules-python-python/builds/15427/canvas?sid=019e26bd-63f3-4300-98cf-6f85f40d50df&tab=artifacts (i.e. the release/2.0 backport) and similarly elsewhere.

I am hesitant to approve these PRs due to this reason, because I don't understand if the regression is introduced by the PRs or if it was failing before them. In general the CI should be green before merging such PRs.

[kevinpark1217]

@aignas CI regression fixed. Remaining failures (RBE Ubuntu × 2 on all three PRs, mypy fix on #3776) are pre-existing on main.

[aignas]

Thank you, I'll wait for consensus on #3774 before tagging 2.0.2 to avoid duplicate work.

[kevinpark1217]

Thank you, I'll wait for consensus on #3774 before tagging 2.0.2 to avoid duplicate work.

@aignas Sounds good. How about tagging for 1.9.1?