Python 3.14 is not just another feature release — it quietly rewrites how CPython itself is secured. Release artifacts are now verified exclusively with Sigstore (PGP signatures are gone, per PEP 761). tarfile finally extracts with filter="data" by default. Free-threaded CPython — the build without the GIL — is officially supported. And HMAC now falls back to formally verified code from the HACL* project when OpenSSL is unavailable.
At the same time, 2026 has kept the CPython security team busy: the June 10, 2026 maintenance release (3.14.6 and 3.13.14) shipped nine security fixes, from a bundled libexpat update (CVE-2026-45186) to control-character injection in http.cookies (CVE-2026-3644). This guide covers everything a security-conscious Python team needs to know before — and after — migrating to 3.13 or 3.14.
The June 2026 Security Release: What 3.14.6 & 3.13.14 Fixed
On June 10, 2026, the CPython team shipped Python 3.14.6 and Python 3.13.14. The 3.14.6 release bundled nine security fixes — one of the larger batches in a single maintenance release. If your production images still run an earlier patch level, this is your reason to rebuild:
| Fix | Component | What it addresses |
|---|---|---|
| CVE-2026-45186 | bundled libexpat | libexpat updated to 2.8.1 — XML parsing vulnerabilities inherited by xml.parsers.expat |
| CVE-2026-4224 | xml.parsers.expat | Additional expat-layer parsing issue fixed in the stdlib binding itself |
| CVE-2026-3644 | http.cookies | Control characters accepted in cookie values — header-injection style abuse |
| CVE-2026-2297 | importlib SourcelessFileLoader | Issue when loading sourceless (.pyc-only) files |
| CVE-2026-3219 | bundled pip | Bundled pip upgraded to 26.1, closing a pip-level vulnerability shipped with ensurepip |
| bz2 fix | bz2 module | Possible stack buffer overflow when a BZ2Decompressor is reused after a decompression error |
The takeaway is structural, not just tactical: a large share of CPython security fixes in 2026 come from bundled third-party code — libexpat, pip, OpenSSL. Your Python runtime has its own supply chain, and patch-level upgrades (3.14.5 → 3.14.6) are how you consume it. Teams that pin python:3.14 Docker tags without rebuilding regularly miss exactly these fixes.
tarfile: Safe by Default — and the CVE That Broke the Filter
For two decades, tarfile.extractall() on untrusted archives was one of Python's most famous footguns: absolute paths, ../ traversal and symlink tricks could write files anywhere on disk. PEP 706 introduced extraction filters, and Python 3.14 finally makes filter="data" the default — blocking absolute paths, parent-directory escapes, and symlinks pointing outside the destination. Python 3.14 also hardened data_filter() to normalize symbolic link targets, closing another path-traversal angle.
But 2025-2026 proved that even the safety net needs patching. CVE-2025-4517 showed that extractall(filter="data") could be bypassed entirely:
PATH_MAX (4096 bytes on Linux), os.path.realpath(strict=False) silently stops resolving symlinks and falls back to string manipulation. A crafted symlink chain can convince the filter that a link resolves inside the extraction directory while it actually escapes to / — arbitrary filesystem write. Affects Python ≥ 3.12 (earlier versions have no filters at all). Fixed in 3.12.11, 3.13.4 and 3.14.0b1.
# Extracting untrusted archives in 2026 — do this
import tarfile
with tarfile.open("untrusted.tar.gz") as tf:
# Python 3.14: filter="data" is already the default.
# Python 3.12 / 3.13: pass it explicitly — and make sure
# you run ≥ 3.12.11 / 3.13.4 (CVE-2025-4517 fix).
tf.extractall(path="dest/", filter="data")
The lesson generalizes: defense layers are code too, and code has bugs. If your service extracts user-supplied archives, combine the filter with an unprivileged process, a dedicated extraction directory, and a patched interpreter — not the filter alone.
Free-Threaded CPython: What "No GIL" Means for Security
Python 3.13 shipped free-threading as an experiment; Python 3.14 makes the free-threaded build officially supported (PEP 703 implementation completed). Performance is now viable: the single-threaded penalty dropped from ~40% in 3.13 to roughly 5–10%, with multi-threaded CPU workloads seeing speedups around 3× on common hardware. Adoption in 2026 is real — which makes the security implications worth spelling out.
1. Race conditions stop being theoretical
The GIL never guaranteed thread safety, but in practice it made many races so narrow they never fired. Without it, time-of-check/time-of-use bugs, double-frees in native code, and state-corruption races become practically exploitable. Code that "worked for years" under the GIL may harbor latent logic races — including in security-sensitive paths like authentication caches, rate limiters, and session stores built on global mutable state.
# Classic pattern that is NOT safe without explicit locking
_token_cache = {} # global mutable state
def get_token(user_id):
if user_id not in _token_cache: # check
_token_cache[user_id] = mint_token() # act — another thread
return _token_cache[user_id] # may interleave here
# Free-threaded-safe version
import threading
_lock = threading.Lock()
def get_token_safe(user_id):
with _lock:
if user_id not in _token_cache:
_token_cache[user_id] = mint_token()
return _token_cache[user_id]
2. What CPython does protect
Built-in types (dict, list, set) use internal per-object locks, and pure-Python code is guaranteed to be at least as crash-safe as with the GIL — the interpreter itself will not corrupt memory running multithreaded pure Python. The guarantee is about interpreter integrity, not about your invariants: compound operations (check-then-set, read-modify-write) still need locks, queues, or immutable data.
3. C extensions are the real risk surface
Many C extensions were written assuming the GIL implicitly serialized access. Running them free-threaded can cause crashes and data corruption — which in native code means memory-safety territory. CPython's mitigation: if an imported extension is not explicitly marked free-thread-safe, the interpreter re-enables the GIL for the lifetime of the process. Audit this in production — a single legacy extension silently converts your "parallel" deployment back to GIL semantics, or worse, an extension incorrectly marked safe becomes your next crash-dump investigation.
PYTHON_GIL=0 and thread-stress tests (the py-free-threading community guide documents patterns), inventory C extensions for free-threading support, and keep security-critical services on the default build until your dependency tree is verified.
Sigstore Replaces PGP: Verifying Python Itself (PEP 761)
Starting with Python 3.14, CPython release artifacts are signed and verified exclusively with Sigstore. PEP 761 formally deprecated PGP signatures: no .asc files are published for 3.14+. The rationale is the one security practitioners have argued for years — PGP requires trusted parties to protect long-lived private keys, while Sigstore uses short-lived keys bound to human-readable identities via OpenID Connect, with signatures logged in a public transparency log.
# Verifying a CPython 3.14 release artifact in CI
python -m pip install sigstore
python -m sigstore verify identity \
--cert-identity thomas@python.org \
--cert-oidc-issuer https://accounts.google.com \
Python-3.14.6.tgz
# SHA-256 checksums also remain available on python.org
# for teams doing hash-based verification.
If your build pipeline (Docker base images, pyenv-style source builds, air-gapped mirrors) still verifies Python downloads with GPG keys, it silently stopped verifying anything at 3.14. Update the pipeline to sigstore verify or SHA-256 checksum pinning. For automation this is genuinely better: no key imports, no trust-store maintenance, no expiring signatures.
The Quieter Hardening Wins in 3.14
- Formally verified HMAC. Python 3.14 ships a built-in HMAC implementation with formally verified code from the HACL* project, used as fallback when OpenSSL's implementation is unavailable — shrinking the space of unverified crypto code paths in the stdlib.
- Hardened compiler defaults. CPython is now built with a set of recommended security compiler options enabled by default, hardening the interpreter binary itself against memory-corruption exploitation.
- Safer XML parsing. The bundled libexpat continues to track upstream security releases (2.8.1 as of 3.14.6) — but remember that
xml.etreeand friends are still not designed for hostile input; usedefusedxmlat trust boundaries.
Migration Checklist for Security-Conscious Teams
- Get off EOL math first. Python 3.9 is past end-of-life and 3.10 is in its final security-only year — CVEs fixed in 3.13/3.14 are frequently not evaluated against EOL branches at all.
- Target 3.13.14+ or 3.14.6+. Both contain the June 2026 security batch. For 3.12, ensure ≥ 3.12.11 for the tarfile CVE-2025-4517 fix.
- Audit every
tarfile/shutil.unpack_archivecall site. On 3.12/3.13, passfilter="data"explicitly. Test that nothing in your codebase relies on extraction behaviors the data filter now blocks. - Fix your release-verification pipeline. Replace GPG verification of python.org artifacts with Sigstore or SHA-256 checks.
- Stay on the default (GIL) build for security-critical services until your C-extension tree is verified free-thread-safe; treat free-threading rollout as a security review, not just a performance project.
- Rebuild containers on every patch release. The 3.14.6 batch (libexpat, pip, http.cookies, bz2) only reaches production if images are rebuilt.
- Monitor your dependencies continuously. Interpreter upgrades fix the runtime — but 2026's dominant Python threat is the package supply chain (see our PyPI Shai-Hulud & Hades analysis). Pair a patched interpreter with daily lockfile scanning.
requirements.txt, poetry.lock and Pipfile.lock daily against OSV.dev — including advisories that affect specific Python interpreter versions and stdlib backport status. When the next CPython security release lands, you'll know which of your projects are running affected patch levels. See Python Vulnerability Monitoring.
Frequently Asked Questions
Is Python 3.14 more secure than 3.13?
Yes, structurally. Python 3.14 makes tarfile extraction filters the default, ships a formally verified HMAC fallback (HACL*), builds the interpreter with hardened compiler options, and moves release verification to Sigstore. Python 3.13 receives security backports until October 2029, so it remains a safe choice — but 3.14's safer defaults mean fewer footguns for new code.
Does CVE-2025-4517 still affect current Python versions?
No, if you're patched. The tarfile filter="data" bypass via the os.path.realpath() PATH_MAX fallback was fixed in Python 3.12.11, 3.13.4 and 3.14.0b1. It only affected Python 3.12+, since earlier versions had no extraction filters. Any 3.13.14 or 3.14.6 deployment is safe — but note that on 3.12/3.13 the filter is still not the default, so you must pass it explicitly.
Is free-threaded Python safe to use in production in 2026?
The build is officially supported in 3.14 and the interpreter itself is stable — CPython guarantees pure-Python code won't crash the interpreter. The risk is your code and your C extensions: race conditions that the GIL masked become real, and extensions not marked free-thread-safe either re-enable the GIL or, if mislabeled, risk memory corruption. Run thread-stress testing before deploying it in security-sensitive services.
How do I verify Python downloads now that PGP signatures are gone?
For Python 3.14 and later, use Sigstore: python -m sigstore verify identity --cert-identity <release-manager>@python.org --cert-oidc-issuer https://accounts.google.com Python-3.14.6.tgz. Release-manager identities are documented on python.org's Sigstore page. SHA-256 checksums also remain published for hash-based verification. Releases older than 3.14 still include legacy PGP signatures.
What was fixed in Python 3.14.6?
The June 10, 2026 release contained nine security fixes, including: bundled libexpat updated to 2.8.1 (CVE-2026-45186), an xml.parsers.expat fix (CVE-2026-4224), control-character handling in http.cookies (CVE-2026-3644), a SourcelessFileLoader issue (CVE-2026-2297), bundled pip upgraded to 26.1 (CVE-2026-3219), and a stack buffer overflow in bz2 when reusing a decompressor after an error.
Does upgrading Python protect me from PyPI supply chain attacks?
No. Interpreter upgrades fix runtime and stdlib vulnerabilities, but 2026's dominant Python threat — malicious packages (Shai-Hulud waves, the Hades campaign's .pth hooks) — executes as legitimate code on any interpreter version. You need both: a patched interpreter and continuous dependency monitoring with tools like pip-audit and CVE OptiBot.
Monitor your Python dependencies automatically
CVE OptiBot scans your requirements.txt, poetry.lock and Pipfile.lock daily against OSV.dev and alerts you when a CVE affects your stack — including stdlib and interpreter-level advisories.
Python 3.14 n’est pas une simple version de plus — elle réécrit discrètement la façon dont CPython lui-même est sécurisé. Les artefacts de release sont désormais vérifiés exclusivement avec Sigstore (les signatures PGP ont disparu, cf. PEP 761). tarfile extrait enfin avec filter="data" par défaut. Le CPython free-threaded — le build sans GIL — est officiellement supporté. Et HMAC s’appuie désormais sur du code formellement vérifié du projet HACL* quand OpenSSL n’est pas disponible.
En parallèle, 2026 a bien occupé l’équipe sécurité de CPython : la release de maintenance du 10 juin 2026 (3.14.6 et 3.13.14) a livré neuf correctifs de sécurité, de la mise à jour de libexpat embarqué (CVE-2026-45186) à l’injection de caractères de contrôle dans http.cookies (CVE-2026-3644). Ce guide couvre tout ce qu’une équipe Python soucieuse de sécurité doit savoir avant — et après — la migration vers 3.13 ou 3.14.
La release de sécurité de juin 2026 : ce que corrigent 3.14.6 & 3.13.14
Le 10 juin 2026, l’équipe CPython a publié Python 3.14.6 et Python 3.13.14. La 3.14.6 embarque neuf correctifs de sécurité — l’un des lots les plus fournis pour une seule release de maintenance. Si vos images de production tournent encore sur un patch level antérieur, voici pourquoi rebuilder :
| Correctif | Composant | Ce qu’il corrige |
|---|---|---|
| CVE-2026-45186 | libexpat embarqué | libexpat mis à jour en 2.8.1 — vulnérabilités de parsing XML héritées par xml.parsers.expat |
| CVE-2026-4224 | xml.parsers.expat | Problème de parsing supplémentaire corrigé dans le binding stdlib lui-même |
| CVE-2026-3644 | http.cookies | Caractères de contrôle acceptés dans les valeurs de cookies — abus de type injection d’en-têtes |
| CVE-2026-2297 | importlib SourcelessFileLoader | Problème au chargement de fichiers sans source (.pyc uniquement) |
| CVE-2026-3219 | pip embarqué | pip embarqué mis à niveau vers 26.1, corrigeant une vulnérabilité livrée avec ensurepip |
| Correctif bz2 | module bz2 | Possible débordement de buffer de pile quand un BZ2Decompressor est réutilisé après une erreur de décompression |
La leçon est structurelle, pas seulement tactique : une grande partie des correctifs de sécurité CPython en 2026 provient de code tiers embarqué — libexpat, pip, OpenSSL. Votre runtime Python a sa propre supply chain, et les mises à jour de patch level (3.14.5 → 3.14.6) sont votre moyen de la consommer. Les équipes qui épinglent des tags Docker python:3.14 sans rebuilder régulièrement ratent exactement ces correctifs.
tarfile : sécurisé par défaut — et la CVE qui a cassé le filtre
Pendant vingt ans, tarfile.extractall() sur des archives non fiables a été l’un des pièges les plus célèbres de Python : chemins absolus, traversal ../ et symlinks pouvaient écrire des fichiers n’importe où sur le disque. Le PEP 706 a introduit les filtres d’extraction, et Python 3.14 fait enfin de filter="data" le défaut — bloquant chemins absolus, échappées vers le répertoire parent et symlinks pointant hors de la destination. Python 3.14 a aussi durci data_filter() pour normaliser les cibles de liens symboliques, fermant un angle de path traversal supplémentaire.
Mais 2025-2026 a prouvé que même le filet de sécurité doit être patché. CVE-2025-4517 a montré que extractall(filter="data") pouvait être entièrement contourné :
PATH_MAX (4096 octets sous Linux), os.path.realpath(strict=False) arrête silencieusement de résoudre les symlinks et retombe sur de la manipulation de chaînes. Une chaîne de symlinks préparée peut convaincre le filtre qu’un lien résout à l’intérieur du répertoire d’extraction alors qu’il s’échappe vers / — écriture arbitraire sur le système de fichiers. Affecte Python ≥ 3.12 (les versions antérieures n’ont pas de filtres du tout). Corrigé dans 3.12.11, 3.13.4 et 3.14.0b1.
# Extraire des archives non fiables en 2026 — faites ceci
import tarfile
with tarfile.open("untrusted.tar.gz") as tf:
# Python 3.14 : filter="data" est deja le defaut.
# Python 3.12 / 3.13 : passez-le explicitement — et verifiez
# que vous tournez en >= 3.12.11 / 3.13.4 (fix CVE-2025-4517).
tf.extractall(path="dest/", filter="data")
La leçon se généralise : les couches de défense sont du code, et le code a des bugs. Si votre service extrait des archives fournies par les utilisateurs, combinez le filtre avec un processus non privilégié, un répertoire d’extraction dédié et un interpréteur patché — pas le filtre seul.
CPython free-threaded : ce que « sans GIL » signifie pour la sécurité
Python 3.13 a livré le free-threading en expérimental ; Python 3.14 rend le build free-threaded officiellement supporté (implémentation du PEP 703 achevée). Les performances sont désormais viables : la pénalité mono-thread est passée d’environ 40 % en 3.13 à 5–10 %, avec des accélérations autour de 3× sur les charges CPU multi-threadées. L’adoption en 2026 est réelle — d’où l’importance d’expliciter les implications sécurité.
1. Les race conditions cessent d’être théoriques
Le GIL n’a jamais garanti la thread safety, mais en pratique il rendait beaucoup de races si étroites qu’elles ne se déclenchaient jamais. Sans lui, les bugs time-of-check/time-of-use, les double-free en code natif et les corruptions d’état deviennent exploitables en pratique. Du code qui « marchait depuis des années » sous le GIL peut cacher des races latentes — y compris dans des chemins sensibles comme les caches d’authentification, les rate limiters et les stores de session basés sur de l’état global mutable.
# Motif classique NON sur sans verrouillage explicite
_token_cache = {} # etat global mutable
def get_token(user_id):
if user_id not in _token_cache: # check
_token_cache[user_id] = mint_token() # act — un autre thread
return _token_cache[user_id] # peut s'intercaler ici
# Version safe en free-threading
import threading
_lock = threading.Lock()
def get_token_safe(user_id):
with _lock:
if user_id not in _token_cache:
_token_cache[user_id] = mint_token()
return _token_cache[user_id]
2. Ce que CPython protège réellement
Les types built-in (dict, list, set) utilisent des verrous internes par objet, et le code Python pur est garanti au moins aussi robuste aux crashs qu’avec le GIL — l’interpréteur lui-même ne corrompra pas la mémoire en exécutant du Python pur multithreadé. La garantie porte sur l’intégrité de l’interpréteur, pas sur vos invariants : les opérations composées (check-then-set, read-modify-write) nécessitent toujours verrous, queues ou données immuables.
3. Les extensions C sont la vraie surface de risque
Beaucoup d’extensions C ont été écrites en supposant que le GIL sérialisait implicitement les accès. Les exécuter en free-threaded peut provoquer crashs et corruption de données — ce qui en code natif relève de la memory safety. La mitigation de CPython : si une extension importée n’est pas explicitement marquée free-thread-safe, l’interpréteur réactive le GIL pour toute la durée du processus. Auditez cela en production — une seule extension legacy reconvertit silencieusement votre déploiement « parallèle » en sémantique GIL, ou pire, une extension incorrectement marquée safe devient votre prochaine investigation de crash-dump.
PYTHON_GIL=0 et des tests de stress multi-thread (le guide communautaire py-free-threading documente les patterns), inventoriez le support free-threading de vos extensions C, et gardez les services critiques sur le build par défaut tant que l’arbre de dépendances n’est pas vérifié.
Sigstore remplace PGP : vérifier Python lui-même (PEP 761)
À partir de Python 3.14, les artefacts de release CPython sont signés et vérifiés exclusivement avec Sigstore. Le PEP 761 a formellement déprécié les signatures PGP : aucun fichier .asc n’est publié pour 3.14+. La raison est celle que les praticiens de la sécurité avancent depuis des années — PGP exige que des tiers de confiance protègent des clés privées à longue durée de vie, tandis que Sigstore utilise des clés éphémères liées à des identités lisibles via OpenID Connect, avec des signatures inscrites dans un journal de transparence public.
# Verifier un artefact de release CPython 3.14 en CI
python -m pip install sigstore
python -m sigstore verify identity \
--cert-identity thomas@python.org \
--cert-oidc-issuer https://accounts.google.com \
Python-3.14.6.tgz
# Les checksums SHA-256 restent aussi disponibles sur python.org
# pour les equipes preferant la verification par hash.
Si votre pipeline de build (images Docker de base, builds source type pyenv, miroirs air-gapped) vérifie encore les téléchargements Python avec des clés GPG, il a silencieusement cessé de vérifier quoi que ce soit à partir de 3.14. Mettez-le à jour vers sigstore verify ou l’épinglage de checksums SHA-256. Pour l’automatisation, c’est objectivement mieux : pas de clés à importer, pas de trust store à maintenir, pas de signatures qui expirent.
Les gains de durcissement plus discrets de 3.14
- HMAC formellement vérifié. Python 3.14 embarque une implémentation HMAC intégrée avec du code formellement vérifié du projet HACL*, utilisée en fallback quand l’implémentation OpenSSL n’est pas disponible — réduisant l’espace de code crypto non vérifié dans la stdlib.
- Options de compilation durcies par défaut. CPython est désormais compilé avec un ensemble d’options de sécurité recommandées activées par défaut, durcissant le binaire de l’interpréteur contre l’exploitation de corruptions mémoire.
- Parsing XML plus sûr. Le libexpat embarqué suit les releases de sécurité upstream (2.8.1 en 3.14.6) — mais rappelez-vous que
xml.etreeet consorts ne sont toujours pas conçus pour des entrées hostiles ; utilisezdefusedxmlaux frontières de confiance.
Checklist de migration pour équipes soucieuses de sécurité
- Sortez d’abord des versions EOL. Python 3.9 est en fin de vie et 3.10 entame sa dernière année security-only — les CVE corrigées en 3.13/3.14 ne sont souvent même pas évaluées sur les branches EOL.
- Ciblez 3.13.14+ ou 3.14.6+. Les deux contiennent le lot de sécurité de juin 2026. Pour 3.12, assurez-vous d’être en ≥ 3.12.11 pour le fix tarfile CVE-2025-4517.
- Auditez chaque appel à
tarfile/shutil.unpack_archive. Sur 3.12/3.13, passezfilter="data"explicitement. Testez que rien dans votre code ne dépend de comportements d’extraction que le filtre data bloque désormais. - Corrigez votre pipeline de vérification de releases. Remplacez la vérification GPG des artefacts python.org par Sigstore ou des checks SHA-256.
- Restez sur le build par défaut (GIL) pour les services critiques tant que votre arbre d’extensions C n’est pas vérifié free-thread-safe ; traitez le déploiement du free-threading comme une revue de sécurité, pas seulement un projet de performance.
- Rebuildez vos conteneurs à chaque patch release. Le lot 3.14.6 (libexpat, pip, http.cookies, bz2) n’atteint la production que si les images sont reconstruites.
- Surveillez vos dépendances en continu. Les mises à jour d’interpréteur corrigent le runtime — mais la menace Python dominante de 2026 est la supply chain des paquets (voir notre analyse Shai-Hulud & Hades PyPI). Combinez interpréteur patché et scan quotidien des lockfiles.
requirements.txt, poetry.lock et Pipfile.lock chaque jour contre OSV.dev — y compris les advisories touchant des versions spécifiques de l’interpréteur Python. Quand la prochaine release de sécurité CPython sortira, vous saurez quels projets tournent sur des patch levels affectés. Voir le monitoring des vulnérabilités Python.
Questions fréquentes
Python 3.14 est-il plus sécurisé que 3.13 ?
Oui, structurellement. Python 3.14 rend les filtres d’extraction tarfile par défaut, embarque un fallback HMAC formellement vérifié (HACL*), compile l’interpréteur avec des options durcies, et bascule la vérification des releases sur Sigstore. Python 3.13 reçoit des backports de sécurité jusqu’en octobre 2029, il reste donc un choix sûr — mais les défauts plus sûrs de 3.14 signifient moins de pièges pour le nouveau code.
CVE-2025-4517 affecte-t-elle encore les versions actuelles de Python ?
Non, si vous êtes patché. Le bypass du filtre tarfile filter="data" via le fallback PATH_MAX de os.path.realpath() a été corrigé dans Python 3.12.11, 3.13.4 et 3.14.0b1. Seuls Python 3.12+ étaient affectés, les versions antérieures n’ayant pas de filtres d’extraction. Tout déploiement 3.13.14 ou 3.14.6 est sûr — mais notez qu’en 3.12/3.13 le filtre n’est toujours pas le défaut : il faut le passer explicitement.
Le Python free-threaded est-il sûr en production en 2026 ?
Le build est officiellement supporté en 3.14 et l’interpréteur lui-même est stable — CPython garantit que du code Python pur ne fera pas crasher l’interpréteur. Le risque, c’est votre code et vos extensions C : les race conditions que le GIL masquait deviennent réelles, et les extensions non marquées free-thread-safe soit réactivent le GIL, soit, si elles sont mal étiquetées, risquent la corruption mémoire. Faites du stress testing multi-thread avant de le déployer sur des services sensibles.
Comment vérifier les téléchargements Python maintenant que les signatures PGP ont disparu ?
Pour Python 3.14 et suivants, utilisez Sigstore : python -m sigstore verify identity --cert-identity <release-manager>@python.org --cert-oidc-issuer https://accounts.google.com Python-3.14.6.tgz. Les identités des release managers sont documentées sur la page Sigstore de python.org. Les checksums SHA-256 restent publiés pour la vérification par hash. Les releases antérieures à 3.14 incluent encore des signatures PGP legacy.
Qu’est-ce qui a été corrigé dans Python 3.14.6 ?
La release du 10 juin 2026 contenait neuf correctifs de sécurité, dont : libexpat embarqué mis à jour en 2.8.1 (CVE-2026-45186), un fix xml.parsers.expat (CVE-2026-4224), la gestion des caractères de contrôle dans http.cookies (CVE-2026-3644), un problème SourcelessFileLoader (CVE-2026-2297), pip embarqué mis à niveau vers 26.1 (CVE-2026-3219), et un débordement de buffer de pile dans bz2 lors de la réutilisation d’un décompresseur après erreur.
Mettre à jour Python me protège-t-il des attaques supply chain PyPI ?
Non. Les mises à jour de l’interpréteur corrigent les vulnérabilités du runtime et de la stdlib, mais la menace Python dominante de 2026 — les paquets malveillants (vagues Shai-Hulud, hooks .pth de la campagne Hades) — s’exécute comme du code légitime sur n’importe quelle version. Il faut les deux : un interpréteur patché et un monitoring continu des dépendances avec pip-audit et CVE OptiBot.
Surveillez vos dépendances Python automatiquement
CVE OptiBot scanne vos requirements.txt, poetry.lock et Pipfile.lock chaque jour contre OSV.dev et vous alerte quand une CVE touche votre stack — y compris les advisories stdlib et interpréteur.