Python End-of-Life Dates: Every Version's Support Timeline

Python powers everything from machine learning pipelines to enterprise web applications, but every Python version has an expiration date. When a version reaches end of life (EOL), the Python Software Foundation stops releasing security patches, leaving your applications exposed to newly discovered vulnerabilities.

This guide covers the complete support timeline for every actively relevant Python version, from 3.8 through 3.14, including the distinction between bug-fix and security-only support phases, exact EOL dates, and the critical nuances around distribution-specific support extensions that catch many teams off guard.

‍

Python Support Lifecycle: How It Works

The Python Software Foundation follows a predictable support lifecycle established by PEP 602. Each Python release goes through two main phases before reaching end of life:

Bug-fix phase (approximately 2 years): The version receives full bug fixes, security patches, and binary releases. This is the period where a version is considered fully supported for production use.

Security-only phase (approximately 3 years): Only critical security fixes are accepted. No more bug fixes, no pre-built binaries, and source-only releases are published as needed. Many teams mistakenly treat security-only versions as "fully supported," but critical ecosystem tools and libraries often drop support during this phase.

End of life (after ~5 years total): The release cycle is frozen entirely. No further changes of any kind are accepted. Any vulnerability discovered after this date will never be patched upstream.

‍

Python End-of-Life Dates: Complete Reference Table

Dates sourced from the Python Developer Guide and PEP release schedules. Approximate future dates are set by each version's release manager and may be adjusted.

‍

Python 3.9: Already End of Life

Python 3.9 reached end of life on October 31, 2025, with Python 3.9.25 published as the final security release. The upstream codebase is now frozen: no new bug fixes, security patches, or enhancements will be provided. Any unresolved issues in the CPython bug tracker for Python 3.9 will remain unresolved permanently.

This matters because Python 3.9 remains widely deployed. It was the default system interpreter for several major Linux distributions, and many organizations built long-running applications and CI/CD pipelines around it.

Known CVEs affecting Python 3.9 include vulnerabilities in the tarfile module, the http.cookies parser, SSLContext NPN protocol handling, and the venv CLI. In September 2024, emergency security patches were required across Python versions 3.8.20 through 3.12.6 to address remote code execution and web cache poisoning vulnerabilities. Python 3.9 received those patches, but any future vulnerability of similar severity will go unpatched.

‍

Python 3.10: End of Life Coming October 2026

Python 3.10 is currently in its security-only phase and reaches end of life on October 31, 2026, approximately 8 months from now. This is the next major Python EOL event, and teams running Python 3.10 in production should be planning their migration strategy now.

Python 3.10 introduced structural pattern matching (match/case statements), improved error messages, and ParamSpec for better typing support. These features mean that code written for 3.10+ often cannot easily be backported to 3.9, creating a natural migration cliff that makes upgrading feel one-directional.

The urgency is compounded by library support. Major frameworks and packages are already dropping Python 3.10 from their test matrices and CI pipelines. When a library you depend on drops 3.10 support, you stop receiving security fixes for that dependency as well, not just for CPython itself.

‍

The Red Hat Complication: RHEL 9 and Python 3.9

One of the most common sources of confusion in the Python EOL landscape is Red Hat Enterprise Linux 9. RHEL 9 ships Python 3.9 as its default system interpreter, and Red Hat has committed to supporting Python 3.9 for the full lifecycle of RHEL 9, which extends through approximately May 2032 (maintenance support end).

This creates a significant gap between upstream and distribution support:

Upstream (Python Software Foundation): Python 3.9 is end of life. No patches, no fixes, no exceptions.

RHEL 9 (Red Hat): Python 3.9 remains fully supported with Red Hat-backported security patches for critical and important CVEs.

RHEL 8: Python 3.9 support ended in November 2025. Newer versions (3.11, 3.12) are available as Application Streams.

What this means in practice: If you run Python 3.9 on RHEL 9, Red Hat will backport critical security fixes. But Red Hat's coverage is limited to CVEs they deem critical or important (typically CVSS 7.0+). Lower-severity vulnerabilities, bug fixes, and ecosystem compatibility issues will not be addressed. Additionally, third-party libraries and frameworks that drop Python 3.9 support will not be covered by Red Hat's backporting efforts.

For teams running Python 3.9 outside of RHEL 9 (on Ubuntu, Alpine, Amazon Linux, containers, or cloud platforms), there is no distribution-level safety net. You are running an unsupported runtime.

‍

Other Distribution-Specific Python Support

Red Hat is not the only distribution that extends Python support beyond upstream EOL. Several other distributions and platforms maintain their own Python lifecycle policies:

Ubuntu LTS: Ubuntu 22.04 LTS ships Python 3.10 and will receive security updates through April 2027 (standard) or April 2032 (with Ubuntu Pro). Ubuntu 24.04 LTS ships Python 3.12.

Amazon Linux 2023: Ships Python 3.9 as the default, with support planned through March 2028.

Debian 12 (Bookworm): Ships Python 3.11, with security support through approximately June 2028.

Alpine Linux: Tracks upstream closely and typically drops support shortly after upstream EOL.

Wolfi/Chainguard: Maintains current Python versions with rapid updates aligned to upstream release cycles.

In every case, distribution support covers the CPython interpreter itself. It does not extend to the broader Python package ecosystem (PyPI packages, frameworks, or tools), which sets its own deprecation schedules independently.

‍

Security Vulnerabilities in EOL Python Versions

Running an end-of-life Python version is not a theoretical risk. CPython had 12 published security vulnerabilities in 2025 alone, spanning modules that are widely used in production applications:

tarfile module (CVE-2025-4330, CVSS 7.5): Allows modifying file metadata or permissions outside the extraction directory when using the filter= parameter. This affects any application that extracts untrusted tar archives.

xml.dom.minidom (CVE-2025-66999, CVSS 6.3): Quadratic complexity when building nested elements using appendChild(), enabling denial-of-service attacks through crafted XML.

os.path.expandvars (CVE-2025-63654, CVSS 5.5): Performance degradation with user-controlled input, opening the door to resource exhaustion attacks.

http.client (CVE-2025-67350, CVSS 7.5): Allows a malicious server to force clients to read unlimited data into memory using Content-Length manipulation, potentially causing out-of-memory crashes.

base64 module (CVE-2025-12781): The b64decode() function always accepts +/ characters regardless of the configured altchars parameter, potentially causing data integrity issues in applications that rely on alternative base64 alphabets.

For EOL versions like Python 3.8 and 3.9, none of these vulnerabilities will ever receive an upstream patch. Organizations running these versions must either accept the risk, apply patches themselves, or find alternative support.

‍

What "Security-Only" Really Means for Your Dependencies

Even versions still in their security-only phase (3.10, 3.11, 3.12) carry risk that is easy to underestimate. During the security-only phase:

No pre-built binaries are published, which means building from source on some platforms. Major libraries begin dropping support, starting with those that adopt SPEC 0 (the Scientific Python ecosystem's version support policy), which recommends supporting only the three most recent minor Python versions. CI/CD tools and cloud platforms may deprecate older Python versions from their managed runtimes. The lack of bug fixes means that non-security bugs discovered during this phase will never be resolved.

For enterprise teams, the practical implication is that "security-only" is a transitional state, not a permanent solution. Planning should begin well before a version enters this phase.

‍

Your Options When Python Reaches End of Life

When a Python version you depend on reaches EOL, you have several paths forward:

1. Upgrade to a Supported Python Version

The most straightforward option. Python's annual release cadence means there is always a supported version available. However, upgrading is not always simple:

Structural pattern matching (3.10), exception groups (3.11), and per-interpreter GIL changes (3.12/3.13) introduce syntax and behavioral changes that can break existing code. Third-party dependencies may not support the target version yet, or may have dropped support for your current version, creating a narrow compatibility window. Large codebases, monorepos, and applications with extensive C extension dependencies face longer migration timelines.

2. Use Distribution-Provided Extended Support

If you run RHEL 9, Amazon Linux 2023, or Ubuntu LTS with an extended support subscription, your distribution may continue providing critical security patches for the Python interpreter. This buys time but does not address ecosystem-level deprecation.

3. Adopt Never-Ending Support (NES) for Python

For organizations that cannot migrate on the upstream timeline, HeroDevs' Never-Ending Support provides secure, drop-in replacements for end-of-life Python versions. NES delivers ongoing security patches, CVE remediation, and compliance documentation (SBOMs, VEX) for Python versions after the Python Software Foundation stops providing updates.

This approach is particularly relevant for teams that:

• Run Python applications in regulated environments requiring supported runtimes (SOC 2, PCI DSS, FedRAMP, EU CRA).
• Have complex dependency chains that make upgrading a multi-quarter effort.
• Need to maintain Python 3.9 or 3.10 workloads beyond their upstream EOL dates while planning a migration on their own timeline.

‍

Key Dates to Watch

Now (February 2026): Python 3.9 is already EOL. Python 3.8 has been EOL since October 2024. If you are running either version, you are accumulating unpatched vulnerabilities.

October 31, 2026: Python 3.10 reaches end of life. Begin planning your migration or support strategy now.

October 31, 2027: Python 3.11 reaches end of life.

October 31, 2028: Python 3.12 reaches end of life.

~May 2032: RHEL 9 maintenance support ends, taking Red Hat's Python 3.9 backporting with it.

‍

How to Check Your Python Version

Run this command to identify which Python version your application is using:

python --version
# or
python3 --version

For environments with multiple Python installations, check specific paths:

which python3
python3 -c "import sys; print(sys.version)"

To audit Python versions across your infrastructure, check your Docker base images, CI/CD runner configurations, cloud function runtimes, and virtual environment pinfiles (pyproject.toml, setup.cfg, .python-version).

‍

Stay Ahead of Python EOL Dates

The Python ecosystem's annual release cadence means EOL events are predictable and plannable. The teams that struggle are the ones that wait until after a version reaches end of life to start migrating.

Whether you upgrade, leverage distribution support, or adopt Never-Ending Support, the key is having a plan before the deadline arrives. With Python 3.10's EOL just 8 months away, now is the time to audit your Python footprint and decide on your path forward.

Need help with EOL Python versions? Contact HeroDevs to learn how Never-Ending Support keeps your Python applications secure and compliant after upstream support ends.