OpenSSL est la bibliothèque de chiffrement qui sécurise les connexions HTTPS de presque tous les serveurs web. Les cinq failles publiées le 10 novembre 2026 sont classées "faibles" par l'éditeur et ne visent que des usages précis : un site classique y est peu exposé. Demandez à votre prestataire quelle version tourne sur vos serveurs et s'il prévoit la mise à jour dès la sortie des correctifs.
Faut-il se précipiter sur la mise à jour d'OpenSSL ? Non, mais il faut savoir ce que l'on a installé, et c'est souvent là que les surprises commencent. Le CERT-FR, le centre de veille de l'État, a signalé de multiples vulnérabilités dans cette bibliothèque : déni de service (un service saturé ou planté), atteinte à la confidentialité, contournement de la politique de sécurité. Sa page d'avis renvoyait une erreur 404 quand nous avons voulu la lire. Impossible donc d'affirmer qu'elle recoupe le lot détaillé ci-dessous.
Que contient l'avis OpenSSL du 10 novembre 2026 ?
L'avis d'OpenSSL couvre cinq CVE, c'est-à-dire cinq failles référencées publiquement, toutes rangées "Low" par l'éditeur. L'avis officiel les répartit en trois familles.
Deux touchent QUIC, un protocole de transport moderne qui sert de base à HTTP/3 et remplace en partie TCP et TLS. L'une peut laisser fuir des données de pile vers un observateur du réseau, dans une application QUIC dont le socket est déjà connecté. L'autre permet à un serveur QUIC malveillant de faire planter un client.
Deux touchent AES-GCM-SIV, un mode de chiffrement conçu pour résister aux erreurs de réutilisation des valeurs d'initialisation (IV). La première permet de falsifier les AAD, ces données jointes à un message, authentifiées mais non chiffrées. La seconde provoque une lecture hors limites si l'IV ne fait pas 12 octets.
La dernière touche CMS, un format de messages chiffrés ou signés qu'on croise dans S/MIME. Un certificat hostile y déclenche une boucle infinie : le processeur sature.
Aucune exploitation active ni démonstration publique n'est signalée, d'après securityonline.info, qui relève par ailleurs une incohérence sur la sévérité affichée.
Un site classique est peu exposé
Prenons une entreprise de négoce avec un site et un espace client derrière nginx et PHP-FPM. Elle ne joue pas le client QUIC, ne chiffre pas ses données en AES-GCM-SIV avec des IV exotiques et n'ouvre pas de messages CMS venus de certificats inconnus. Les usages visés sont rares.
Ceux qui doivent regarder de près : les équipes qui chiffrent du S/MIME avec des certificats externes, utilisent HTTP/3 côté client ou font de la cryptographie dans leur propre code.
Les autres peuvent noter la date et garder leur semaine.
Calendrier : le 1er décembre, puis un redémarrage
Les versions corrigées sont les 4.1.1, 4.0.4 et 3.5.10, annoncées pour le 1er décembre 2026. Les correctifs sont déjà dans le dépôt public de l'éditeur, et un conseil circule pour compiler soi-même d'ici là. Il n'a pas été testé, et nous ne le conseillons pas pour un risque aussi faible.
Les distributions Linux et les images Docker suivront avec un délai que nous n'avons pas pu documenter. Autre point à retenir : les serveurs web et les workers gardent l'ancienne bibliothèque tant qu'on ne les relance pas. Redémarrez nginx, PHP-FPM et les workers une fois le paquet mis à jour, pas avant.
D'ici là, le vrai travail est l'inventaire : quelle version sur chaque serveur, chaque image ? Un tableur nommé "final_v12_VRAI" ne compte pas. C'est le genre de suivi que couvre un contrat d'hébergement et maintenance, et nous accompagnons des entreprises de Provence, autour de Marseille, sur ce sujet. Nous avions déjà détaillé la démarche pour les failles PHP2Shell.
Et si l'on reste sur une version ancienne ?
C'est le seul vrai point d'attention. Les branches 3.0, 1.1.1 et 1.0.2 sont touchées par une seule faille, celle de CMS, qui sature le processeur. Ses correctifs (3.0.24, 1.1.1zk, 1.0.2zt) sont réservés aux clients d'un support premium, une maintenance prolongée après la fin de vie, payante.
Sur la page commerciale de l'éditeur, l'extension de support figure dans des offres à 65 000 $ par an (Engineering) ou 175 000 $ par an (Enterprise). Le prix du support étendu seul n'est pas publié. Pour une petite structure, ce tarif n'a guère de sens : mieux vaut migrer vers une branche supportée.
Les branches 3.1 à 3.4 et 3.6, qui ne sont plus maintenues, n'ont même pas été analysées. Si votre application repose sur un vieux socle, une reprise de l'application existante règle souvent le problème à la racine. Un vieux serveur n'a pas besoin d'un contrat à 65 000 $ : il a surtout besoin de partir à la retraite.
- Cinq CVE classées "Low" par OpenSSL, sans exploitation active signalée.
- Un site classique est peu exposé : QUIC, AES-GCM-SIV et CMS sont des usages rares.
- Correctifs 4.1.1, 4.0.4 et 3.5.10 annoncés pour le 1er décembre 2026, puis redémarrage des services.
- Sur 3.0, 1.1.1 ou 1.0.2, le correctif est payant : mieux vaut migrer.
Si ce sujet touche votre activité, choisissez un créneau : nous regardons votre cas ensemble.
Questions fréquentes
Qu'est-ce qu'un CVE ?
C'est le numéro d'identification public d'une faille de sécurité, sous la forme CVE-année-numéro. Il permet à tous de parler de la même faille et de suivre son correctif.
Faut-il compiler OpenSSL soi-même avant le 1er décembre ?
Un conseil en ce sens circule, mais il n'a pas été testé et il alourdit la maintenance. Pour un serveur ordinaire, mieux vaut attendre les paquets de la distribution, puisque le risque est faible.
Les modules FIPS sont-ils touchés ?
Non, selon l'avis d'OpenSSL, les modules FIPS ne sont pas affectés par ce lot de cinq failles.