← L'édition
DevNouveau3 min de lecture

Gestion des vulnérabilités : le projet curl remporte un arbitrage officiel face à MITRE concernant un faux CVE

À la suite d'un désaccord avec le rapporteur d'un bogue bénin, Daniel Stenberg a défendu la décision de l'équipe curl de ne pas publier d'alerte de sécurité inutile. L'organisme MITRE a rendu son arbitrage final le 24 juin 2026 en confirmant la position du projet.

Fil « Contestation d'un identifiant de vulnérabilité CVE par l'auteur de curl »

Illustration de l'article — daniel.haxx.se
Image : daniel.haxx.se

Une gouvernance autonome des failles de sécurité

Le projet open source curl est enregistré en tant que CNA (CVE Numbering Authority, organisation habilitée à attribuer directement des identifiants de vulnérabilité). Cette autonomie permet à l'équipe de gérer les signalements en interne sans dépendre d'acteurs tiers. Depuis son adhésion, le projet a publié 57 identifiants CVE (Common Vulnerabilities and Exposures, registre public des failles de sécurité connues) après évaluation approfondie.

Avec une présence estimée à environ 30 milliards d'instances du composant libcurl dans le monde, la publication d'un CVE entraîne un coût massif pour l'écosystème. Chaque alerte déclenche des audits et des vagues de mises à jour chez les utilisateurs. Pour éviter de mobiliser inutilement les équipes d'ingénierie, l'équipe de curl applique une politique stricte : les anomalies dont la sévérité est jugée inférieure au niveau bas ne donnent pas lieu à l'émission d'un CVE.

L'origine du litige technique

Le différend concerne une alerte soumise fin 2025 portant sur la fonction Curl_cert_hostcheck(). Cette fonction vérifie si un nom d'hôte correspond à un certificat TLS (Transport Layer Security, protocole de sécurisation des échanges web) utilisant un masque générique (wildcard). Le bogue entraînait une validation erronée uniquement lors de la combinaison de plusieurs facteurs très spécifiques :

  • L'utilisation d'un nom d'hôte commençant par un point dans une URL (par exemple https://.example.com/).
  • Une résolution d'adresse effectuée hors du système DNS (Domain Name System, protocole de résolution des noms de domaine en IP), ce nom étant syntaxiquement invalide sur le réseau DNS traditionnel.
  • Une exécution reposant sur les moteurs TLS OpenSSL ou Schannel.
  • La présence d'un serveur malveillant disposant d'un certificat pour *.example.com et d'un accès local de l'attaquant pour modifier la résolution d'adresse.
# Exemple d'URL invalide en DNS mais provoquant le bogue dans la fonction de vérification
curl https://.example.com/

Ce comportement anormal a été corrigé dès le 8 décembre 2025 et agrémenté de tests unitaires. En raison des exigences extrêmes requises pour exploiter le problème, l'équipe a classé le risque comme théorique et a refusé de délivrer un identifiant CVE.

L'arbitrage final de MITRE

Le rapporteur de l'anomalie a contesté ce choix le 10 février 2026 en sollicitant l'organisme MITRE pour forcer l'attribution d'un CVE. Malgré des relances de l'organisme en mai et juin 2026, l'équipe de curl a maintenu ses arguments techniques.

Le 24 juin 2026, l'instance d'arbitrage MITRE TL-Root a clôturé le dossier en confirmant la décision du projet curl :

« Il s'agit d'un bogue, désormais corrigé sur la branche principale. Il n'est pas considéré comme une vulnérabilité de sécurité en raison de la nécessité d'un attaquant local disposant de privilèges pour l'exploiter. »

Cette décision marque la fin du premier litige de CVE rencontré par curl depuis son passage au statut de CNA, validant sa démarche de filtrage des alertes non pertinentes.