Ubuntu vient de publier, le 1er septembre 2026, un correctif de sécurité pour Libgcrypt, la bibliothèque cryptographique qui sert de moteur RSA à GnuPG et à une bonne partie de l’écosystème OpenPGP. L’avis USN-8711-1 referme une faille identifiée sous CVE-2024-2236 : un canal auxiliaire temporel qui permet, dans certaines conditions, de monter une attaque de type Bleichenbacher contre du chiffrement RSA. Le correctif touche trois versions LTS d’Ubuntu (22.04, 24.04 et 26.04), et son calendrier, à quelques semaines de l’entrée en vigueur des obligations de signalement de vulnérabilités actives de l’UE, en dit long sur l’état de maintenance des briques cryptographiques historiques.
Ce n’est pas une découverte spectaculaire au sens d’un 0-day exploité massivement. C’est plutôt un rappel : les bibliothèques qui chiffrent le courrier électronique, les paquets Debian et une partie du trafic OpenPGP en Europe reposent encore sur du code C ancien, dont les protections contre les attaques temporelles doivent être révisées régulièrement. Voici ce que l’on sait, ce que ça change concrètement, et pourquoi cette affaire mérite plus qu’un simple apt upgrade.
CVE-2024-2236 : que dit exactement l’avis USN-8711-1
L’avis USN-8711-1, daté du 1er septembre 2026, décrit une faille temporelle (timing side-channel) dans l’implémentation RSA de Libgcrypt. Le texte de Canonical reprend la formulation standard employée par les autres éditeurs : un attaquant distant peut potentiellement initier une attaque de type Bleichenbacher, ce qui peut mener au déchiffrement de textes chiffrés RSA. La faille est enregistrée sous l’identifiant CVE-2024-2236 et est référencée sur la page officielle du CVE Program.
Trois versions d’Ubuntu LTS sont concernées, avec des paquets corrigés précis : libgcrypt20 1.9.4-3ubuntu3.3 pour Ubuntu 22.04 LTS, libgcrypt20 1.10.3-2ubuntu0.2 pour Ubuntu 24.04 LTS, et libgcrypt20 1.12.0-2ubuntu1.1 pour Ubuntu 26.04 LTS. Toute installation utilisant un numéro de build antérieur reste exposée jusqu’à la mise à jour. Le correctif touche deux fichiers du code source, cipher/rsa-common.c et src/const-time.h, avec pour instruction de ne plus accepter de bourrage PKCS#1.5 invalide lors du déchiffrement, un changement typique des corrections anti-oracle de bourrage.
Red Hat a publié sa propre fiche pour la même faille, avec une précision utile absente de l’avis Ubuntu : la vulnérabilité touche tous les modes de bourrage RSA pris en charge, à savoir PKCS#1 v1.5, RSA-OAEP et RSASVE. Selon la fiche CVE de Red Hat, un attaquant doit envoyer un grand nombre de messages d’essai pour parvenir à un déchiffrement réussi, ce qui limite l’exploitation aux scénarios où l’attaquant dispose d’un accès réseau soutenu au service visé. Le tracker de sécurité Debian classe de son côté plusieurs suites de la distribution (bullseye, bookworm, trixie, forky, sid) comme vulnérables à cette même référence.
Bleichenbacher, késako : la mécanique de l’attaque
Le nom Bleichenbacher revient dans quasiment toutes les fiches consacrées à CVE-2024-2236, et il vaut la peine de comprendre pourquoi. En 1998, le cryptographe Daniel Bleichenbacher a démontré qu’un serveur qui répond différemment selon que le bourrage PKCS#1 v1.5 d’un texte chiffré RSA est valide ou non fournit, sans le vouloir, un oracle. En envoyant des dizaines de milliers de messages légèrement modifiés et en observant les réponses (erreur, succès, ou simplement le temps de réponse), un attaquant reconstruit progressivement le texte en clair, sans jamais casser la clé RSA elle-même.
Le cas Libgcrypt de 2026 est une variante temporelle de ce principe : ce n’est pas un message d’erreur explicite qui fuit l’information, mais une différence de durée d’exécution selon que le bourrage est valide ou non. C’est exactement le type de défaut que les développeurs cherchent à éliminer en écrivant du code en temps constant, où chaque branche du programme s’exécute dans un délai identique, qu’elle traite un cas valide ou invalide. Le fichier src/const-time.h modifié par le correctif Ubuntu est précisément le module censé garantir ce temps constant.
Ce n’est pas non plus une première pour Libgcrypt. La bibliothèque a déjà connu une faille de canal auxiliaire par cache en 2017, référencée CVE-2017-7526, qui permettait la récupération complète d’une clé RSA-1024 en exploitant la méthode de fenêtre glissante gauche-droite utilisée pour l’exponentiation modulaire. Cette faille avait été corrigée dans la version 1.7.8 de Libgcrypt, avec des mises à jour parallèles chez Debian et Ubuntu à l’époque. Neuf ans plus tard, la même bibliothèque affronte un second défaut de timing sur la même primitive RSA, ce qui interroge sur la robustesse à long terme du code historique en C face aux attaques temporelles.
Pourquoi GnuPG et le courrier chiffré sont concernés
Libgcrypt n’est pas une bibliothèque anecdotique. C’est le moteur cryptographique historique de GnuPG, l’implémentation open source du standard OpenPGP utilisée pour signer des paquets logiciels, chiffrer des courriels et authentifier des releases dans une large partie de l’écosystème Linux. Quand GnuPG déchiffre un message OpenPGP contenant une clé de session enveloppée en RSA, c’est Libgcrypt qui exécute l’opération critique de déchiffrement RSA, exactement le point visé par CVE-2024-2236.
Dans la pratique, exploiter cette faille contre une simple boîte mail chiffrée reste difficile : l’attaque nécessite d’envoyer un très grand nombre de messages à un service qui utilise Libgcrypt comme oracle de déchiffrement, un scénario plus réaliste contre un serveur exposé en réseau (passerelle de chiffrement, serveur de clés, service d’authentification de paquets) que contre un client de messagerie qui déchiffre localement, hors ligne, sans répondre à des sollicitations distantes. C’est d’ailleurs cette nuance qui explique le score de sévérité mesuré plutôt que critique attribué à la faille.
Le score CVSS relevé par le projet Flatcar Linux dans son suivi de dépendances est de 5,9, soit une sévérité qualifiée de moyenne. Ce chiffre place CVE-2024-2236 nettement en dessous des failles critiques qui font la une, mais au-dessus du seuil où l’on peut se permettre d’ignorer un correctif, surtout pour une brique qui protège des clés privées RSA.
Le calendrier européen ajoute de la pression
La publication de ce correctif début septembre 2026 tombe à un moment particulier pour les opérateurs européens. Les obligations de signalement de vulnérabilités actives prévues par la réglementation européenne sur les produits comportant des éléments numériques doivent devenir pleinement applicables à l’automne 2026, avec des exigences de notification qui couvrent explicitement les bibliothèques cryptographiques comme Libgcrypt, OpenSSL ou GnuTLS. Un fabricant qui distribue un produit intégrant une bibliothèque vulnérable devra documenter et notifier ce type de faille, même quand elle n’est pas activement exploitée dans la nature.
Pour les équipes de sécurité françaises et européennes, cela signifie qu’un correctif comme USN-8711-1 ne peut plus être traité comme un simple ticket de maintenance de routine. Il doit être tracé, documenté, et intégré dans les registres de conformité qui accompagnent la nouvelle vague réglementaire. Les entités qui suivent les recommandations de l’ANSSI en matière de cryptographie ont d’ailleurs l’habitude de cette discipline : la faille CVE-2024-2236 s’ajoute à une liste déjà longue de vulnérabilités affectant des bibliothèques cryptographiques largement déployées, qui ont ponctué l’année 2026.
Une année chargée pour les bibliothèques cryptographiques
Libgcrypt n’est pas un cas isolé en 2026. Plusieurs bibliothèques de référence ont dû corriger des failles significatives ces derniers mois : OpenSSL a traité une vulnérabilité de déni de service avec un score CVSS de 7,5 touchant les déploiements QUIC, Go a publié 45 avis liés à une faille dans son module crypto/tls qui paralysait des connexions TLS 1.3, et Bouncy Castle a dû corriger un défaut dans son implémentation Argon2 capable de consommer jusqu’à un téraoctet de RAM sur certaines configurations. GnuTLS et wolfSSL ont pour leur part cumulé plusieurs CVE sur une période de sept semaines.
Ce qui distingue le cas Libgcrypt des autres, c’est la nature du défaut : ce n’est ni un problème de mémoire, ni une faute de logique protocolaire, mais une fuite d’information par le temps d’exécution, une classe d’attaque connue depuis les travaux fondateurs de Paul Kocher dans les années 1990 et qui continue, près de trente ans plus tard, à échapper à des audits de code pourtant réguliers. Cela illustre une réalité peu confortable pour les mainteneurs de bibliothèques cryptographiques historiques : écrire du code réellement en temps constant, sur toutes les architectures processeur et tous les compilateurs, reste un exercice qui échappe encore régulièrement aux meilleures équipes.
Comparatif des failles temporelles RSA marquantes
Pour situer CVE-2024-2236 dans son contexte historique, voici un comparatif des principales attaques par canal auxiliaire ayant touché des implémentations RSA largement déployées.
| Faille | Année de divulgation | Composant visé | Type de canal | Correctif |
|---|---|---|---|---|
| Attaque Bleichenbacher originale | 1998 | SSL/TLS, bourrage PKCS#1 v1.5 | Message d’erreur explicite | Retrait progressif du bourrage PKCS#1 v1.5 côté protocole |
| CVE-2017-7526 (Libgcrypt) | 2017 | Exponentiation RSA-1024 | Cache CPU (fenêtre glissante) | Libgcrypt 1.7.8 |
| ROBOT | 2017 | Serveurs TLS multiples (F5, Citrix…) | Oracle de bourrage réseau | Correctifs éditeurs multiples |
| Marvin Attack | 2023 | Implémentations RSA-OAEP/PKCS#1 | Timing réseau fin | Correctifs échelonnés selon bibliothèques |
| CVE-2024-2236 (Libgcrypt) | Divulguée 2024, corrigée par Ubuntu en sept. 2026 | Déchiffrement RSA (PKCS#1 v1.5, OAEP, RSASVE) | Timing d’exécution local/réseau | Libgcrypt via USN-8711-1 (1.9.4-3ubuntu3.3, 1.10.3-2ubuntu0.2, 1.12.0-2ubuntu1.1) |
Ce tableau montre une continuité troublante : depuis 1998, la même famille d’attaques contre le bourrage RSA revient régulièrement, sous des formes de plus en plus subtiles. Le passage d’un simple message d’erreur (1998) à un canal purement temporel local (2026) montre que les défenseurs ont progressé, mais que la surface d’attaque ne s’est jamais totalement refermée.
Versions et paquets concernés : le détail technique
Pour les administrateurs système qui doivent auditer leur parc, voici le détail des versions Ubuntu concernées et leurs correctifs respectifs, tel que publié dans l’avis officiel.
| Version Ubuntu | Paquet | Version corrigée | Statut avant correctif |
|---|---|---|---|
| Ubuntu 26.04 LTS (Resolute) | libgcrypt20 | 1.12.0-2ubuntu1.1 | Vulnérable sur les builds antérieurs |
| Ubuntu 24.04 LTS (Noble) | libgcrypt20 | 1.10.3-2ubuntu0.2 | Vulnérable sur les builds antérieurs |
| Ubuntu 22.04 LTS (Jammy) | libgcrypt20 | 1.9.4-3ubuntu3.3 | Vulnérable sur les builds antérieurs |
| Debian (bullseye, bookworm, trixie, forky, sid) | libgcrypt20 | Suivi en cours via le tracker Debian | Classé vulnérable au moment de la rédaction |
| Red Hat Enterprise Linux | libgcrypt | Via avis CSAF RHSA associé | Documenté dans la fiche CVE Red Hat |
Le fait que Debian liste encore plusieurs suites comme vulnérables au moment de la publication de l’avis Ubuntu illustre un problème classique de l’écosystème open source : une faille corrigée en amont (upstream) ne se propage pas instantanément à toutes les distributions qui embarquent le même code. Chaque distribution doit backporter le correctif dans ses propres branches maintenues, un travail qui prend du temps et laisse des fenêtres d’exposition différentes selon l’OS utilisé.
Ce que les entreprises et administrations doivent vérifier
Pour une DSI ou une équipe sécurité, la première étape consiste à identifier où Libgcrypt est réellement utilisé dans le système d’information. La bibliothèque ne se limite pas à GnuPG : elle sert de moteur cryptographique à de nombreux paquets Linux qui déclarent une dépendance à libgcrypt20, y compris certains outils VPN, des gestionnaires de mots de passe en ligne de commande, et des composants de chiffrement de disque. Un simple apt list --installed | grep libgcrypt ou l’équivalent avec le gestionnaire de paquets de la distribution utilisée permet de vérifier la version installée.
Ensuite, la priorité doit aller aux services qui exposent une fonction de déchiffrement RSA à un client distant, potentiellement hostile : serveurs de clés OpenPGP publics, passerelles de chiffrement de courrier d’entreprise, ou services d’authentification qui valident des signatures ou déchiffrent des jetons RSA. Ce sont ces scénarios réseau qui rendent l’attaque de type Bleichenbacher réalisable, contrairement à un usage purement local et hors ligne de GnuPG sur un poste de travail.
Sur le plan de la conformité, les organismes soumis aux nouvelles obligations européennes de signalement des vulnérabilités actives devront documenter cette mise à jour dans leurs registres, même en l’absence d’exploitation confirmée dans la nature à ce jour. Les recommandations générales de l’ANSSI en matière de gestion des bibliothèques cryptographiques tierces s’appliquent pleinement ici : inventaire des dépendances, veille sur les avis CVE, et application rapide des correctifs de sécurité sur les composants cryptographiques.
Impact sur le marché des audits de code cryptographique
Cette succession de failles sur des bibliothèques cryptographiques matures (OpenSSL, Go crypto/tls, Bouncy Castle, GnuTLS, wolfSSL et maintenant Libgcrypt) alimente une tendance de fond déjà observée par les cabinets spécialisés dans l’audit de code cryptographique : la demande pour des revues manuelles ciblées sur les implémentations en temps constant progresse, à mesure que les grandes entreprises technologiques et les administrations réalisent que les tests automatisés classiques ne détectent pas ce type de fuite temporelle.
Les outils d’analyse dynamique dédiés à la détection de fuites temporelles, comme les frameworks qui mesurent statistiquement les variations de temps d’exécution sur des entrées contrôlées, gagnent également en popularité dans les pipelines d’intégration continue des projets cryptographiques critiques. Le fait qu’une bibliothèque aussi ancienne et aussi auditée que Libgcrypt ait laissé passer un second défaut de timing sur la même primitive RSA en moins de dix ans montre les limites des audits ponctuels face à un code qui évolue en permanence.
Contexte historique : trente ans de failles sur le bourrage RSA
L’histoire de RSA et de son bourrage PKCS#1 v1.5 est jalonnée d’incidents similaires depuis près de trente ans. L’attaque originale de Daniel Bleichenbacher en 1998 avait déjà forcé l’industrie à repenser la manière dont les serveurs TLS traitent les erreurs de déchiffrement. Près de vingt ans plus tard, l’attaque ROBOT (Return Of Bleichenbacher’s Oracle Threat) a montré en 2017 que la même classe de vulnérabilité restait présente chez plusieurs fournisseurs majeurs d’équipements réseau, dont F5 et Citrix. En 2023, l’attaque Marvin a de nouveau ciblé des implémentations RSA-OAEP et PKCS#1 avec des mesures de timing réseau particulièrement fines.
Ce fil rouge illustre une leçon simple mais difficile à appliquer en pratique : tant qu’un protocole ou une bibliothèque continue de prendre en charge le bourrage PKCS#1 v1.5, la porte reste entrouverte à une nouvelle variante de l’attaque de Bleichenbacher, qu’elle se manifeste par un message d’erreur, une différence de latence réseau, ou un canal purement temporel local comme dans le cas de CVE-2024-2236. C’est un argument de plus en faveur de la migration vers des schémas de chiffrement asymétrique plus modernes, y compris dans la perspective de la transition post-quantique déjà engagée par plusieurs bibliothèques cryptographiques majeures.
Comment corriger la faille dès aujourd’hui
La procédure de correction est directe pour les utilisateurs d’Ubuntu 22.04, 24.04 et 26.04 LTS : une mise à jour standard du gestionnaire de paquets applique automatiquement la version corrigée de libgcrypt20.
sudo apt update
sudo apt list --upgradable | grep libgcrypt20
sudo apt install --only-upgrade libgcrypt20
dpkg -l | grep libgcrypt20Pour les distributions Debian dont certaines suites restent classées vulnérables au moment de la rédaction, il convient de surveiller le tracker de sécurité Debian et d’appliquer le correctif dès sa publication dans le dépôt de sécurité. Sur les systèmes Red Hat Enterprise Linux, l’avis CSAF associé à la fiche CVE fournit le numéro de paquet corrigé à installer via yum update ou dnf update. Après mise à jour, il est recommandé de redémarrer les services qui chargent dynamiquement Libgcrypt (démons GnuPG, agents de chiffrement, serveurs de clés) pour s’assurer qu’ils utilisent bien la bibliothèque corrigée en mémoire, plutôt que l’ancienne version encore chargée depuis le démarrage du processus.
Ce que cela signifie pour l’écosystème OpenPGP
Pour les utilisateurs de GnuPG en environnement professionnel, en particulier dans les secteurs où la signature de code et le chiffrement de courrier restent des pratiques courantes (édition de logiciels, administration publique, recherche académique), cette faille rappelle qu’un outil considéré comme une référence de confiance depuis plus de vingt ans continue de nécessiter une maintenance active. GnuPG lui-même n’a pas publié de déclaration spécifique sur CVE-2024-2236 dans les sources consultées, ce qui reflète la répartition classique des responsabilités dans l’écosystème : Libgcrypt gère le correctif au niveau de la bibliothèque, et les distributions (Ubuntu, Debian, Red Hat) le propagent ensuite à leurs utilisateurs via leurs propres canaux d’avis de sécurité.
Cette architecture en couches, bibliothèque cryptographique en amont puis distributions en aval, explique aussi pourquoi la fenêtre entre la divulgation initiale d’une faille et sa correction complète sur l’ensemble des systèmes peut s’étaler sur plusieurs années, comme le montre le délai entre l’attribution de CVE-2024-2236 et sa correction effective par Ubuntu début septembre 2026.
Prévisions : ce qui va probablement se passer dans les prochains mois
Plusieurs évolutions semblent probables à court et moyen terme sur ce dossier.
- D’autres distributions basées sur Debian (dérivés grand public, distributions orientées serveur) devraient publier leurs propres avis de sécurité dans les semaines suivant celui d’Ubuntu, avec un décalage de propagation typique de plusieurs semaines à quelques mois.
- Les obligations européennes de signalement des vulnérabilités actives, effectives à l’automne 2026, vont probablement pousser davantage d’éditeurs à documenter publiquement ce type de correctif de bibliothèque tierce, plutôt que de le noyer dans des notes de version génériques.
- Le rythme des découvertes de failles temporelles sur des bibliothèques cryptographiques matures (Libgcrypt, OpenSSL, GnuTLS, wolfSSL, Bouncy Castle) devrait rester soutenu en 2026 et 2027, porté par l’essor des outils d’analyse dynamique de canaux auxiliaires dans les audits de sécurité.
- La pression pour réduire, voire retirer, la prise en charge du bourrage PKCS#1 v1.5 dans les nouvelles implémentations RSA devrait s’accentuer, au profit de schémas comme RSA-OAEP correctement implémentés en temps constant ou de la migration vers des primitives post-quantiques recommandées par l’ANSSI et l’ENISA.
- Les cabinets d’audit de code cryptographique devraient continuer à voir croître la demande pour des revues spécifiquement ciblées sur les canaux auxiliaires, un segment jusqu’ici moins prioritaire que les audits de logique protocolaire classique.
Foire aux questions
Qu’est-ce que CVE-2024-2236 exactement ?
C’est une faille de canal auxiliaire temporel dans l’implémentation RSA de la bibliothèque Libgcrypt, corrigée par Ubuntu le 1er septembre 2026 via l’avis USN-8711-1. Elle permet, dans certaines conditions réseau, de monter une attaque de type Bleichenbacher pour déchiffrer des données chiffrées en RSA.
Quelles versions d’Ubuntu sont concernées ?
Ubuntu 22.04 LTS, 24.04 LTS et 26.04 LTS sont toutes trois concernées. Les versions corrigées du paquet libgcrypt20 sont respectivement 1.9.4-3ubuntu3.3, 1.10.3-2ubuntu0.2 et 1.12.0-2ubuntu1.1.
Quel est le score de sévérité de cette faille ?
Le score CVSS relevé publiquement est de 5,9, ce qui correspond à une sévérité moyenne. L’exploitation nécessite l’envoi d’un grand nombre de messages d’essai, ce qui limite les scénarios réalistes aux services exposés en réseau plutôt qu’à un usage local hors ligne.
GnuPG est-il directement affecté ?
Libgcrypt est la bibliothèque cryptographique utilisée par GnuPG pour ses opérations RSA. Un service qui utilise GnuPG avec Libgcrypt pour déchiffrer des messages OpenPGP reçus depuis un réseau non maîtrisé peut donc être exposé, mais un usage purement local reste beaucoup plus difficile à exploiter.
Comment savoir si mon système utilise une version vulnérable de Libgcrypt ?
Sous Ubuntu ou Debian, la commande dpkg -l | grep libgcrypt20 affiche la version installée. Il suffit ensuite de la comparer aux versions corrigées listées dans l’avis USN-8711-1 ou dans le tracker de sécurité Debian.
Cette faille est-elle liée à l’attaque Bleichenbacher de 1998 ?
Elle s’inscrit dans la même famille conceptuelle : les fournisseurs et chercheurs qui l’ont documentée la qualifient explicitement d’attaque de type Bleichenbacher, même si le mécanisme précis (canal temporel plutôt que message d’erreur explicite) diffère de l’attaque originale.
Faut-il migrer vers des algorithmes post-quantiques à cause de cette faille ?
Cette faille précise ne casse pas RSA lui-même et ne justifie pas à elle seule une migration en urgence. Elle renforce cependant l’argument plus large déjà porté par l’ANSSI et l’ENISA en faveur d’une transition progressive vers des algorithmes résistants au quantique, dans la mesure où elle illustre la fragilité persistante des implémentations RSA historiques.
D’autres bibliothèques cryptographiques ont-elles eu des failles similaires en 2026 ?
Oui. OpenSSL, Go (module crypto/tls), Bouncy Castle, GnuTLS et wolfSSL ont tous publié des correctifs de sécurité significatifs sur des composants cryptographiques au cours de l’année 2026, ce qui traduit une intensification générale de la découverte de failles sur les bibliothèques de chiffrement largement déployées.
