Le 27 août 2026, un chercheur en sécurité a découvert que le paquet Python openssl-encrypt, téléchargé depuis PyPI et présenté comme une solution de chiffrement de fichiers sécurisé, ne chiffrait en réalité rien du tout dans l’une de ses fonctionnalités phares. Référencée CVE-2026-81681, la faille touche toutes les versions jusqu’à la 1.4.8 incluse. Son “Encrypted USB Workspace” annonçait du AES-256-GCM, dérivait bien une clé, affichait un marqueur “chiffré”, et laissait pourtant les fichiers de l’utilisateur en clair sur la clé USB. L’entrée a été mise à jour le 11 septembre 2026, la veille de la publication de cet article.
L’affaire dépasse le cadre d’un bug isolé. Elle relance un débat que l’écosystème open source traîne depuis des années : combien de bibliothèques cryptographiques distribuées gratuitement sur PyPI, npm ou crates.io tiennent réellement leurs promesses de sécurité ? Et que se passe-t-il quand personne, pas même les mainteneurs, ne s’en aperçoit pendant des mois ?
CVE-2026-81681 : anatomie d’un chiffrement qui n’a jamais eu lieu
Le paquet openssl-encrypt, maintenu par un développeur connu sous le pseudonyme “Tobi” sur un dépôt GitHub (jahlives/openssl_encrypt), se présente comme un outil de chiffrement de fichiers basé sur des primitives modernes, avec dérivation de clé par hachage répété pour renforcer un mot de passe utilisateur. Le paquet compte 54 versions publiées sur PyPI depuis sa création, un signe d’une maintenance active et régulière, ce qui rend la découverte d’autant plus troublante.
Sa fonctionnalité “Encrypted USB Workspace” visait un usage précis : transformer une clé USB en espace de travail portable protégé, pour transporter des documents sensibles entre un poste professionnel et un poste personnel, ou entre deux sites. Le principe annoncé était simple. L’utilisateur définit un mot de passe, le logiciel dérive une clé via une fonction de dérivation, puis chiffre le contenu du répertoire avec AES-256-GCM, un mode de chiffrement authentifié réputé solide et largement déployé, notamment dans TLS 1.3.
Le problème identifié par les chercheurs est que cette dernière étape ne se produisait jamais. Le code dérivait bien la clé, écrivait un marqueur dans le répertoire pour signaler qu’il était “chiffré”, mais n’appliquait cette clé à aucun fichier. Concrètement, un attaquant qui met la main sur la clé USB, employé qui la perd, vol dans un train, contrôle douanier, accède à l’intégralité des données en clair, sans avoir besoin de casser quoi que ce soit. Pas de brute force, pas de cryptanalyse, juste un répertoire ouvert derrière une étiquette trompeuse.
Ce type de défaut porte un nom dans la communauté sécurité : le “security theater”, ou théâtre de sécurité. Le logiciel produit tous les signaux visuels et fonctionnels d’une protection, interface de saisie de mot de passe, calcul visible de clé, marqueur de statut, sans produire l’effet recherché. Pour l’utilisateur final, rien ne distingue un espace réellement chiffré d’un espace qui ne l’est pas, jusqu’au jour où les données fuitent.
Chronologie de la divulgation
La faille a été publiée dans la base OpenCVE le 27 août 2026, sous l’identifiant CVE-2026-81681. Ce délai de moins de trois semaines avant notre publication du 12 septembre 2026 en fait un dossier encore chaud, et l’entrée continue d’évoluer : sa dernière mise à jour date du 11 septembre, avec des précisions sur les versions affectées et les correctifs disponibles. Le mainteneur a depuis publié une version 1.4.9, corrigeant le défaut en appliquant réellement le chiffrement au répertoire de travail.
Pour resituer le contexte technique, il faut rappeler que 2026 a déjà été une année chargée en incidents touchant des implémentations de TLS 1.3 et de primitives cryptographiques dans des bibliothèques largement utilisées. En avril, une faille dans Go (CVE-2026-32283) permettait de paralyser des connexions TLS 1.3 via des messages de mise à jour de clé répétés, provoquant l’émission de 45 avis de sécurité distincts chez les éditeurs qui embarquent le langage. En parallèle, Botan (CVE-2026-34582) laissait passer des données d’application avant la fin complète du handshake, et s2n-tls, la bibliothèque TLS maintenue par AWS, souffrait d’un déni de service (CVE-2026-16317) permettant à un attaquant en position d’intercepteur de supprimer silencieusement des enregistrements chiffrés. WolfSSL n’a pas été épargné non plus, avec un use-after-free (CVE-2026-5460, CVSS 6,5) dans son traitement hybride post-quantique.
CVE-2026-81681 se distingue de cette liste par sa nature. Les failles TLS listées ci-dessus sont des erreurs d’implémentation dans du code qui, sur le principe, tente honnêtement de chiffrer. Le cas openssl-encrypt est différent : le chiffrement promis n’existe simplement pas dans le chemin de code concerné. C’est une régression fonctionnelle qui n’a, semble-t-il, jamais été couverte par un test vérifiant que les octets écrits sur le disque diffèrent effectivement des octets en clair.
| Bibliothèque / paquet | CVE | Type de défaut | Score CVSS | Date de divulgation |
|---|---|---|---|---|
| openssl-encrypt (PyPI) | CVE-2026-81681 | Chiffrement AES-256-GCM jamais appliqué (données en clair) | Non communiqué | 27 août 2026 |
| Go crypto/tls | CVE-2026-32283 | Déni de service via messages de mise à jour de clé TLS 1.3 | Non communiqué | 7 avril 2026 |
| Botan (C++) | CVE-2026-34582 | Traitement de données avant fin du handshake TLS 1.3 | Non communiqué | 7 avril 2026 |
| s2n-tls (AWS) | CVE-2026-16317 | Suppression silencieuse d’enregistrements chiffrés | Non communiqué | 21 juillet 2026 |
| wolfSSL | CVE-2026-5460 | Use-after-free dans le KeyShare hybride post-quantique | 6,5 | 10 avril 2026 |
| Linux kernel TLS | CVE-2026-74611 | Restauration incorrecte de l’itérateur de messages TLS 1.3 | Non communiqué | 22 août 2026 |
Pourquoi les paquets de chiffrement Python restent un angle mort
PyPI héberge des dizaines de milliers de paquets liés de près ou de loin à la cryptographie, du simple wrapper autour d’OpenSSL jusqu’à des implémentations maison de primitives. Contrairement aux bibliothèques de référence comme PyCA cryptography ou PyNaCl, qui bénéficient d’audits réguliers, de mainteneurs institutionnels et d’une visibilité importante, la majorité de ces paquets sont maintenus par une poignée de développeurs bénévoles, parfois une seule personne, sans revue de code externe systématique.
Ce déséquilibre crée un terrain favorable aux régressions silencieuses. Un paquet peut fonctionner correctement à sa création, puis voir une fonctionnalité se dégrader au fil des refontes internes sans que personne ne le remarque, faute de tests qui vérifient le résultat cryptographique produit plutôt que la simple absence d’erreur d’exécution. Le code peut tourner sans planter, générer une clé, écrire un fichier, et pourtant ne rien chiffrer. C’est exactement le scénario documenté dans CVE-2026-81681.
Le risque est amplifié par la manière dont ces paquets sont intégrés en aval. Une entreprise qui construit un outil de sauvegarde ou de partage de fichiers “sécurisé” pour ses équipes peut très bien s’appuyer sur une dépendance comme openssl-encrypt sans jamais auditer son code source, en faisant confiance à la description du paquet et à son nombre de versions publiées. Le nom même du paquet, qui évoque OpenSSL, projette une crédibilité que le code ne garantit pas forcément, alors qu’il s’agit d’un projet tiers indépendant du projet OpenSSL officiel.
Pour les équipes de sécurité en entreprise, la leçon pratique est directe : un paquet qui revendique du chiffrement doit être vérifié empiriquement, en inspectant les octets produits, et pas seulement audité sur la lecture de sa documentation. Un simple test consistant à comparer la taille et l’entropie du fichier “chiffré” avec le fichier source aurait suffi à révéler le problème bien plus tôt.
Impact sur le marché et la confiance dans les outils open source
L’impact direct sur le marché reste, à ce stade, difficile à chiffrer précisément : aucune volumétrie officielle de téléchargements ni de liste d’entreprises clientes n’a été publiée par les chercheurs ou par le mainteneur. Ce que l’on peut affirmer, à partir des informations publiques disponibles sur PyPI, c’est que le paquet a connu 54 versions depuis sa création, un rythme de publication qui suggère une base d’utilisateurs suffisante pour justifier une maintenance continue plutôt qu’un projet abandonné.
L’impact indirect, lui, est plus facile à cerner. Chaque incident de ce type nourrit une défiance croissante envers les dépendances tierces dans les chaînes d’approvisionnement logicielles, un sujet déjà sensible après plusieurs vagues d’attaques par empoisonnement de paquets sur npm et PyPI ces dernières années. Les responsables sécurité en entreprise, en particulier dans les secteurs réglementés (santé, finance, administration), sont de plus en plus nombreux à exiger un inventaire logiciel complet, ou SBOM, incluant une vérification fonctionnelle des composants cryptographiques, et pas seulement une liste de versions et de CVE connues.
Ce climat s’inscrit aussi dans une pression réglementaire européenne plus large. Le Cyber Resilience Act (CRA), dont les premières obligations entrent progressivement en vigueur d’ici 2027, impose aux fabricants de produits comportant des éléments numériques de démontrer la sécurité de leurs dépendances logicielles, y compris open source, tout au long du cycle de vie du produit. Un défaut comme celui d’openssl-encrypt, s’il était intégré dans un produit commercial vendu en Europe, tomberait potentiellement sous le coup de ces nouvelles obligations de transparence et de correction.
Le contexte européen autour de la cryptographie robuste s’est également durci ces dernières semaines. Le 5 septembre 2026, un rapport a relayé un avertissement du G7 sur la menace posée par l’informatique quantique aux algorithmes actuels, avec une politique portée par la Commission européenne qui impose à tous les États membres d’entamer leur transition vers des algorithmes résistants au quantique avant fin 2026, et aux systèmes à haut risque de migrer avant 2030. L’ANSSI, agence française de cybersécurité, pilote ce groupe de travail du G7 et a lancé un appel pressant aux secteurs public et privé pour accélérer cette transition. Dans ce climat où l’Europe pousse activement vers une cryptographie plus fiable et vérifiable, la découverte d’un outil qui simule un chiffrement AES-256 sans jamais l’appliquer tombe à un moment particulièrement inopportun pour la crédibilité de l’écosystème open source.
AES-256-GCM, l’algorithme qui sert aussi bien la défense que l’attaque
L’ironie de ce dossier ne s’arrête pas au paquet Python. Une note de recherche publiée le 23 août 2026 par un laboratoire affilié à la Cloud Security Alliance a documenté une technique baptisée “cryptographic context injection”. Elle consiste à chiffrer des instructions malveillantes avec un algorithme fort, précisément AES-256-GCM combiné à une dérivation de clé par PBKDF2, pour que les filtres de contenu statiques placés en amont d’un modèle d’intelligence artificielle ne puissent pas les lire avant qu’elles n’atteignent le modèle cible.
Cette technique illustre une tension intéressante. Le même algorithme, AES-256-GCM, sert d’un côté d’argument marketing dans un outil de protection des données qui ne l’applique jamais (openssl-encrypt), et de l’autre d’outil offensif sophistiqué pour contourner des systèmes de sécurité, publiée quatre jours seulement avant la divulgation de CVE-2026-81681. La cryptographie forte reste un instrument neutre : sa valeur dépend entièrement de la rigueur de son implémentation et du contexte dans lequel elle est déployée.
Pour les équipes qui évaluent des dépendances de chiffrement, ce double usage renforce un principe de base : la présence du nom d’un algorithme réputé solide, AES-256, RSA, ChaCha20, dans la documentation d’un outil ne dit rien sur la qualité de son implémentation réelle. Seul un audit du code, ou à défaut des tests de vérification empirique du résultat produit, permet de trancher.
Comparatif : implémentation correcte face au cas openssl-encrypt
Pour comprendre ce qui distingue une implémentation correcte de chiffrement authentifié du comportement défaillant observé dans openssl-encrypt, il est utile de comparer les deux chemins d’exécution, attendu et réel, étape par étape.
| Étape du processus | Comportement attendu (AES-256-GCM correct) | Comportement observé dans openssl-encrypt ≤ 1.4.8 |
|---|---|---|
| Saisie du mot de passe | Le mot de passe est demandé à l’utilisateur | Identique, aucune anomalie |
| Dérivation de clé | Une clé est dérivée du mot de passe via une fonction de dérivation | Clé bien dérivée, comportement conforme |
| Chiffrement du contenu | Chaque fichier du répertoire est chiffré avec la clé dérivée | Le chiffrement n’est jamais appliqué au répertoire de travail |
| Marqueur de statut | Le marqueur reflète l’état réel du chiffrement | Le marqueur affiche “chiffré” alors que les données sont en clair |
| Lecture par un tiers non autorisé | Impossible sans la clé, données illisibles | Lecture directe possible, données en clair sur le support |
| Correction disponible | Non applicable | Corrigé en version 1.4.9, chiffrement réellement appliqué |
Contexte historique : les précédents de chiffrement fantôme
Ce n’est pas la première fois qu’un outil grand public ou professionnel promet un chiffrement qu’il n’applique pas correctement. L’histoire de la sécurité informatique compte plusieurs affaires similaires, où la faille ne résidait pas dans la robustesse mathématique de l’algorithme choisi, mais dans son intégration défaillante. Des applications de messagerie ont par le passé été épinglées pour du chiffrement de bout en bout mal implémenté, où les clés de session restaient accessibles côté serveur malgré les promesses marketing. Des logiciels de sauvegarde cloud ont également été mis en cause pour stocker des clés de déchiffrement à côté des données chiffrées elles-mêmes, annulant l’intérêt même du chiffrement.
Le point commun de ces affaires, et celui d’openssl-encrypt, est l’absence de vérification indépendante avant une adoption large. Contrairement aux algorithmes eux-mêmes, qui font l’objet de processus de standardisation rigoureux pilotés par des organismes comme le NIST, les implémentations logicielles qui les mettent en œuvre échappent souvent à tout contrôle formel, en particulier dans l’écosystème open source où la barrière à l’entrée pour publier un paquet reste très basse.
Historiquement, ce type d’incident a souvent servi de déclencheur à des initiatives de durcissement collectif : audits financés par des fondations, programmes de bug bounty ciblés sur les dépendances critiques, ou intégration de vérifications automatiques dans les pipelines CI/CD des grands éditeurs. Le Cyber Resilience Act européen, en formalisant des obligations de sécurité pour les composants logiciels intégrés dans des produits commerciaux, s’inscrit dans cette même logique de réponse structurelle plutôt que ponctuelle.
Réaction du mainteneur et correctif disponible
Le mainteneur du paquet a réagi en publiant une nouvelle version, la 1.4.9, disponible sur PyPI, qui corrige le défaut en appliquant réellement le chiffrement AES-256-GCM au répertoire de travail avant l’écriture du marqueur de statut. Le dépôt GitHub du projet reste actif, avec une documentation associée à chaque branche de version, un signe encourageant pour la suite du projet.
Reste que la correction d’un défaut de ce type ne suffit pas à effacer le risque déjà couru par les utilisateurs des versions vulnérables. Toute donnée stockée dans un “Encrypted USB Workspace” créé avec une version antérieure ou égale à 1.4.8 doit être considérée comme ayant été exposée en clair, et non comme protégée, pendant toute la période où elle a résidé sur le support physique. La mise à jour du logiciel ne rechiffre pas rétroactivement les données déjà écrites : une migration manuelle vers la version corrigée, avec re-création complète de l’espace de travail, reste nécessaire pour toute donnée sensible déjà stockée.
Comment vérifier si un outil de chiffrement fait vraiment son travail
Face à ce type d’incident, plusieurs vérifications simples permettent de limiter le risque avant de déployer un outil de chiffrement tiers dans un contexte professionnel. La première consiste à comparer l’entropie du fichier produit avec celle du fichier source. Un fichier réellement chiffré avec AES-256-GCM doit présenter une distribution d’octets proche de l’aléatoire, alors qu’un fichier resté en clair conservera la structure et la lisibilité du contenu original.
La deuxième vérification porte sur la taille du fichier produit. Un chiffrement authentifié comme AES-256-GCM ajoute un tag d’authentification de taille fixe, généralement 16 octets, en plus du contenu chiffré. Un fichier de taille strictement identique au fichier source, sans cet ajout, doit immédiatement éveiller les soupçons.
Troisième réflexe, plus exigeant mais plus fiable : lire le code source du paquet, en particulier le chemin d’exécution qui va de la saisie du mot de passe à l’écriture du fichier final, pour vérifier que l’appel à la fonction de chiffrement porte bien sur les données de l’utilisateur, et non sur un tampon vide ou un objet de test laissé par erreur. Dans le cas d’openssl-encrypt, c’est précisément ce type d’inspection qui a permis de repérer que la clé dérivée n’était jamais transmise à l’opération de chiffrement du répertoire.
Enfin, pour les organisations qui gèrent un parc important de dépendances, l’intégration d’outils de scan de composition logicielle (SCA) capables de signaler les CVE connues au moment du build, combinée à une politique de mise à jour rapide des dépendances critiques, reste la meilleure défense contre ce type de régression silencieuse une fois qu’elle est documentée publiquement.
Ce que cela change pour les développeurs Python
Pour les développeurs qui intègrent des fonctionnalités de chiffrement dans leurs propres outils, l’affaire CVE-2026-81681 illustre l’importance de tests unitaires qui valident le résultat cryptographique et pas seulement l’absence d’exception. Un test qui se contente de vérifier que la fonction de chiffrement s’exécute sans erreur ne détecte jamais ce genre de régression. Un test qui vérifie que le fichier de sortie diffère du fichier d’entrée, que sa taille correspond à l’ajout attendu du tag d’authentification, et que le déchiffrement avec un mauvais mot de passe échoue bien, aurait détecté le problème dès son introduction dans le code.
Les bibliothèques de référence dans l’écosystème Python, comme cryptography (maintenue par la Python Cryptographic Authority) ou PyNaCl, appliquent ce type de tests de bout en bout de manière systématique, avec des vecteurs de test officiels fournis par les spécifications des algorithmes eux-mêmes. Ce niveau de rigueur a un coût en temps de développement, ce qui explique en partie pourquoi de nombreux paquets plus petits, développés par des équipes réduites ou des contributeurs individuels, n’atteignent pas ce standard.
La recommandation qui se dégage pour les équipes techniques est simple à formuler mais difficile à appliquer systématiquement : privilégier les bibliothèques cryptographiques largement auditées et maintenues par des organisations reconnues, plutôt que des paquets plus récents ou moins visibles, même si leur documentation semble complète et leur fréquence de publication rassurante.
Prévisions : ce qui pourrait suivre cet incident
Plusieurs évolutions semblent probables dans les mois qui suivent la divulgation de CVE-2026-81681.
- Une hausse des audits volontaires de paquets de chiffrement sur PyPI, portée par des chercheurs indépendants motivés par la visibilité qu’apporte la découverte d’une faille de ce type.
- Un renforcement des exigences de vérification dans les outils de scan de dépendances (SCA), qui pourraient intégrer des heuristiques ciblant spécifiquement les paquets revendiquant des fonctionnalités de chiffrement, au-delà de la simple détection de CVE déjà publiées.
- Une pression accrue sur les registres de paquets eux-mêmes, PyPI en tête, pour mieux signaler les projets liés à la sécurité et encourager, voire exiger, une forme de label pour les paquets ayant fait l’objet d’un audit externe.
- Une accélération des obligations issues du Cyber Resilience Act pour les éditeurs qui intègrent des dépendances open source dans des produits commerciaux vendus dans l’Union européenne, avec une attention particulière portée aux composants cryptographiques.
- Une multiplication des incidents similaires révélés au grand jour, non pas parce que ces défauts seraient nouveaux, mais parce que l’attention médiatique et réglementaire autour de la cryptographie post-quantique et de la robustesse des implémentations pousse davantage de chercheurs à auditer des paquets jusque-là ignorés.
Le rôle des registres de paquets dans la détection de ces failles
PyPI ne dispose pas aujourd’hui d’un mécanisme de vérification automatique du comportement cryptographique des paquets qu’il héberge. Le registre se contente de vérifier l’intégrité du paquet publié et l’identité du compte qui le publie, mais n’exécute aucune analyse du code source pour valider les affirmations de sécurité présentes dans la documentation. Cette limite structurelle n’est pas propre à PyPI, npm et crates.io fonctionnent selon des principes similaires.
Des initiatives existent pour combler ce vide, comme les programmes de financement d’audits portés par des fondations telles que l’Open Source Security Foundation (OpenSSF), qui priorise les dépendances les plus utilisées dans l’écosystème pour des revues de sécurité approfondies. Mais ces programmes fonctionnent par nature de manière sélective, en se concentrant sur les paquets les plus téléchargés, ce qui laisse de côté une longue traîne de bibliothèques plus confidentielles, potentiellement intégrées dans des produits de niche ou des outils internes d’entreprise, où le risque reste tout aussi réel mais bien moins visible.
openssl-encrypt, avec ses 54 versions publiées, n’est ni un paquet obscur ni un projet abandonné. Il illustre plutôt la zone grise où se trouve la majorité des dépendances cryptographiques open source : suffisamment utilisées pour représenter un risque réel, mais pas assez visibles pour bénéficier d’un audit systématique financé par un tiers.
Foire aux questions
Qu’est-ce que CVE-2026-81681 exactement ?
Il s’agit d’une faille dans le paquet Python openssl-encrypt (versions inférieures ou égales à 1.4.8) qui annonce un chiffrement AES-256-GCM pour sa fonctionnalité “Encrypted USB Workspace”, mais qui ne l’applique jamais réellement aux fichiers concernés, les laissant stockés en clair.
Mes données sont-elles en danger si j’ai utilisé ce paquet ?
Si vous avez utilisé une version antérieure ou égale à 1.4.8 pour créer un espace de travail chiffré, toutes les données qui y ont été stockées doivent être considérées comme non protégées et potentiellement lisibles par quiconque a eu accès au support physique.
Comment corriger le problème ?
Il faut mettre à jour vers la version 1.4.9 du paquet, qui applique réellement le chiffrement, puis recréer entièrement l’espace de travail à partir des données originales, plutôt que de simplement mettre à jour un espace déjà créé avec une version vulnérable.
AES-256-GCM lui-même est-il compromis par cette faille ?
Non. L’algorithme AES-256-GCM n’est absolument pas remis en cause par cet incident. Le défaut se situe uniquement dans l’implémentation du paquet openssl-encrypt, qui n’appelait jamais la fonction de chiffrement sur les données concernées.
Comment vérifier qu’un autre outil de chiffrement fonctionne correctement ?
Comparez la taille et l’entropie du fichier produit avec le fichier source. Un fichier réellement chiffré doit paraître aléatoire et inclure un tag d’authentification supplémentaire. Un fichier de taille identique au fichier source, lisible tel quel, indique une absence de chiffrement.
Ce type d’incident est-il fréquent dans l’écosystème open source ?
Les cas documentés publiquement restent rares, mais la structure de l’écosystème, avec des milliers de paquets maintenus par de petites équipes sans audit systématique, rend ce genre de régression silencieuse plausible bien au-delà de ce seul incident.
Le Cyber Resilience Act européen s’applique-t-il à ce genre de paquet ?
Le CRA cible en premier lieu les fabricants de produits commerciaux qui intègrent des composants logiciels, y compris open source. Un paquet comme openssl-encrypt n’est pas directement visé s’il est distribué gratuitement sans faire partie d’un produit commercial, mais toute entreprise qui l’intégrerait dans un produit vendu en Europe devrait démontrer sa conformité aux exigences de sécurité du texte.
Existe-t-il des alternatives plus fiables pour chiffrer des fichiers en Python ?
Les bibliothèques cryptography (Python Cryptographic Authority) et PyNaCl sont généralement recommandées pour leur maintenance active, leurs tests de conformité aux spécifications officielles des algorithmes et leur adoption large dans l’industrie, ce qui les expose à davantage de revues externes.
