Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 are out

The Python release team published expedited security updates across five supported branches, delivering Python 3.15.2 alongside maintenance point releases for 3.14.10, 3.13.18, 3.12.16, and 3.11.18. According to Python Insider's report, the primary motivation behind the coordinated rollout is an immediate intervention to distrust compromised intermediate Certificate Authority keys issued by eMudhra. The update ensures that the interpreter blocks the compromised certificates within the underlying transport layer, neutralising potential man-in-the-middle exploits across automated build environments, developer laptops, and production deployments.

This breakdown outlines the full contents of Python 3.15.2, the architectural adjustments made across the standard library, installation considerations, and compatibility notes for developers running active Python stacks. Platform engineers, systems administrators, and backend software developers who deploy Python runtimes across Linux distributions, macOS systems, or Windows servers should review these details to plan upgrades and safeguard package installation flows across internal networks and container infrastructure.

What Python 3.15.2 shipped

Python 3.15.2 brings critical security content led by CVE-2026-115557 and tracked under issue gh-160040, which blocks compromised eMudhra intermediate CA keys directly within the standard library ssl module. By enforcing this block inside the interpreter as a last-resort defense mechanism, network connections established through standard library sockets will explicitly refuse to trust certificates originating from those compromised credentials. The release also ships official pre-built binary installers for 3.15.2 and 3.14.10, while the remaining maintenance branches—Python 3.13.18, 3.12.16, and 3.11.18—are provided strictly as source-only releases.

Beyond certificate distrust, Python 3.15.2 delivers shared vulnerability patches applied uniformly across all five release branches. These updates resolve CVE-2026-114583 via issue gh-160097, which hardens tarfile.tar_filter against malicious archive structures by rejecting links designed to replace destination paths during extraction. The update also integrates the resolution for gh-160300 inside http.cookiejar, forcing the client parser to immediately reject incoming HTTP cookies formatted with negative version integers. The releases were prepared and signed by Python core release managers Hugo van Kemenade, Thomas Wouters, Pablo Galindo Salgado, Ned Deily, and Steve Dower.

What changed for builders in Python 3.15.2

For software builders, automation pipelines, and infrastructure engineers, the distrust mechanism inside Python 3.15.2 establishes automatic transport safeguards for standard package management tasks. Typical package installations and upgrades executed through pip, including operations that fetch and update pip itself, are protected against network attacks based on the compromised eMudhra keys even on machines where the local pip wheel has not been updated yet. This network protection applies transparently to automated continuous integration runners and build containers running Python 3.15.2.

The release branch distinctions also establish clear patch parity boundaries across legacy and modern Python runtimes, as summarized in the table below:

Engineers maintaining modern 3.15 deployments already retain the earlier patches introduced in 3.15.0 and 3.15.1, such as Expat 2.9.0 XML parser updates and Windows registry isolation, while older branches receive them simultaneously in this security sweep.

How to install or upgrade Python 3.15.2

Upgrading to Python 3.15.2 depends on your target operating system and environment. Because Python 3.15.2 supplies compiled binary installers, desktop developers and system operators on supported platforms can download and run the official installer packages directly to refresh the system runtime. Once the base binary is installed, verify the active interpreter and confirm that the version string reports 3.15.2 before upgrading internal tools or setting default environment shims.

python3.15 -V

For environments where multiple interpreter versions reside on the same system, administrators can configure default aliases or explicit environment variables to ensure scheduled scripts and shell sessions select the updated 3.15.2 binary over unpatched releases.

python3.15 -m pip install --upgrade pip

Gotchas and compatibility in Python 3.15.2

Teams transitioning to Python 3.15.2 should audit legacy applications that interface with external networks using certificates issued under the affected intermediate CA hierarchies. Because the ssl module enforces an outright block against compromised eMudhra intermediate keys as a terminal safeguard, applications attempting handshakes with endpoints that rely on these certificates will fail at the transport negotiation stage. Upstream server certificates that chain back to these invalid intermediate keys must be reissued through uncompromised certificate authorities before client connections can succeed.

Archive handling routines and web scraping applications may also encounter stricter validation behaviors under Python 3.15.2. Scripts utilizing tarfile.tar_filter will immediately reject archives containing link structures that attempt to overwrite destination targets, preventing extraction of non-conforming or maliciously crafted files. Similarly, services receiving web requests or parsing unusual session tokens via http.cookiejar will reject cookies that specify negative version numbers, potentially impacting client interactions with misconfigured external HTTP proxies.

What to watch after Python 3.15.2

Following the distribution of Python 3.15.2, operations teams must distinguish between systems that can receive official binary updates and environments pinned to earlier releases that require compiling from source. While Python 3.15.2 and 3.14.10 benefit from turnkey binary installer distributions, teams operating on Python 3.13.18, 3.12.16, and 3.11.18 must rely entirely on source tarball compilations, package manager rebuilds, or Linux distribution vendor backports to deploy equivalent protections.

Organizations managing substantial Python footprints should track upcoming maintenance schedules across all active release branches to ensure downstream components remain aligned. Upgrading is strongly recommended by the Python release management team for all developers operating on affected versions. Contributions and volunteer participation through the Python Software Foundation remain the foundational mechanism sustaining ongoing security triage, release engineering, and rapid vulnerability remediation across the entire standard library lifecycle.