Le 2 septembre 2026, le projet curl a publié la version 8.22.0 et, avec elle, dix nouveaux identifiants CVE. Rien d’exceptionnel en soi : la bibliothèque, présente selon ses propres estimations dans environ trente milliards d’installations dans le monde, publie des lots de correctifs plusieurs fois par an. Ce qui retient l’attention cette fois, c’est la nature des failles. Quatre des neuf CVE touchant curl et libcurl concernent directement la façon dont le logiciel vérifie les certificats et gère les contextes cryptographiques d’OpenSSL et de wolfSSL. Le CERT-FR a jugé le sujet assez sérieux pour publier son propre avis, CERTFR-2026-AVI-1108, le jour même de la sortie.
curl équipe des routeurs, des voitures, des téléviseurs, des distributions Linux entières et une bonne partie des applications mobiles qui parlent HTTPS. Une faille de validation de certificat dans cette brique, même notée “faible” par ses propres mainteneurs, mérite qu’on s’y arrête. Voici ce que contient réellement ce lot de correctifs, pourquoi la sévérité affichée peut tromper, et ce que cela dit de l’état de la vérification TLS en 2026.
curl 8.22.0 : dix failles corrigées en une seule publication
Le projet curl a documenté neuf CVE pour curl et libcurl, plus un dixième pour l’outil compagnon wcurl, tous publiés le 2 septembre 2026 selon la page officielle des avis de sécurité. Le mainteneur principal Daniel Stenberg a détaillé la liste complète sur son blog personnel le jour de la sortie. Sur les neuf failles curl, quatre relèvent directement de la cryptographie et de la validation TLS : CVE-2026-80229, CVE-2026-80230, CVE-2026-82208 et CVE-2026-80231. Les cinq autres concernent des sujets plus périphériques : la gestion des cookies (CVE-2026-82209, CVE-2026-80255), la réutilisation de connexions authentifiées (CVE-2026-19931), une use-after-free dans le HTTP/2 server push (CVE-2026-18924) et un contournement d’authentification SASL dans OpenLDAP via wcurl (CVE-2026-13608).
Les chercheurs et l’équipe curl ont travaillé sur un calendrier serré. Les rapports initiaux datent du 24 et du 27 août 2026, et le correctif est sorti le 2 septembre, soit une fenêtre de huit à onze jours entre signalement et publication. Ce rythme reste dans la moyenne habituelle du projet, connu pour traiter ses rapports de sécurité rapidement plutôt que de les laisser s’accumuler.
CVE-2026-80229 : une use-after-free dans les providers OpenSSL 3
La première faille touche l’interface multi de libcurl, celle qui permet de gérer plusieurs transferts en parallèle avec réutilisation de connexions. Quand libcurl est compilé avec le système de providers d’OpenSSL 3, il attache un contexte de bibliothèque à l’état du handle “easy” sans en garder une référence de propriété. Si ce handle est détruit avant que la connexion TLS mise en pool ne le soit, le contexte est libéré alors que la connexion active y pointe encore. Résultat : un pointeur pendouillant exploité lors d’une opération d’entrée-sortie ultérieure, classée CWE-416, use-after-free.
curl précise que le bug ne peut se produire que sur des builds utilisant OpenSSL 3 ou plus récent, aucune des variantes dérivées comme BoringSSL ou LibreSSL n’implémentant ce système de providers. Les versions concernées vont de curl 8.14.0 à 8.21.0. Le correctif est disponible dans curl 8.22.0. En attendant une mise à niveau, l’option CURLOPT_FORBID_REUSE permet de désactiver la réutilisation de connexion pour les transferts qui passent par un provider.
/* Mitigation temporaire avant mise a jour vers curl 8.22.0 */
curl_easy_setopt(handle, CURLOPT_FORBID_REUSE, 1L);CVE-2026-80230 : le contournement du certificate pinning OpenSSL
La deuxième faille est plus délicate à comprendre mais tout aussi révélatrice. Le certificate pinning, activé via CURLOPT_PINNEDPUBLICKEY, sert à épingler une clé publique précise pour une connexion donnée, indépendamment de la chaîne de confiance classique. C’est une protection courante contre les certificats frauduleux. Le problème apparaît quand un développeur combine ce pinning avec une désactivation de la vérification standard du pair, via CURLOPT_SSL_VERIFYPEER à 0 et CURLOPT_SSL_VERIFYHOST à 0. Dans cette configuration précise, libcurl échoue à appliquer le pinning sur les connexions établies sans certificat serveur présenté, ce qui permet à des connexions non authentifiées de passer alors qu’elles devraient être rejetées.
Cette faille, référencée CWE-295, validation de certificat incorrecte, touche curl de la version 7.45.0 à 8.21.0, soit une fenêtre d’exposition qui remonte à 2015. Elle concerne OpenSSL et l’ensemble de ses forks : BoringSSL, AWS-LC, LibreSSL et QuicTLS sont tous listés comme affectés. curl note toutefois que le scénario suppose déjà une configuration affaiblie par le développeur lui-même, ce qui limite la portée pratique du problème sans l’annuler.
CVE-2026-82208 : wolfSSL réinstalle un magasin de confiance compromis
La troisième faille cible spécifiquement le backend wolfSSL, alternative légère à OpenSSL très utilisée dans l’embarqué et l’IoT. Quand le cache de certificats d’autorité est activé et qu’un callback CURLOPT_SSL_CTX_FUNCTION remplace le magasin de confiance par défaut, libcurl peut réinstaller silencieusement le magasin mis en cache après l’exécution du callback. Un certificat que le magasin choisi par le développeur aurait dû rejeter se retrouve accepté, parce que l’ancien magasin, censé avoir été remplacé, reprend la main sans prévenir.
D’après l’avis officiel, le problème ne touche que les builds compilés avec le backend wolfSSL et n’affecte pas l’outil en ligne de commande curl, seulement les applications qui utilisent libcurl directement avec ce callback. Les versions concernées vont de 8.9.1 à 8.21.0. Le signalement, daté du 27 août 2026, est le plus récent des quatre failles cryptographiques du lot.
CVE-2026-80231 : la confusion du magasin CA natif sous Windows et macOS
La quatrième faille cryptographique ne touche que deux systèmes d’exploitation, Windows et macOS, via leurs magasins de certificats natifs respectifs. Quand un programme change le paramètre CURLSSLOPT_NATIVE_CA entre deux appels vers le même nom d’hôte, libcurl peut réutiliser à tort une connexion HTTPS établie sous l’ancienne configuration. Une connexion validée avec un jeu de certificats d’autorité peut donc servir à transporter du trafic qui aurait dû être validé avec un jeu différent, ce qui correspond à CWE-488, l’exposition d’un élément de données à la mauvaise session.
Les versions affectées vont de 7.71.0 à 8.21.0. Comme pour les trois autres failles cryptographiques, la parade immédiate consiste à activer CURLOPT_FORBID_REUSE pour les transferts qui s’appuient sur le magasin CA natif, en attendant la mise à jour vers 8.22.0.
Les six autres failles du lot : cookies, HTTP/2 et LDAP
Le reste de la publication touche des zones moins directement cryptographiques mais pas moins sensibles. CVE-2026-82209 concerne une fuite de cookies à portée de domaine via la Public Suffix List. CVE-2026-80255 porte sur un contournement de l’attribut de sécurité des cookies. CVE-2026-19931 permet, dans certaines configurations de connexions authentifiées par Negotiate, une réutilisation de connexion pour un utilisateur différent de celui prévu. CVE-2026-18924 est une use-after-free dans la gestion du HTTP/2 server push. Enfin, CVE-2026-13608 touche l’outil wcurl et son intégration avec l’authentification SASL d’OpenLDAP, un contournement distinct du cœur de libcurl.
Aucune de ces six failles n’est classée au-dessus de “faible” ou “moyen” par curl. Mais leur accumulation dans une même publication, combinée aux quatre failles cryptographiques, donne un lot de sécurité particulièrement dense pour un projet qui vise en général des publications plus courtes.
Les quatre failles cryptographiques de curl 8.22.0
| CVE | Composant concerné | Type (CWE) | Versions affectées | Signalée le |
|---|---|---|---|---|
| CVE-2026-80229 | OpenSSL 3 (providers) | CWE-416, use-after-free | 8.14.0 – 8.21.0 | 24 août 2026 |
| CVE-2026-80230 | OpenSSL et forks (BoringSSL, AWS-LC, LibreSSL, QuicTLS) | CWE-295, validation de certificat | 7.45.0 – 8.21.0 | 24 août 2026 |
| CVE-2026-82208 | wolfSSL | CWE-295, validation de certificat | 8.9.1 – 8.21.0 | 27 août 2026 |
| CVE-2026-80231 | Magasin CA natif (Windows, macOS) | CWE-488, session croisée | 7.71.0 – 8.21.0 | 24 août 2026 |
Pourquoi ces failles restent classées “faibles” malgré leur lien avec le chiffrement
Sur le papier, quatre failles de validation de certificat dans une même publication ressemblent à une alerte rouge. En pratique, curl attribue à chacune une sévérité faible, et ce choix mérite d’être expliqué plutôt que pris pour argent comptant. Trois des quatre failles exigent des préconditions précises : une configuration de callback particulière pour wolfSSL, un changement de paramètre CA natif entre deux appels pour la confusion Windows/macOS, ou une combinaison de pinning et de vérification désactivée pour le contournement OpenSSL. Ce ne sont pas des trous ouverts par défaut. Ce sont des pièges qui se referment seulement si le code appelant emprunte un chemin spécifique.
La use-after-free liée aux providers OpenSSL 3 est un cas légèrement différent. Elle peut se produire sans configuration exotique, dès lors que l’interface multi et la réutilisation de pool sont en jeu. C’est d’ailleurs la seule des quatre à toucher aussi l’outil en ligne de commande curl, et pas seulement les applications qui utilisent libcurl comme bibliothèque. Le classement “faible” tient ici davantage à la difficulté d’exploitation fiable d’une use-after-free qu’à l’absence de risque réel.
Trente milliards d’appareils : l’impact de marché d’une faille curl
curl n’est pas un logiciel de niche. Selon l’estimation que le projet publie lui-même dans sa FAQ, la bibliothèque tourne dans environ trente milliards d’installations à travers le monde en 2025, un chiffre qui inclut les distributions Linux, les appareils mobiles, les véhicules connectés, les décodeurs télé, les routeurs et une bonne partie du parc IoT industriel. C’est cette diffusion massive, plus que la gravité individuelle de chaque CVE, qui explique pourquoi une publication comme celle du 2 septembre déclenche des bulletins chez les éditeurs de distributions Linux, chez les fabricants de matériel réseau et chez les agences nationales de cybersécurité.
Le marché ne réagit pas de façon uniforme. Les distributions Linux à cycle de publication rapide, comme celles qui suivent Debian testing ou Fedora, intègrent généralement le correctif en quelques jours. Les environnements embarqués, où curl est souvent figé au moment de la certification d’un firmware, mettent parfois des mois voire des années à recevoir une mise à jour, quand ils en reçoivent une. C’est le décalage classique entre la vitesse de correction d’un projet open source et la vitesse réelle de déploiement dans le parc mondial, un problème structurel qui touche toutes les bibliothèques cryptographiques embarquées et pas seulement curl.
CERT-FR déclenche l’alerte CERTFR-2026-AVI-1108
En France, l’ANSSI a publié via son CERT-FR l’avis CERTFR-2026-AVI-1108, titré “Multiples vulnérabilités dans Curl”, le jour même de la sortie de la version 8.22.0. L’avis couvre les versions de curl et libcurl supérieures ou égales à 7.44.0 et antérieures à 8.22.0, soit pratiquement toutes les versions publiées depuis plus de dix ans. La recommandation est classique et sans ambiguïté : appliquer le correctif dès que possible.
Ce type d’avis s’inscrit dans le travail de veille habituel de l’ANSSI sur les bibliothèques largement déployées. Pour les organisations soumises à NIS2 ou qui opèrent des systèmes critiques, un avis CERT-FR sur une bibliothèque aussi répandue que curl sert souvent de déclencheur formel pour lancer un cycle de patch management, même quand la sévérité individuelle de chaque CVE reste modérée.
Le contexte historique : curl et wolfSSL, cibles récurrentes
Les bibliothèques de chiffrement les plus utilisées sont aussi celles qui reçoivent le plus d’attention de la part des chercheurs en sécurité, un effet mécanique de leur surface d’exposition. OpenSSL avait déjà connu un lot dense de six failles supplémentaires en septembre 2026, touchant ses modules CMS, CMP et ASN.1. wolfSSL avait pour sa part fait l’objet, plus tôt dans l’année, d’une faille distincte liée à son implémentation ML-KEM post-quantique, avec extraction de clé privée après plusieurs centaines de requêtes.
Le précédent le plus connu du grand public reste Heartbleed, la faille découverte dans OpenSSL en 2014, qui avait démontré qu’une brique cryptographique presque universellement déployée pouvait rester vulnérable pendant des années sans que personne ne s’en aperçoive. Douze ans plus tard, le rythme de découverte s’est nettement accéléré, non pas parce que le code est devenu moins sûr, mais parce que les méthodes d’audit, y compris assistées par des outils automatisés, couvrent désormais des recoins du code que la revue manuelle atteignait rarement.
Comparaison : quel backend TLS porte quelle faille
curl se distingue par sa capacité à compiler avec une quinzaine de bibliothèques TLS différentes selon les besoins de la plateforme cible. Cette flexibilité a un revers : chaque backend introduit sa propre surface de bug, et le lot du 2 septembre 2026 illustre bien cette fragmentation. Le tableau ci-dessous répartit les quatre failles cryptographiques selon le backend qu’elles concernent.
| Backend TLS | CVE associée(s) | Nature du problème |
|---|---|---|
| OpenSSL 3.x (providers) | CVE-2026-80229 | Contexte de bibliothèque libéré prématurément |
| OpenSSL et forks (BoringSSL, AWS-LC, LibreSSL, QuicTLS) | CVE-2026-80230 | Pinning de clé publique non appliqué sans certificat |
| wolfSSL | CVE-2026-82208 | Magasin de confiance mis en cache réinstallé après un callback |
| Magasin CA natif (Schannel, Secure Transport) | CVE-2026-80231 | Connexion réutilisée malgré un changement de configuration CA |
Cette répartition montre qu’aucun backend n’est épargné. OpenSSL, de loin le plus utilisé, concentre deux des quatre failles. wolfSSL, souvent choisi pour sa légèreté sur des cibles embarquées, en porte une qui touche spécifiquement son mécanisme de cache. Les magasins de certificats natifs des systèmes d’exploitation, censés simplifier la gestion de la confiance, introduisent leur propre classe de bug liée à la réutilisation de connexion.
Qui a trouvé les failles : la place croissante de la recherche automatisée
Les avis officiels de curl créditent le chercheur Stanislav Fort, rattaché à Aisle Research, pour le signalement des CVE-2026-80229 et CVE-2026-80230, les deux failles liées à OpenSSL. Daniel Stenberg, mainteneur historique du projet, est crédité comme correcteur sur l’ensemble du lot. Le délai entre signalement, le 24 août, et correction publiée, le 2 septembre, confirme un mode de fonctionnement que le projet revendique depuis longtemps : traiter les rapports de sécurité en quelques jours plutôt qu’en quelques semaines.
Ce cycle rapide s’inscrit dans une tendance plus large observée sur l’ensemble de l’écosystème open source en 2026 : des outils d’analyse automatisée, capables de couvrir en continu de larges portions de code C historiquement difficiles à auditer manuellement, remontent un nombre croissant de rapports vers les mainteneurs de bibliothèques critiques. curl elle-même reconnaît, dans plusieurs de ses avis récents, que certains de ces bugs relèvent d’erreurs typiques du langage C, ce qui suggère que le langage reste une source structurelle de ce type de défaut, indépendamment de la méthode de détection.
Ce que les entreprises doivent corriger maintenant
La recommandation officielle de curl est sans détour : passer à la version 8.22.0 dès que possible. Pour les organisations qui ne peuvent pas recompiler immédiatement leurs dépendances, chaque avis propose une parade temporaire. Pour les failles liées à la réutilisation de connexion, CVE-2026-80229 et CVE-2026-80231, activer CURLOPT_FORBID_REUSE limite l’exposition en empêchant la mise en pool des connexions concernées, au prix d’une perte de performance sur les charges de travail à fort volume de requêtes. Pour CVE-2026-80230, la seule vraie protection reste de ne jamais désactiver la vérification standard du certificat même lorsqu’un pinning de clé publique est en place, une pratique qui ne devrait de toute façon jamais être combinée.
Les équipes de sécurité qui gèrent un inventaire logiciel de type SBOM ont ici un exemple concret de son utilité. Identifier rapidement quels services embarquent une version de curl antérieure à 8.22.0, et dans quel backend TLS, permet de prioriser les correctifs sur les composants réellement exposés plutôt que de traiter l’ensemble du parc de façon uniforme.
Prédictions : ce qui attend curl et l’écosystème TLS
- D’autres bibliothèques HTTP et clients réseau devraient révéler des failles similaires de réutilisation de connexion mal isolée dans les prochains mois, à mesure que les outils d’audit automatisé élargissent leur couverture au-delà de curl.
- Le nombre de CVE liés à la validation de certificat dans des bibliothèques C historiques va probablement continuer de croître en 2026 et 2027, porté par une génération d’outils d’analyse plus systématique du code mémoire non sûr.
- Les distributions Linux à support étendu et les fournisseurs de firmware embarqué resteront la partie la plus lente à intégrer le correctif, prolongeant l’exposition réelle bien au-delà de la date de publication du 2 septembre.
- Les agences nationales comme l’ANSSI devraient multiplier les avis ciblant des bibliothèques transverses comme curl, plutôt que de se concentrer uniquement sur des produits finis, à mesure que la pression réglementaire NIS2 pousse les entités essentielles à cartographier leurs dépendances logicielles.
- La cohabitation de multiples backends TLS dans un même projet comme curl restera un facteur de complexité et de risque, ce qui pourrait renforcer les arguments en faveur d’une consolidation autour d’un plus petit nombre de bibliothèques cryptographiques largement auditées.
Foire aux questions
Qu’est-ce que curl et pourquoi cette bibliothèque compte-t-elle autant ?
curl est un outil et une bibliothèque logicielle, libcurl, utilisés pour transférer des données via des protocoles réseau comme HTTP, HTTPS ou FTP. Elle est intégrée dans un nombre extrêmement large de systèmes d’exploitation, d’applications et d’appareils connectés, ce qui en fait l’une des briques logicielles les plus déployées au monde.
Quelles versions de curl sont concernées par ces failles ?
Selon la faille, les versions affectées commencent entre 7.45.0 et 8.14.0 et s’étendent jusqu’à 8.21.0 incluse. La version 8.22.0, publiée le 2 septembre 2026, corrige l’ensemble des quatre failles cryptographiques ainsi que les six autres CVE du même lot.
Ces failles ont-elles été exploitées activement ?
Ni curl ni le CERT-FR ne mentionnent d’exploitation active ou de preuve de concept publique au moment de la publication de l’avis CERTFR-2026-AVI-1108 le 2 septembre 2026.
Pourquoi curl classe-t-il ces failles comme “faibles” alors qu’elles touchent le chiffrement ?
La sévérité tient compte des préconditions nécessaires à l’exploitation. Trois des quatre failles exigent une configuration spécifique du code appelant, comme un callback personnalisé, un changement de paramètre CA, ou une combinaison de pinning et de vérification désactivée, ce qui réduit fortement la probabilité qu’elles soient déclenchées par accident ou exploitées à grande échelle.
Qu’est-ce que le certificate pinning et pourquoi CVE-2026-80230 pose-t-il problème ?
Le certificate pinning consiste à épingler une clé publique précise pour une connexion, en plus ou à la place de la chaîne de confiance classique. CVE-2026-80230 montre que ce mécanisme peut échouer silencieusement lorsqu’il est combiné à une désactivation de la vérification standard du certificat, une configuration que les développeurs ne devraient jamais utiliser ensemble.
Comment savoir si mon système utilise une version vulnérable de curl ?
La commande curl –version affiche la version installée ainsi que le backend TLS utilisé. Pour un inventaire à grande échelle, un outil de génération de SBOM permet de recenser automatiquement les versions de curl et libcurl présentes dans l’ensemble d’un parc applicatif.
Que recommande le CERT-FR aux entreprises françaises ?
L’avis CERTFR-2026-AVI-1108 recommande d’appliquer le correctif dès que possible, conformément à la politique de gestion des vulnérabilités habituelle de l’ANSSI pour les bibliothèques largement déployées.
Cette publication va-t-elle ralentir les performances des applications qui utilisent curl ?
Seule la mitigation temporaire CURLOPT_FORBID_REUSE, recommandée en attendant une mise à jour vers 8.22.0, peut réduire les performances en empêchant la réutilisation de connexions. Une fois la mise à jour appliquée, aucune perte de performance n’est attendue puisque les correctifs traitent la gestion mémoire et la logique de validation sans désactiver la réutilisation de connexion elle-même.
