Trois semaines après un bulletin d’août déjà chargé, OpenSSL replonge dans les correctifs d’urgence. Entre le 25 août et le 19 septembre 2026, le projet et ses relais chez Red Hat, Ubuntu et Oracle ont publié ou mis à jour neuf identifiants CVE distincts touchant les modules CMS, CMP, ASN.1, PKCS#12 et le gestionnaire QUIC. Deux failles sortent du lot : une écriture hors limites dans le décodage de messages CMS chiffrés (CVE-2026-63072) et un crash à distance non authentifié du serveur CMP (CVE-2026-63076). Aucune des deux ne permet à ce stade l’exécution de code arbitraire, mais leur exploitation reste possible sans authentification préalable sur des services exposés à Internet.
Neuf CVE en trois semaines : ce qui vient d’être corrigé dans OpenSSL
La chronologie commence le 25 août 2026, quand Ubuntu publie sa fiche pour CVE-2026-75803, une anomalie dans le déchiffrement authentifié ChaCha20-Poly1305 et AES-OCB. Le problème : avec un texte chiffré vide, la fonction EVP_Cipher() peut signaler un succès sans avoir réellement vérifié le tag d’authentification, ce qui ouvre la porte à des messages forgés dans certains scénarios d’intégration. OpenSSL classe cette faille en sévérité faible dans son bulletin officiel, un point sur lequel les avis secondaires ne s’accordent pas toujours, d’où l’importance de se référer à la fiche du projet plutôt qu’à des résumés tiers.
La fiche est mise à jour le 4 septembre. Puis, le 16 septembre, un bilan de sécurité Linux évoque un errata Oracle référencé ELSA-2026-67165-0, qui rebase OpenSSL vers la version 3.5.8-1.0.1 sur Oracle Linux 9 et embarque un lot de correctifs incluant CVE-2026-14456, 14457, 18798, 54874 et la série 63072 à 63076. Trois jours plus tard, le 19 septembre, Red Hat publie un avis distinct qui détaille six failles supplémentaires : CVE-2026-7383, 9076, 34180, 34181, 34182 et 34183. Au total, neuf identifiants CVE circulent sur une fenêtre de moins d’un mois, tous rattachés au même cœur de code OpenSSL mais à des sous-systèmes différents.
Ce rythme de publication illustre un phénomène courant avec les grandes bibliothèques cryptographiques : une faille corrigée en amont déclenche une cascade d’avis en aval, chaque distribution Linux et chaque éditeur devant retester, repackager et republier ses propres bulletins. Le lecteur pressé retiendra surtout deux chiffres : neuf CVE traités en trois semaines, et six branches d’OpenSSL différentes à corriger en parallèle (4.0, 3.6, 3.5, 3.4, 3.0 et la lignée historique 1.1.1).
CVE-2026-63072 : l’écriture hors limites dans CMS_decrypt()
La faille la plus documentée de cette vague touche la fonction CMS_decrypt(), utilisée pour déchiffrer des messages au format Cryptographic Message Syntax (CMS), un standard largement employé pour l’échange de courriels sécurisés, la signature de documents et certains flux d’infrastructure à clé publique (PKI). Le problème vient du déballage de clé AES-WRAP-PAD : lors du traitement d’un message CMS spécialement forgé, la routine peut écrire jusqu’à huit octets au-delà de la zone mémoire allouée sur le tas.
Concrètement, un attaquant capable de soumettre un message CMS malveillant à une application qui appelle CMS_decrypt() peut provoquer un plantage du processus, donc un déni de service. Selon la fiche officielle publiée sur CVE.org, OpenSSL a corrigé le problème dans les versions 4.0.2, 3.6.4, 3.5.8, 3.4.7, 3.0.22 et 1.1.1zi, ce qui donne une liste précise de versions minimales à déployer. Les équipes qui exploitent des passerelles de messagerie sécurisée, des serveurs de signature de documents ou des solutions d’archivage électronique s’appuyant sur CMS sont les premières concernées.
CVE-2026-63076 : le crash à distance du serveur CMP
Deuxième faille marquante : une déréférence de pointeur invalide (catégorie CWE-476) dans le serveur Certificate Management Protocol (CMP) d’OpenSSL. Le CMP est le protocole utilisé par de nombreuses autorités de certification internes et solutions de gestion de cycle de vie des certificats pour délivrer, renouveler ou révoquer des certificats X.509 de façon automatisée.
Le code vérifiait uniquement que le champ protectionAlg d’une requête CMP n’était pas nul, sans valider son type ASN.1 avant de le traiter comme un paramètre PBM (Password-Based MAC). Un client ou un attaquant qui envoie un champ protectionAlg mal formé peut donc déclencher une déréférence invalide et faire planter un serveur CMP, sans avoir besoin de s’authentifier au préalable. Cette faille touche les branches 4.0, 3.6, 3.5, 3.4 et 3.0, corrigées respectivement en 4.0.2, 3.6.4, 3.5.8, 3.4.7 et 3.0.22. Pour les entreprises qui exploitent leur propre autorité de certification interne avec automatisation CMP, un cas fréquent dans les environnements PKI d’entreprise et gouvernementaux, c’est la faille à traiter en priorité.
Les six failles de l’avis Red Hat du 19 septembre
L’avis Red Hat publié le 19 septembre 2026 regroupe six vulnérabilités moins spectaculaires individuellement, mais qui touchent des chemins de code très utilisés :
- CVE-2026-7383 : un dépassement d’entier signé dans les fonctions
ASN1_mbstring_ncopy()etASN1_mbstring_copy(), qui se traduit par un débordement de tampon sur le tas (CWE-787) lors du traitement de chaînes Unicode personnalisées viaASN1_STRING_TABLE_add(). Point notable : les modules certifiés FIPS d’OpenSSL 4.0, 3.6, 3.5, 3.4 et 3.0 ne sont pas concernés, car le fichier vulnérable se situe hors de la frontière du module FIPS. - CVE-2026-9076 : une lecture hors limites dans le déchiffrement CMS basé sur mot de passe, pouvant entraîner un déni de service.
- CVE-2026-34180 : une lecture hors limites sur le tas dans le décodage ASN.1, susceptible de provoquer un déni de service ou une fuite d’information limitée.
- CVE-2026-34181 : des fichiers PKCS#12 protégés par PBMAC1 acceptés avec des clés HMAC trop courtes, ce qui affaiblit les garanties d’intégrité de ce mécanisme dans certains scénarios de stockage de clés et de certificats.
- CVE-2026-34182 : une validation insuffisante des longueurs de chiffré et de tag dans le traitement CMS AuthEnvelopedData, qui pourrait permettre à un attaquant positionné sur le chemin réseau de forger des messages ou de contourner la vérification d’intégrité.
- CVE-2026-34183 : une croissance mémoire non bornée dans le gestionnaire QUIC PATH_CHALLENGE, exploitable pour épuiser la mémoire d’un serveur QUIC/TLS et provoquer un déni de service.
Pris isolément, aucun de ces six correctifs ne constitue une urgence absolue. Pris ensemble, ils dessinent une tendance claire : les modules périphériques d’OpenSSL, à savoir CMS, CMP, PKCS#12 et QUIC, concentrent l’essentiel des découvertes récentes, alors que le cœur TLS 1.3 reste relativement stable depuis sa réécriture actée par la RFC 9846.
Tableau récapitulatif des neuf CVE et de leurs correctifs
| CVE | Module touché | Type de faille | Impact | Versions corrigées |
|---|---|---|---|---|
| CVE-2026-63072 | CMS (CMS_decrypt) | Écriture hors limites (8 octets) | Déni de service | 4.0.2 / 3.6.4 / 3.5.8 / 3.4.7 / 3.0.22 / 1.1.1zi |
| CVE-2026-63076 | CMP (serveur) | Déréférence de pointeur invalide | Crash à distance non authentifié | 4.0.2 / 3.6.4 / 3.5.8 / 3.4.7 / 3.0.22 |
| CVE-2026-7383 | ASN.1 (chaînes Unicode) | Débordement de tampon sur le tas | Déni de service | Branches 4.0 à 3.0 (FIPS non concerné) |
| CVE-2026-9076 | CMS (déchiffrement par mot de passe) | Lecture hors limites | Déni de service | Correctif Red Hat du 19/09 |
| CVE-2026-34180 | Décodage ASN.1 | Lecture hors limites sur le tas | Déni de service / fuite limitée | Correctif Red Hat du 19/09 |
| CVE-2026-34181 | PKCS#12 (PBMAC1) | Validation insuffisante des clés HMAC | Affaiblissement de l’intégrité | Correctif Red Hat du 19/09 |
| CVE-2026-34182 | CMS AuthEnvelopedData | Validation insuffisante longueur/tag | Forgerie de message possible | Correctif Red Hat du 19/09 |
| CVE-2026-34183 | QUIC (PATH_CHALLENGE) | Croissance mémoire non bornée | Épuisement mémoire / déni de service | Correctif Red Hat du 19/09 |
| CVE-2026-75803 | AEAD (ChaCha20-Poly1305, AES-OCB) | Vérification de tag manquante sur texte vide | Sévérité faible selon OpenSSL | Publiée le 25/08, mise à jour le 04/09 |
Exploitation active : ce que l’on sait à ce jour
Aucune de ces neuf failles n’apparaît à ce jour dans le registre officiel des vulnérabilités OpenSSL comme activement exploitée. Pour CVE-2026-75803 en particulier, la fiche publique ne recense aucune référence d’exploit public et la décision de priorisation associée conclut à l’absence de preuve d’exploitation. Cela ne signifie pas que le risque est nul : historiquement, les failles CMS et CMP mettent plusieurs mois avant d’être ciblées, le temps que des chercheurs ou des groupes malveillants développent des preuves de concept exploitables contre des cibles réelles. Le déni de service reste toutefois le scénario le plus probable à court terme, car il est nettement plus simple à mettre en œuvre qu’une corruption mémoire menant à l’exécution de code.
Le fait que les modules FIPS ne soient pas affectés par CVE-2026-7383 est également un point rassurant pour les déploiements certifiés, notamment dans les secteurs bancaire et gouvernemental où la certification FIPS 140 conditionne souvent l’homologation des produits.
Comparaison avec le bulletin d’août 2026
Ce n’est pas la première fois qu’OpenSSL publie un lot conséquent de correctifs cette année. Fin août, le projet avait déjà corrigé neuf vulnérabilités en une seule salve, avec le protocole QUIC visé à trois reprises, dont la faille de déni de service CVE-2026-14456. La vague de septembre s’en distingue par sa cible : là où le bulletin d’août touchait davantage le cœur protocolaire (QUIC, TLS), les correctifs de septembre se concentrent sur les couches de gestion de certificats et de messages signés ou chiffrés (CMS, CMP, PKCS#12). C’est un changement de surface d’attaque plus qu’une aggravation générale : les chercheurs qui auditent OpenSSL semblent avoir déplacé leur attention vers les modules PKI après avoir largement couvert le cœur TLS.
Cette continuité entre les deux vagues confirme une tendance observée sur l’ensemble de 2026 : OpenSSL publie des correctifs de sécurité à un rythme plus soutenu que les années précédentes, porté par un examen plus systématique du code lié aux protocoles récents comme QUIC et par l’attention accrue portée aux bibliothèques cryptographiques dans le sillage de la mise en œuvre du Cyber Resilience Act européen.
OpenSSL face aux autres bibliothèques cryptographiques
OpenSSL n’est pas seul sur le marché des bibliothèques TLS et cryptographiques open source. GnuTLS et wolfSSL ont également connu leur lot de correctifs en 2026, avec des CVE distincts touchant la gestion des certificats, dans la continuité d’une année marquée par une vague plus large de failles touchant TLS 1.3 chez plusieurs éditeurs. BoringSSL, le fork maintenu par Google et utilisé dans Chrome et une partie de l’infrastructure Google, suit un cycle de développement plus fermé et moins de CVE publiques, en partie parce qu’il n’est pas conçu comme un produit externe stable mais comme une dépendance interne mise à jour en continu. LibreSSL, le fork porté par le projet OpenBSD, revendique une base de code volontairement réduite pour limiter la surface d’attaque, une approche qui paie sur le papier mais qui limite aussi la compatibilité avec certaines fonctionnalités récentes comme QUIC natif.
Malgré ces alternatives, OpenSSL reste la bibliothèque cryptographique open source la plus déployée au monde. Elle est embarquée par défaut dans la quasi-totalité des distributions Linux d’entreprise (Red Hat Enterprise Linux, Oracle Linux, Ubuntu, Debian, SUSE), dans de nombreux serveurs web, dans des équipements réseau et dans d’innombrables applications métier qui l’utilisent via des bindings dans des langages comme Python, Node.js, Java ou Go. Cette omniprésence explique pourquoi chaque vague de CVE OpenSSL déclenche une cascade d’avis chez tous les éditeurs et distributeurs Linux, contrairement à des bibliothèques plus confidentielles dont les correctifs restent circonscrits à un nombre limité de produits.
Tableau comparatif : OpenSSL et ses alternatives
| Bibliothèque | Mainteneur | Usage principal | Rythme de publication CVE 2026 | Support QUIC natif |
|---|---|---|---|---|
| OpenSSL | Communauté OpenSSL (fondation) | Distributions Linux, serveurs web, PKI | Élevé, plusieurs bulletins groupés | Oui |
| BoringSSL | Chrome, infrastructure interne Google | Faible visibilité publique | Oui | |
| LibreSSL | Projet OpenBSD | OpenBSD, quelques distributions dérivées | Faible, base de code réduite | Partiel |
| GnuTLS | Projet GNU | Applications GNU/Linux, certains VPN | Modéré, plusieurs CVE en 2026 | Non natif |
| wolfSSL | wolfSSL Inc. | Systèmes embarqués, IoT | Modéré, dont une faille ML-KEM en 2026 | Oui |
Quels secteurs sont les plus exposés
Les secteurs les plus exposés à cette vague de correctifs sont ceux qui s’appuient le plus lourdement sur les modules touchés. Les environnements bancaires et financiers, qui utilisent le CMS pour la signature de transactions et d’échanges de fichiers réglementaires, doivent traiter en priorité CVE-2026-63072 et CVE-2026-34182. Les administrations et opérateurs qui exploitent leur propre autorité de certification interne, avec un serveur CMP pour automatiser le cycle de vie des certificats, sont directement concernés par CVE-2026-63076. Le secteur des télécommunications et les fournisseurs de contenu qui déploient massivement QUIC pour accélérer leurs services web doivent surveiller CVE-2026-34183 et son risque d’épuisement mémoire. Enfin, toute organisation qui archive des clés ou des certificats dans des conteneurs PKCS#12 doit vérifier son exposition à CVE-2026-34181, qui touche directement la robustesse du mécanisme d’intégrité PBMAC1.
Le commerce en ligne, très dépendant de TLS pour les transactions, est moins directement concerné par cette vague spécifique puisque le cœur du protocole n’est pas en cause, mais reste indirectement exposé via les services de facturation électronique et de signature de documents qui s’appuient souvent sur CMS.
Le contexte réglementaire européen : CRA et obligations de correction
Cette vague de correctifs tombe alors que le Cyber Resilience Act européen entre progressivement en application, avec des obligations de gestion des vulnérabilités et de notification qui pèsent directement sur les éditeurs de logiciels intégrant des composants comme OpenSSL. Concrètement, une entreprise qui distribue un produit embarquant une version vulnérable d’OpenSSL peut être tenue de documenter sa réponse à ces CVE dans le cadre de ses obligations de conformité, y compris la disponibilité d’un correctif et le délai de déploiement. Cette dynamique réglementaire renforce l’intérêt des nomenclatures logicielles (SBOM), qui permettent justement d’identifier rapidement quels produits embarquent quelle version d’OpenSSL sans avoir à auditer manuellement chaque dépendance.
Pour les opérateurs français et européens soumis à des obligations de sécurité renforcées, comme les opérateurs de services essentiels ou les entités importantes au sens de la directive NIS2, la veille sur ces bulletins passe aussi par les avis publiés par le CERT-FR. Ce type de vague de correctifs groupés constitue un cas d’école : il faut être capable d’identifier en quelques heures l’ensemble des systèmes exposés, prioriser les correctifs selon la surface d’exposition réelle (serveur CMP public, passerelle CMS, service QUIC) et documenter la remédiation.
Ce que les équipes de sécurité doivent faire maintenant
La première étape reste triviale mais souvent négligée : vérifier la version d’OpenSSL réellement en production, y compris celle embarquée dans des conteneurs ou des applications compilées statiquement. Pour les équipes qui gèrent elles-mêmes leurs certificats, notre guide sur la génération de clés et de certificats avec OpenSSL reste une référence utile pour comprendre les commandes de base avant d’aller plus loin dans le durcissement.
openssl version -a
# Vérifier que la version installée est au moins :
# 4.0.2, 3.6.4, 3.5.8, 3.4.7, 3.0.22 ou 1.1.1zi
# Sur les distributions basées sur Red Hat / Oracle Linux :
sudo dnf update openssl openssl-libs
# Sur Ubuntu / Debian :
sudo apt update && sudo apt install --only-upgrade openssl libssl3
# Inventorier les binaires qui embarquent OpenSSL statiquement :
grep -rl "OpenSSL" /opt /usr/local --include="*.so" 2>/dev/nullEnsuite, il faut prioriser selon l’exposition réelle : un serveur CMP accessible depuis Internet doit être patché avant un serveur CMS interne, lui-même prioritaire sur une application PKCS#12 utilisée uniquement en local. Les équipes qui gèrent des flottes de conteneurs doivent penser à reconstruire leurs images de base, car un correctif appliqué à l’hôte ne protège pas automatiquement les conteneurs qui embarquent leur propre copie de la bibliothèque. Enfin, un inventaire SBOM à jour reste le moyen le plus rapide de répondre à la question « quels produits sont concernés » sans audit manuel exhaustif.
Prédictions : ce qui va suivre pour OpenSSL et l’écosystème PKI
- D’autres CVE devraient émerger dans les prochains mois autour des modules CMS et CMP, ces sous-systèmes ayant historiquement reçu moins d’audits que le cœur TLS et étant désormais sous les projecteurs après cette vague.
- Les distributions Linux d’entreprise vont continuer à accélérer leurs cycles de rebase pour suivre le rythme des correctifs OpenSSL, au risque d’augmenter la fréquence des mises à jour à appliquer côté opérateurs.
- La pression réglementaire liée au Cyber Resilience Act devrait pousser davantage d’éditeurs à publier des SBOM détaillés listant précisément leur version d’OpenSSL, plutôt que de laisser leurs clients deviner leur exposition.
- Certains grands hyperscalers et opérateurs cloud pourraient accélérer leur migration vers des forks alternatifs comme BoringSSL pour réduire leur dépendance aux cycles de correctifs groupés d’OpenSSL, sans pour autant remplacer OpenSSL dans l’écosystème Linux au sens large.
- Les environnements PKI d’entreprise vont probablement renforcer la fréquence de leurs audits de dépendances CMS/CMP, un sous-système longtemps considéré comme secondaire par rapport au cœur TLS.
Foire aux questions
Quelle est la faille OpenSSL la plus urgente à corriger dans cette vague ?
CVE-2026-63076 mérite la priorité la plus élevée pour les organisations qui exposent un serveur CMP sur Internet, car elle permet un crash à distance sans authentification préalable. CVE-2026-63072 suit de près pour toute application traitant des messages CMS non fiables.
Ces failles permettent-elles l’exécution de code à distance ?
À ce jour, non. Les neuf CVE de cette vague de septembre entraînent majoritairement des dénis de service (plantage ou épuisement mémoire), une lecture ou écriture hors limites limitée, ou un affaiblissement de garanties d’intégrité, mais aucune n’a été documentée comme permettant l’exécution de code arbitraire à distance.
Faut-il mettre à jour même si mon serveur n’est pas exposé publiquement ?
Oui. Plusieurs de ces failles peuvent être déclenchées par un fichier ou un message malveillant traité en interne, comme un PKCS#12 importé ou un message CMS reçu par courriel, sans nécessiter d’exposition directe du service sur Internet.
Quelle version d’OpenSSL dois-je viser après ces correctifs ?
Selon la branche utilisée : 4.0.2, 3.6.4, 3.5.8, 3.4.7, 3.0.22 ou 1.1.1zi pour les correctifs de la série 63072/63076. Pour les six CVE de l’avis Red Hat du 19 septembre, il faut appliquer le correctif packagé par votre distribution, ces identifiants n’étant pas tous rattachés à un numéro de version amont individualisé au moment de la publication.
Ces CVE affectent-elles les modules certifiés FIPS 140 ?
Non, dans le cas précis de CVE-2026-7383 : le code vulnérable se situe en dehors de la frontière du module FIPS d’OpenSSL 4.0, 3.6, 3.5, 3.4 et 3.0, ce qui signifie que les déploiements certifiés FIPS ne sont pas concernés par cette faille spécifique. Les autres CVE de la vague doivent être vérifiées au cas par cas selon la documentation du module FIPS utilisé.
Y a-t-il un lien avec le bulletin OpenSSL d’août 2026 ?
Les deux vagues touchent le même projet mais des identifiants CVE différents et des sous-systèmes différents. Le bulletin d’août ciblait davantage le cœur protocolaire, dont QUIC, tandis que la vague de septembre se concentre sur les modules de gestion de certificats et de messages signés ou chiffrés.
Existe-t-il un exploit public pour l’une de ces failles ?
Non, aucune preuve d’exploitation active ou d’exploit public n’a été documentée pour ces neuf CVE au moment de la publication de cet article. Cela peut évoluer rapidement, d’où l’intérêt de patcher sans attendre une preuve de concept.
