Python on servers: supported versions and safe updates
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.
- 3.15Newest branch, released Oct 9, 2026
- 3.11Oldest supported branch, end of life Oct 2027
- 3.10End of life since Oct 1, 2026
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.
| Branch | Status | First release | End of life | Latest |
|---|---|---|---|---|
| 3.15 | Bugfix | Oct 9, 2026 | Oct 2031 | 3.15.2 |
| 3.14 | Bugfix | Oct 7, 2025 | Oct 2030 | 3.14.10 |
| 3.13 | Security | Oct 7, 2024 | Oct 2029 | 3.13.18 |
| 3.12 | Security | Oct 2, 2023 | Oct 2028 | 3.12.16 |
| 3.11 | Security | Oct 24, 2022 | Oct 2027 | 3.11.18 |
| 3.10 | End of life | Oct 4, 2021 | Oct 1, 2026 | 3.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
| System | Default python3 | Other versions |
|---|---|---|
| Debian 13 (trixie) | 3.13 | |
| Debian 12 (bookworm) | 3.11 | |
| Ubuntu 26.04 LTS | 3.14 | |
| Ubuntu 24.04 LTS | 3.12 | |
| Ubuntu 22.04 LTS | 3.10 | |
| RHEL 10 | 3.12 | 3.14 stream to May 2029 |
| RHEL 9 | 3.9 | 3.12 to Apr 2027, 3.14 to May 2029 |
| RHEL 8 | 3.6 | 3.12 |
| FreeBSD ports | 3.12 | other 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
- Python security advisories: the security-announce mailing list (subscribe) and the PSF advisory database on GitHub, in OSV format.
- Release notes for each version on python.org/downloads list the CVEs fixed.
- For distro packages, use your distribution's tracker, such as the Debian tracker. See Security advisories.
Hardening tips
- Run each app as its own unprivileged user, never as root.
- Pin dependencies with hashes and install with
pip install --require-hashes -r requirements.txt. - Run pip-audit in CI and weekly on production venvs.
- Never expose a framework's debug mode or development server to the internet; put a real web server in front.
- Keep pip, setuptools and wheel up to date inside each venv.
- Remove venvs and interpreters you no longer use; old copies stay vulnerable.
- Extract archives only with
tarfile'sfilter="data"and on a patched interpreter.
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
- Status of Python versions, Python Developer's Guide
- Download Python, python.org
- Python 3.15.2, python.org
- Python 3.12.16, python.org
- Python security, python.org
- pip-audit, PyPI
- pip-audit README, PyPA on GitHub
- RHEL Application Streams Release Life Cycle, Red Hat
- python3 package search, Debian
- python3 package search, Ubuntu
- python3.13, Debian Security Tracker
- lang/python, FreshPorts