curl corrige une faille HTTP/2 de gravité élevée permettant l'exécution de code côté client

Le projet curl a publié la version 8.23.0 le 14 octobre pour corriger une vulnérabilité de gravité élevée permettant à des serveurs malveillants de corrompre la mémoire du client lors de téléchargements HTTP/2. La faille, identifiée sous la référence CVE-2026-92392, a été découverte par Luna Tong d'Anthropic et affecte toutes les versions de curl et libcurl depuis la 8.12.0 jusqu'à la 8.22.0.

Ce qui s'est passé

Cette vulnérabilité permet à un serveur contrôlé par un attaquant de déclencher une exécution de code à distance sur la machine cliente effectuant le téléversement de données. L'attaque nécessite que le client téléverse un fichier d'environ 135 Ko via HTTP/2 vers un serveur malveillant dont le certificat passe les vérifications de validation standard. Bien que l'impact théorique inclue une compromission totale du système, les mainteneurs de curl notent qu'une exploitation réussie est difficile et aboutirait probablement à un plantage plutôt qu'à une exécution de code dans la plupart des scénarios réels.

Le bug était présent dans chaque version de curl depuis la 8.12.0, sortie en février 2025. Il s'agit de la première faille de gravité élevée pour le projet depuis le dépassement de tas (heap overflow) SOCKS5 en octobre 2023. En réponse à cette découverte, l'équipe de curl a raccourci son cycle de publication régulier de huit semaines de deux semaines afin de livrer le correctif rapidement. Aucune exploitation active utilisant cette vulnérabilité n'a été signalée dans la nature jusqu'à présent.

Le correctif traite au total 24 CVEs dans cette version, bien que les 23 autres soient classées comme de faible sévérité. Le projet a également mis à jour sa ligne de support à long terme, connue sous le nom de releases Rock-solid curl, pour s'aligner avec ce correctif de sécurité. Les utilisateurs sur des branches plus anciennes prises en charge doivent mettre à niveau vers des versions spécifiques corrigées : 8.14.3 pour la branche 8.14.x, 8.16.2 pour la 8.16.x, et 8.20.2 pour la 8.20.x.

Comment cela fonctionne

La vulnérabilité est une erreur d'utilisation après libération (use-after-free) liée à la gestion des transferts HTTP/2 par libcurl. HTTP/2 permet plusieurs flux concurrents sur une seule connexion, et libcurl suit chaque transfert à l'aide d'un objet appelé handle facile (easy handle). Lors d'un téléversement, un serveur malveillant peut bloquer le transfert en définissant la taille de fenêtre HTTP/2 à zéro, en renvoyant une partie de la réponse, puis en réinitialisant le flux tout en maintenant la connexion sous-jacente ouverte. Curl interprète cette réinitialisation comme un signal pour relancer le transfert.

Lors de la phase de nettoyage de cette logique de nouvelle tentative, curl informait auparavant la couche HTTP/2 que le transfert était terminé avant de vider les données restantes non envoyées du téléversement. Cet ordre signifiait que les octets restants étaient écrits sur une connexion sans transfert enregistré. Si ces octets ressemblaient à des lignes de requête HTTP, curl ouvrait un nouveau flux et stockait un pointeur vers le handle facile. Lorsque l'application finissait par libérer le handle après avoir terminé la nouvelle tentative sur une nouvelle connexion HTTP/1.1, l'ancienne connexion conservait toujours un pointeur pendu vers cette mémoire libérée.

Un attaquant pouvait ensuite envoyer des données sur l'ancien flux qui atterrissaient dans l'espace mémoire récemment libéré. En divulguant des adresses locales pour contourner la randomisation de la disposition de l'espace d'adressage (ASLR), l'attaquant pouvait écraser un pointeur de fonction dans cette mémoire. Lorsque curl appelait ensuite ce pointeur, il exécutait le code de l'attaquant. Le correctif, une réorganisation de six lignes dans lib/multi.c par Stefan Eissing, garantit que la couche HTTP/2 ne libère ses références au handle qu'après que toutes les données restantes ont été vidées.

Détails clés

• Versions affectées : curl et libcurl 8.12.0 à 8.22.0.
• Versions corrigées : Mettez à niveau vers la 8.23.0, ou vers 8.14.3, 8.16.2 et 8.20.2 pour les branches plus anciennes.
• Vecteur d'attaque : Serveur malveillant recevant un téléversement HTTP/2 d'environ 135 Ko.
• Sévérité : Classée Élevée par le projet curl ; aucun score CVSS publié.
• Découverte : Signalée par Luna Tong d'Anthropic via HackerOne le 15 septembre.
• Atténuation : Désactivez HTTP/2 en utilisant --http1.1 ou CURLOPT_HTTP_VERSION_1_1 si la mise à jour immédiate n'est pas possible.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes DevOps, cet incident met en lumière les risques inhérents aux bibliothèques d'infrastructure largement utilisées. Curl est intégré dans d'innombrables applications, allant des scripts en ligne de commande aux services backend complexes. Comme libcurl négocie HTTP/2 par défaut pour les URL HTTPS lorsque le serveur le prend en charge, de nombreuses applications peuvent être vulnérables sans modifications explicites de configuration. Le fait que la vulnérabilité nécessite un environnement de build spécifique et un timing précis pour être exploitée ne nie pas le risque, surtout pour les attaques ciblées contre des infrastructures connues.

Le processus de découverte signale également un changement dans la manière dont les vulnérabilités de sécurité open source sont trouvées. Le rapporteur a utilisé OSS Scanner d'Anthropic, un outil piloté par IA qui scanne les projets open source et envoie les résultats sans revue humaine. Cela soulève des questions sur l'avenir de la recherche de vulnérabilités, alors que les modèles d'IA deviennent capables d'identifier des bugs de corruption mémoire complexes que le fuzzing traditionnel pourrait manquer. Cependant, cela introduit aussi du bruit, car les mainteneurs ont noté une augmentation des rapports générés par IA de faible qualité.

Ce que vous pouvez faire

• Vérifiez votre version actuelle de curl en exécutant curl --version et mettez à niveau immédiatement vers la 8.23.0 ou une version de branche corrigée.
• Si vous ne pouvez pas mettre à jour tout de suite, forcez HTTP/1.1 dans vos applications en définissant CURLOPT_HTTP_VERSION sur CURL_HTTP_VERSION_1_1.
• Vérifiez si votre build de libcurl inclut la prise en charge HTTP/2 ; sinon, vous n'êtes pas vulnérable à cette faille spécifique.
• Surveillez les trackers de sécurité Debian si vous utilisez Debian 13 (trixie), qui a reçu le patch 8.14.1-2+deb13u7 via DSA-6558-1.
• Passez en revue tous les conteneurs Docker personnalisés ou pipelines CI/CD qui intègrent d'anciennes versions de curl pour les transferts de fichiers.
• Envisagez de désactiver HTTP/2 dans les services internes où il n'est pas strictement nécessaire afin de réduire la surface d'attaque.