Une faille vieille de 28 ans vient de refaire surface, cette fois dans l’une des bibliothèques cryptographiques les plus utilisées de l’écosystème Python. Le 3 août 2026, le projet pyca/cryptography a publié un avis de sécurité pour CVE-2026-69247, un oracle de type Bleichenbacher logé dans les fonctions de déchiffrement PKCS#7. Le correctif est sorti dans la version 50.0.0, mais l’écart entre les scores de gravité attribués (8,2 chez GitHub, 5,9 chez Red Hat) illustre à quel point cette classe d’attaque reste difficile à évaluer. Voici ce que révèlent les avis techniques, pourquoi cette faille rappelle une attaque de 1998 contre SSL, et ce que les équipes qui déchiffrent des messages S/MIME ou des enveloppes CMS doivent vérifier dès maintenant.
CVE-2026-69247 en bref : ce que dit l’avis officiel
La bibliothèque cryptography pour Python, maintenue par le projet pyca (Python Cryptographic Authority), sert de brique de base à une bonne partie de l’écosystème Python moderne : elle expose des primitives RSA, AES, ECC et, depuis plusieurs versions, un support de PKCS#7/CMS pour signer et déchiffrer des messages. C’est précisément dans ce module que loge la faille. Entre la version 44.0.0 et la version 49.x, trois fonctions, pkcs7_decrypt_der, pkcs7_decrypt_pem et pkcs7_decrypt_smime, renvoyaient des résultats distincts selon l’issue du déchiffrement RSA d’une clé de session encapsulée dans un objet RecipientInfo.
Selon la fiche publiée sur le National Vulnerability Database (NVD), l’une de ces issues distinctes révélait la longueur exacte récupérée lors de l’opération RSA, une autre était observable par simple mesure du temps de réponse. Deux canaux d’information suffisent, en théorie, à reconstituer un oracle de padding exploitable. L’identifiant GitHub associé est GHSA-g6cj-pr64-35w5, référencé côté PyPI sous PYSEC-2026-3552. Le correctif, disponible depuis la version 50.0.0, ferme les trois fonctions concernées en uniformisant leur comportement d’échec.
Un oracle de padding, 28 ans après l’attaque originale de Bleichenbacher
Le nom “Bleichenbacher” renvoie à un chercheur suisse, Daniel Bleichenbacher, qui a démontré en 1998 une faille dans le padding PKCS#1 v1.5 utilisé par RSA au sein de SSL. Le principe reste d’une simplicité redoutable. Un serveur qui déchiffre une clé de session RSA distingue, dans ses réponses ou ses temps de traitement, si le texte chiffré reçu respecte un format valide ou non. Un attaquant qui envoie des milliers de textes chiffrés légèrement modifiés, puis observe ces micro-différences, peut reconstruire petit à petit la clé de session sans jamais casser RSA lui-même.
Cette classe d’attaque n’a jamais vraiment disparu. Elle a refait surface en 2017 sous le nom de ROBOT (Return Of Bleichenbacher’s Oracle Threat), touchant plusieurs grands équipementiers réseau, puis régulièrement dans des implémentations TLS ou des bibliothèques cryptographiques isolées, y compris dans libgcrypt via CVE-2024-2236, une variante RSA déjà documentée sur shattered.io. CVE-2026-69247 en est la dernière incarnation, cette fois hors du protocole TLS lui-même : elle vise le format PKCS#7/CMS utilisé pour chiffrer des messages électroniques au format S/MIME, ainsi que d’autres flux applicatifs qui encapsulent une clé de session RSA.
Le parallèle est direct mais le contexte diffère. En 1998, la cible était un serveur TLS qui négociait une session chiffrée en direct. En 2026, la cible type est une passerelle de messagerie ou un filtre anti-spam qui déchiffre automatiquement des pièces jointes S/MIME envoyées par n’importe quel expéditeur, sans jamais authentifier la source au préalable.
Comment l’attaque fonctionne concrètement contre PKCS#7
Pour qu’un attaquant puisse réellement exploiter CVE-2026-69247, plusieurs conditions doivent se cumuler, et c’est précisément ce point qui explique l’écart entre les scores de gravité. D’après l’avis Red Hat, le service ciblé doit accepter et déchiffrer automatiquement des messages PKCS#7/CMS non authentifiés, viser un certificat RSA précis appartenant à la victime, exposer des résultats ou des délais distinguables entre les cas d’erreur, et tolérer un volume élevé de requêtes répétées pour permettre une attaque adaptative.
Une cinquième condition, plus technique, change tout : la bibliothèque cryptographique de bas niveau sur laquelle s’appuie cryptography doit elle-même manquer d’une protection appelée “rejet implicite” (implicit rejection). L’avis du NVD cite nommément OpenSSL 3.0, OpenSSL 3.1, LibreSSL et BoringSSL comme moteurs concernés par cette absence de protection dans certains chemins de code. Le rejet implicite consiste à toujours renvoyer un résultat de déchiffrement, valide ou non, de façon strictement indistinguable, plutôt que de signaler explicitement un échec. Sans cette protection en amont, la couche Python de cryptography ne pouvait pas totalement compenser le problème avant la version 50.0.0.
Le NIST NVD résume l’impact de façon directe : “An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key”. Autrement dit, la faille ne condamne pas toute utilisation de la bibliothèque, elle condamne un motif de conception précis : déchiffrer sans filtrer, puis renvoyer un signal exploitable.
Chronologie de la divulgation, d’août à septembre 2026
La séquence de publication mérite d’être détaillée car elle explique pourquoi cette faille grimpe seulement maintenant dans les radars de sécurité, un mois et demi après sa sortie initiale. L’avis GitHub Security Advisory et l’entrée OSV.dev sont apparus le 3 août 2026 à 21h17 UTC, au moment de la sortie de cryptography 50.0.0. Red Hat a ouvert son propre dossier de suivi le 8 septembre 2026, avant de le mettre à jour le 23 septembre. Le NVD, de son côté, a publié sa dernière mise à jour le 17 septembre 2026 à 01h15. Fedora a livré ses correctifs pour les paquets python-cryptography et pyOpenSSL dès le 28 août 2026.
Ce décalage d’un mois et demi entre la sortie du correctif et sa remontée dans les tableaux de bord de vulnérabilités des grandes entreprises est courant pour les failles de bibliothèques largement utilisées mais peu spectaculaires. Sans preuve d’exploitation active, sans inscription au catalogue Known Exploited Vulnerabilities de la CISA, et sans preuve de concept publique à ce jour, CVE-2026-69247 se classe dans la catégorie des correctifs “à appliquer lors du prochain cycle de mise à jour” plutôt que des urgences absolues. C’est justement ce classement qui inquiète certains analystes : les oracles de padding ont souvent été exploités des années après leur découverte, une fois que des chercheurs ont industrialisé les outils d’attaque adaptative.
Pourquoi le score CVSS varie de 5,9 à 8,2 selon la source
La divergence de notation entre GitHub et Red Hat n’est pas une anomalie, elle traduit deux lectures différentes du même scénario d’attaque. Le score CVSS 4.0 de 8,2 (Élevé) calculé par GitHub, sous le vecteur CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N, part du principe qu’un oracle accessible à distance peut, dans l’absolu, causer un impact élevé sur la confidentialité, même si les conditions d’exploitation sont exigeantes. Le score CVSS 3.1 de 5,9 (Modéré) retenu par Red Hat pondère davantage la difficulté pratique : il faut un service de déchiffrement adapté, un volume de requêtes important, et un comportement défavorable du moteur cryptographique sous-jacent.
Un troisième agrégateur de vulnérabilités classe même la faille à 7,5, sans préciser de vecteur détaillé, ce qui illustre le manque de consensus qui entoure les failles à exploitation conditionnelle. Pour les équipes de sécurité qui priorisent leurs correctifs sur la base d’un score unique, ce type d’écart pose un vrai problème méthodologique. Faut-il patcher en urgence une faille notée 8,2, ou la traiter comme une tâche de routine notée 5,9 ?
Tableau 1 : CVE-2026-69247 en un coup d’œil
| Champ | Valeur |
|---|---|
| Identifiant CVE | CVE-2026-69247 |
| Identifiants associés | GHSA-g6cj-pr64-35w5, PYSEC-2026-3552 |
| Bibliothèque affectée | cryptography (pyca) pour Python |
| Versions vulnérables | 44.0.0 à 49.x |
| Version corrigée | 50.0.0 |
| Fonctions concernées | pkcs7_decrypt_der, pkcs7_decrypt_pem, pkcs7_decrypt_smime |
| CVSS 4.0 (GitHub / OSV) | 8,2 – Élevé |
| CVSS 3.1 (Red Hat) | 5,9 – Modéré |
| Publication initiale (GHSA/OSV) | 3 août 2026 |
| Dernière mise à jour NVD | 17 septembre 2026 |
| Correctifs distribution | Fedora 44 (python-cryptography, pyOpenSSL), 28 août 2026 |
| Exploit public connu | Non recensé à ce jour |
Qui utilise pyca/cryptography, et qui est réellement exposé
La bibliothèque cryptography figure parmi les dépendances les plus installées de l’écosystème Python. Elle sert de socle à des projets aussi variés que des clients HTTP sécurisés, des outils d’automatisation d’infrastructure ou des passerelles de messagerie. Cette large diffusion crée un réflexe naturel, mais dangereux : assimiler “la bibliothèque est installée” à “l’application est vulnérable”. Ce n’est pas le cas ici. Le chemin de code concerné ne s’active que lorsqu’une application appelle explicitement l’une des trois fonctions de déchiffrement PKCS#7 sur un contenu dont elle ne contrôle pas la provenance.
Le NVD cite comme exemple typique les passerelles S/MIME et les filtres anti-spam qui déchiffrent automatiquement des messages chiffrés entrants avant de les analyser. C’est un cas d’usage réel dans les grandes organisations qui appliquent des politiques de chiffrement de bout en bout pour leurs échanges par e-mail, notamment dans les secteurs bancaire, juridique et gouvernemental où le S/MIME reste plus répandu que dans le grand public. À l’inverse, les recherches disponibles n’établissent aucun lien confirmé entre cette faille précise et des projets comme Paramiko, Requests ou Django, qui dépendent de cryptography sans nécessairement invoquer ces fonctions de déchiffrement PKCS#7 sur des données non fiables.
Le distributeur Linux Fedora a confirmé le risque au niveau paquet en publiant des mises à jour pour python-cryptography et pyOpenSSL dès le 28 août 2026, ce qui suggère que le mainteneur de la distribution a jugé le correctif suffisamment important pour un déploiement rapide, indépendamment du niveau de gravité final retenu par chaque agrégateur.
Le correctif technique : rejet implicite et clé aléatoire de secours
La contre-mesure appliquée dans la version 50.0.0 suit un principe éprouvé, documenté depuis la RFC 3218 publiée en 2002 en réaction directe à l’attaque originale de Bleichenbacher. Plutôt que de signaler un échec de déchiffrement PKCS#7, la bibliothèque substitue désormais une clé aléatoire lorsque le déchiffrement RSA échoue ou produit un format invalide. Le traitement se poursuit alors avec cette clé factice jusqu’à son terme, sans jamais révéler à l’attaquant si l’opération a réellement réussi ou échoué.
Le changelog du projet crédite un contributeur identifié sous le pseudonyme @X1AOxiang pour le signalement de la faille. Le correctif a été fusionné via la pull request #15369, avec pour commit de référence 53fccd93413a8d7f07d6d8999681f27b75cffa3f. Pour les équipes qui gèrent leurs dépendances Python, la remédiation tient en quelques lignes :
python -m pip install --upgrade "cryptography>=50.0.0"
# Vérifier la version actuellement installée :
python -c "import cryptography; print(cryptography.__version__)"
# Auditer les appels directs aux fonctions concernées :
grep -R "pkcs7_decrypt_" --include="*.py" .Au-delà de la simple mise à jour, les équipes doivent aussi vérifier si leur application journalise ou renvoie des messages d’erreur détaillés lors d’un échec de déchiffrement PKCS#7, un comportement qui pourrait recréer un oracle même après la mise à jour de la bibliothèque, si le code applicatif propage lui-même une information distinguable.
Tableau 2 : les oracles de type Bleichenbacher à travers les décennies
| Année | Cible | Nom / identifiant | Nature de l’impact |
|---|---|---|---|
| 1998 | Serveurs SSL (RSA PKCS#1 v1.5) | Attaque Bleichenbacher originale | Déchiffrement adaptatif d’une session SSL via un oracle de padding |
| 2017 | Implémentations TLS de plusieurs équipementiers réseau | ROBOT (Return Of Bleichenbacher’s Oracle Threat) | Retour de l’oracle de padding, une décennie après les premiers correctifs TLS |
| 2024 | Libgcrypt (bibliothèque utilisée par GnuPG) | CVE-2024-2236 | Oracle temporel sur le déchiffrement RSA, corrigé tardivement par les distributions Linux |
| 2026 | pyca/cryptography (Python), format PKCS#7/CMS | CVE-2026-69247 | Oracle exploitable via les fonctions de déchiffrement PKCS#7 EnvelopedData |
Ce tableau illustre une réalité que les équipes de sécurité connaissent bien : les oracles de padding ne sont jamais définitivement éradiqués. Chaque nouvelle implémentation d’un protocole basé sur RSA PKCS#1 v1.5, qu’il s’agisse de TLS, de S/MIME ou d’un format propriétaire, recrée le même risque si les développeurs ne connaissent pas l’historique de cette classe d’attaque. Le fait qu’une bibliothèque aussi mature et auditée que cryptography ait pu réintroduire ce défaut en 2026, 28 ans après sa découverte initiale, confirme que la vigilance ne peut pas reposer uniquement sur la réputation d’un projet.
Comparaison avec les autres failles cryptographiques Python récentes
CVE-2026-69247 n’est pas la première alerte de l’année à viser une bibliothèque cryptographique de l’écosystème Python. En parallèle, le paquet python-jose a fait l’objet de CVE-2026-85394, une faille de confusion d’algorithme HMAC notée CVSS 9,1 qui, contrairement au cas présent, permettait de forger directement des jetons JWT sans clé privée. La comparaison est instructive. Là où python-jose exposait une faille de conception immédiate et facilement automatisable, CVE-2026-69247 demande un scénario d’attaque bien plus élaboré, avec des requêtes adaptatives répétées contre un service spécifique.
Cette différence de complexité d’exploitation explique en partie pourquoi une faille notée 9,1 a suscité une réaction immédiate de la communauté, tandis que celle-ci, plafonnée à 8,2 dans le pire des cas, progresse plus lentement dans les priorités de correction des entreprises. Les deux failles partagent toutefois un point commun frappant : elles touchent des bibliothèques considérées comme des références de sécurité, largement auditées, ce qui rappelle qu’aucun projet, même mature, n’est à l’abri d’un défaut de conception hérité.
Impact pour la France et l’Europe
À la date du 27 septembre 2026, ni l’ANSSI ni le CERT-FR n’ont publié d’avis désignant nommément CVE-2026-69247 dans leurs bulletins. Ce silence institutionnel ne signifie pas absence de risque, il reflète plutôt le fonctionnement habituel de la veille française, qui priorise les failles à exploitation active ou à fort impact sur les infrastructures critiques. Les organisations françaises qui utilisent le S/MIME pour leurs échanges chiffrés, notamment dans les secteurs bancaire et administratif où cette norme reste répandue, ont donc intérêt à traiter cette mise à jour de manière proactive plutôt que d’attendre une alerte officielle.
Le contexte réglementaire européen ajoute une pression supplémentaire. Le règlement européen sur la cyber-résilience (Cyber Resilience Act), déjà couvert sur shattered.io, impose désormais un signalement rapide des vulnérabilités critiques touchant des composants numériques commercialisés dans l’Union. Une bibliothèque aussi largement intégrée que cryptography entre potentiellement dans le périmètre de nombreux produits soumis à ces obligations, ce qui renforce l’intérêt d’un traitement rapide plutôt que d’une correction différée au prochain cycle de maintenance.
Ce que révèle cette faille sur l’audit des bibliothèques cryptographiques
Le cas de CVE-2026-69247 pose une question de fond dépassant le simple correctif : comment un défaut aussi bien documenté, connu depuis 1998, a-t-il pu se glisser dans une implémentation PKCS#7 ajoutée récemment à une bibliothèque de référence ? La réponse tient probablement à la nature même des extensions de fonctionnalités. Le support PKCS#7/CMS a été ajouté à cryptography pour répondre à une demande précise, celle de signer et déchiffrer des messages S/MIME, un cas d’usage plus rare que le chiffrement TLS classique et donc moins soumis à l’attention constante de la communauté de recherche en sécurité.
Les fonctions les plus anciennes et les plus utilisées d’une bibliothèque, comme le support RSA-OAEP ou AES-GCM dans cryptography, bénéficient d’un examen cumulatif de plusieurs années par des dizaines de chercheurs indépendants. Les extensions plus récentes, même intégrées avec soin, n’ont pas encore traversé ce même filtre collectif. C’est un rappel utile pour toute équipe qui évalue le risque d’une dépendance : la maturité globale d’un projet ne garantit pas la maturité de chacun de ses modules.
Checklist de remédiation pour les équipes techniques
- Vérifier la version installée de
cryptographydans tous les environnements de production, y compris les images de conteneurs figées. - Mettre à jour vers la version 50.0.0 ou ultérieure dès que possible, en priorité sur les services qui déchiffrent des messages S/MIME ou CMS non authentifiés.
- Auditer le code applicatif pour repérer tout appel direct à
pkcs7_decrypt_der,pkcs7_decrypt_pemoupkcs7_decrypt_smime. - Vérifier que les messages d’erreur retournés par l’application ne recréent pas un canal d’information distinguable après la mise à jour de la bibliothèque.
- Contrôler la version du moteur cryptographique sous-jacent (OpenSSL, LibreSSL, BoringSSL) et privilégier les versions qui implémentent le rejet implicite RSA.
- Documenter la correction dans le registre de vulnérabilités interne, notamment pour les organisations soumises au Cyber Resilience Act ou à NIS2.
Prédictions : ce qui pourrait suivre cette divulgation
Plusieurs évolutions semblent probables dans les mois qui suivent cette publication. D’abord, il est vraisemblable que d’autres bibliothèques cryptographiques passent au crible leurs propres implémentations PKCS#7 et CMS, un domaine moins audité que le cœur des protocoles TLS. Ensuite, le nombre de CVE liées à des oracles de padding devrait continuer d’augmenter à mesure que les chercheurs réexaminent du code hérité écrit avant que le rejet implicite ne devienne une pratique standard.
Les grands fournisseurs cloud devraient aussi accélérer la diffusion de cryptography 50.0.0 dans leurs images de base et leurs environnements managés, une pratique désormais courante après chaque CVE touchant une dépendance aussi répandue. Le manque d’avis dédié de l’ANSSI ou du CERT-FR sur cette faille pourrait par ailleurs alimenter le débat sur les délais de signalement prévus par l’Article 14 du Cyber Resilience Act, qui impose un cadre de notification resserré pour les vulnérabilités cryptographiques critiques. Enfin, les organisations qui exploitent encore des passerelles S/MIME historiques pourraient profiter de cet épisode pour réévaluer leur architecture de messagerie chiffrée, en particulier celles qui envisagent déjà une transition vers des algorithmes post-quantiques.
Foire aux questions
Qu’est-ce que CVE-2026-69247 exactement ?
Il s’agit d’un oracle de type Bleichenbacher dans les fonctions de déchiffrement PKCS#7 de la bibliothèque Python cryptography, qui permettait de distinguer certains résultats de déchiffrement RSA par leur contenu ou par leur temps de réponse.
Mon application Python est-elle automatiquement vulnérable si j’utilise cryptography ?
Non. La faille ne s’active que si votre code appelle explicitement pkcs7_decrypt_der, pkcs7_decrypt_pem ou pkcs7_decrypt_smime sur des données dont vous ne contrôlez pas la provenance, comme un message S/MIME entrant.
Comment savoir si j’utilise une version affectée ?
Exécutez python -c "import cryptography; print(cryptography.__version__)". Toute version comprise entre 44.0.0 et 49.x est concernée. La version 50.0.0 et les suivantes intègrent le correctif.
Pourquoi le score CVSS varie-t-il entre 5,9 et 8,2 selon la source ?
GitHub applique le référentiel CVSS 4.0 en supposant un impact élevé sur la confidentialité si l’oracle est atteint, tandis que Red Hat, sous CVSS 3.1, pondère davantage la difficulté pratique d’exploitation, ce qui abaisse le score final.
Existe-t-il un exploit public pour cette faille ?
Non, à la date du 27 septembre 2026, aucune preuve de concept publique n’a été recensée, et la faille n’apparaît pas au catalogue Known Exploited Vulnerabilities de la CISA.
Cette faille touche-t-elle aussi TLS ?
Non directement. Elle concerne le format PKCS#7/CMS, utilisé notamment pour le chiffrement de messages S/MIME, pas les échanges de clés TLS eux-mêmes. Le principe de l’oracle est identique à celui qui touche parfois TLS, mais le protocole visé ici est différent.
Que doit faire une équipe qui déchiffre des messages S/MIME en production ?
Mettre à jour vers cryptography 50.0.0 en priorité, vérifier qu’aucun message d’erreur applicatif ne recrée un canal distinguable, et contrôler la version du moteur OpenSSL ou équivalent utilisé en arrière-plan.
Qui a découvert la faille ?
Le changelog du projet pyca/cryptography crédite un contributeur identifié sous le pseudonyme @X1AOxiang pour le signalement initial.
