Python on servers: supported versions and safe updates

Updated November 2026

Run a supported Python branch (3.11 to 3.15), let the operating system update its own Python, keep each application in a virtual environment, and scan that environment with pip-audit. On October 25, 2026, the Python project shipped expedited security releases 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18.

Who uses it

Python runs web apps (Django, Flask, FastAPI), automation and monitoring scripts, and parts of the operating system itself: many distribution admin tools are Python scripts that run on the system interpreter. That is why a server usually has two kinds of Python: the system Python that the OS owns, and application environments that you own.

Supported versions

Each branch gets five years of fixes. For the first two years it is in "bugfix" status, with regular binary releases about every two months. After that it gets security fixes only, released as source code when needed, with no new Windows or macOS installers.

CPython branches as of November 3, 2026
BranchStatusFirst releaseEnd of lifeLatest
3.15BugfixOct 9, 2026Oct 20313.15.2
3.14BugfixOct 7, 2025Oct 20303.14.10
3.13SecurityOct 7, 2024Oct 20293.13.18
3.12SecurityOct 2, 2023Oct 20283.12.16
3.11SecurityOct 24, 2022Oct 20273.11.18
3.10End of lifeOct 4, 2021Oct 1, 20263.10.22 (final)

The October 25 releases fixed CVE-2026-115557 (the ssl module now blocks the compromised eMudhra intermediate CA keys) and CVE-2026-114583 (a bypass of tarfile's tar_filter through crafted links). The 3.12.16 release also updated the bundled Expat library. Per-CVE details are on our vulnerability pages.

Check the installed version

python3 --version
python3 -c 'import sys; print(sys.version)'
which -a python3 python3.11 python3.12 python3.13 python3.14 2>/dev/null
readlink -f "$(command -v python3)"
dpkg -S "$(readlink -f "$(command -v python3)")"     # Debian/Ubuntu: owning package
rpm -qf "$(readlink -f "$(command -v python3)")"     # RHEL/Fedora/SUSE
/srv/myapp/.venv/bin/python --version               # an app's virtual environment
ps -eo pid,lstart,args | grep '[p]ython'            # running Python processes

A distro package keeps its original version number and gets fixes backported, so Debian 12's 3.11.2-6+deb12u9 is newer than plain 3.11.2. Compare the full package version with the distro's security tracker, not with python.org. See Check installed versions.

System Python vs app venvs

Leave the system Python to the package manager. Do not replace /usr/bin/python3, do not change it with update-alternatives, and do not run sudo pip install. Debian and Ubuntu mark their system Python as "externally managed", so pip refuses to install into it outside a virtual environment. Breaking the system Python can break the admin tools you need to patch the server.

Give each app its own virtual environment (venv), owned by the app's user:

sudo -u myapp python3 -m venv /srv/myapp/.venv
sudo -u myapp /srv/myapp/.venv/bin/python -m pip install --upgrade pip
sudo -u myapp /srv/myapp/.venv/bin/python -m pip install -r /srv/myapp/requirements.txt

A venv points to the interpreter that created it. When the distro updates Python inside the same minor version (3.12.x), the venv picks it up at the next restart. When you move to a new minor version (3.12 to 3.13), create a new venv and reinstall your requirements; do not copy the old one.

Distribution packages

Default Python 3 per release, checked November 3, 2026
SystemDefault python3Other versions
Debian 13 (trixie)3.13
Debian 12 (bookworm)3.11
Ubuntu 26.04 LTS3.14
Ubuntu 24.04 LTS3.12
Ubuntu 22.04 LTS3.10
RHEL 103.123.14 stream to May 2029
RHEL 93.93.12 to Apr 2027, 3.14 to May 2029
RHEL 83.63.12
FreeBSD ports3.12other lang/python3* ports

Older numbers such as RHEL 9's 3.9 or Ubuntu 22.04's 3.10 are past upstream end of life but still get fixes from the distribution for as long as that OS release is supported. Backports can lag: on November 3, the Debian tracker still listed CVE-2026-114583 as open for python3.13 in trixie and python3.11 in bookworm.

Apply the distro's updates:

sudo apt update && sudo apt install --only-upgrade 'python3*' 'libpython3*'   # Debian/Ubuntu
sudo dnf upgrade --refresh 'python3*'                                          # RHEL/Fedora
sudo zypper patch                                                              # SUSE (all security patches)
sudo apk -U upgrade                                                            # Alpine
sudo pkg upgrade -g 'python3*'                                                 # FreeBSD

On RHEL, install a newer stream next to the default (for example sudo dnf install python3.12) and build app venvs from /usr/bin/python3.12. The default python3 stays as it is.

Containers and newer builds

If the distro's Python is too old for your app, use an official python container image or a separately installed interpreter for the app only. Pin the minor version, such as FROM python:3.13-slim-trixie or python:3.14-slim, and rebuild after each Python release:

docker build --pull -t myapp:latest .
docker compose build --pull && docker compose up -d     # recreates containers
docker compose exec app python --version

More in Containers. Remember that 3.11 to 3.13 now get source-only releases, so whoever builds your interpreter must rebuild it.

Audit packages with pip-audit

Most Python advisories affect packages from PyPI, not the interpreter. pip-audit (maintained under the Python Packaging Authority) checks installed packages or a requirements file against the PyPI vulnerability data and the OSV database. Install it inside the venv you want to check:

/srv/myapp/.venv/bin/python -m pip install pip-audit
/srv/myapp/.venv/bin/pip-audit -l --desc        # this venv's packages, with descriptions
pip-audit -r requirements.txt                   # check a requirements file
pip-audit --fix --dry-run                       # show what --fix would upgrade
pip-audit --fix                                 # upgrade vulnerable packages
pip-audit -f json -o audit.json                 # machine-readable report
pip-audit -r requirements.txt --require-hashes  # repeatable audit of hashed requirements

pip-audit exits with code 1 when it finds a known vulnerability, so it can fail a CI job or a cron check. Use --ignore-vuln ID only for a finding you have reviewed. Two limits: auditing a requirements file is like running pip install on it, so only audit files you trust; and pip-audit does not cover the Python interpreter or C libraries that packages bundle. After --fix, update your pinned requirements so the next deploy does not bring the old version back.

Restart and verify

A running process keeps the old interpreter and libraries in memory. After an update, restart (not just reload) each Python service:

sudo systemctl restart myapp.service          # restarts the app
systemctl show -p ExecMainStartTimestamp myapp.service
ps -eo pid,lstart,args | grep '[p]ython'      # nothing should predate the update
/srv/myapp/.venv/bin/python -c 'import ssl, sys; print(sys.version, ssl.OPENSSL_VERSION)'

Run the app's health check afterwards. See Restarts and reboots.

Security advisories

Hardening tips

On an end-of-life branch

If an app runs on Python 3.10 or older from python.org, a custom build or an old container image, it gets no more fixes. Move it to 3.13 or 3.14: create a new venv on the new interpreter, install your requirements, run your tests, then switch the service. If the old version comes from a supported distribution, it is still patched, but plan the move before that OS release ends. See Is my OS supported?.

Sources