Une faille de gravité élevée dans curl et libcurl modifie la manière habituelle d’aborder la sécurité côté client. CVE-2026-92392 se déclenche pendant un téléversement HTTP/2, mais l’acteur hostile se trouve sur le serveur qui reçoit ce téléversement. Un serveur malveillant peut envoyer une réponse particulière de réinitialisation de flux alors qu’un client transmet des données, laissant curl conserver une référence vers un objet déjà libéré. Il en résulte une corruption mémoire, et le projet curl indique que le défaut peut être transformé en exécution de code à distance lorsque des conditions exigeantes liées à la compilation, à l’architecture, à l’allocateur, au minutage et au protocole sont réunies.

Illustration éditoriale de cybersécurité : un téléversement HTTP/2 atteint un serveur tandis que des ingénieurs suivent un correctif curl et l’inventaire des dépendances.

Le correctif figure dans curl et libcurl 8.23.0, publiés le 14 octobre 2026. La plage concernée va de la version 8.12.0 à la version 8.22.0. Cette plage mérite de l’attention, car libcurl est souvent intégré à des applications, composants de systèmes d’exploitation, outils d’automatisation, gestionnaires de paquets, produits de sécurité et services qui n’annoncent pas leur utilisation de curl. Mettre à jour le binaire en ligne de commande sur le poste d’un administrateur peut donc laisser intactes les copies les plus importantes.

Il s’agit bien d’un problème de correctif, mais pas d’un simple scénario où il suffirait de lancer une mise à jour partout. La première tâche consiste à découvrir où curl est utilisé pour des téléversements HTTP/2, y compris par l’intermédiaire d’une bibliothèque ou d’une application liée statiquement. La deuxième consiste à déterminer si une réduction temporaire des capacités du protocole est praticable pendant que le correctif permanent progresse dans les paquets des fournisseurs et les fenêtres de changement en production. La troisième est de vérifier que les systèmes qui téléversent des fichiers peuvent être assurés de ne contacter que les destinations prévues.

Ce que CVE-2026-92392 affecte réellement

L’avis de sécurité de curl décrit une use-after-free dans le chemin de téléversement HTTP/2. Pendant un téléversement, le serveur peut émettre un RST_STREAM HTTP/2 avec la raison HTTP_1_1_REQUIRED ou REFUSED_STREAM. La connexion elle-même peut rester active tandis que le transfert individuel est interrompu. Dans l’automate vulnérable, curl nettoie ensuite le transfert et la connexion dans un ordre qui laisse une référence pendante vers l’objet du transfert.

Une use-after-free ne signifie pas automatiquement que chaque invocation aboutit à une exécution de code. Cela signifie que le logiciel continue à utiliser une zone mémoire après que son propriétaire l’a libérée. Selon ce qui occupe ensuite cette mémoire, le résultat immédiat peut être un plantage, un état corrompu, une fuite d’informations ou une défaillance de sûreté mémoire plus contrôlable. Dans ce cas, le projet curl classe le problème comme étant de gravité élevée et décrit un chemin allant de l’erreur mémoire à l’exécution de code à distance.

Les versions touchées sont curl et libcurl 8.12.0 à 8.22.0 incluses. Les versions antérieures à 8.12.0 ne sont pas affectées par cette faille précise, et la version 8.23.0 contient le correctif. La distinction entre curl et libcurl est importante sur le plan opérationnel : l’outil en ligne de commande n’est qu’un utilisateur de la bibliothèque, alors qu’un bien plus grand nombre d’applications peuvent appeler directement la bibliothèque. Un serveur qui n’exécute jamais le programme curl peut tout de même être exposé par une application liée à libcurl.

La vulnérabilité exige HTTP/2. Cela ne signifie pas que tout transfert HTTPS est automatiquement vulnérable, mais les équipes ne doivent pas conclure à la sécurité simplement parce que les utilisateurs n’ont pas passé explicitement une option HTTP/2. curl peut négocier HTTP/2 lorsqu’il se connecte à un service HTTPS qui le propose et lorsque la compilation locale inclut la prise en charge nécessaire. Les applications peuvent aussi sélectionner explicitement HTTP/2 au moyen d’options libcurl ou de frameworks réseau de plus haut niveau.

L’opération vulnérable est un téléversement du client vers le serveur. Les téléchargements ordinaires ne correspondent pas au scénario décrit dans l’avis. Cela réduit l’exposition, sans rendre le problème marginal. Agents de sauvegarde, éditeurs d’artefacts, clients de télémétrie, services d’ingestion documentaire, systèmes d’intégration continue, connecteurs cloud, outils d’assistance et logiciels de synchronisation envoient couramment des données vers l’extérieur. Certains n’utilisent curl que pour une petite étape d’un flux plus vaste, ce qui explique précisément pourquoi un simple inventaire des paquets peut manquer l’exposition concrète.

L’attaquant se trouve du côté qui reçoit les données

De nombreux plans de défense partent de l’hypothèse que le serveur dangereux est celui qui fournit un téléchargement. CVE-2026-92392 inverse ce modèle mental. Le client commence par envoyer des données à un serveur qu’il pense digne de confiance, et c’est ce serveur qui peut fournir le comportement protocolaire hostile.

Cela ne signifie pas qu’un attaquant peut exploiter n’importe quel processus curl simplement en publiant une page malveillante sur Internet. Le processus victime doit se connecter à un serveur contrôlé ou influencé par l’attaquant, effectuer un téléversement, négocier HTTP/2 et satisfaire les conditions d’implémentation nécessaires pour atteindre la séquence de nettoyage vulnérable. Dans un environnement réel, cela peut passer par un point d’accès volontairement malveillant, un service compromis, un flux redirigé, une destination d’envoi choisie par l’utilisateur ou une application qui accepte une configuration distante. Le chemin exact dépend du produit environnant.

Le projet curl énumère des conditions particulièrement précises pour transformer la faille en exécution de code. L’attaquant doit connaître la version exacte de curl et la disposition des objets, les caractéristiques de l’architecture cible, le comportement d’un allocateur libc et d’un tas compatibles, les effets prévisibles de nghttp2 et de TLS 1.3, ainsi que le minutage fin de transferts parallèles. L’exploit publié comporte également une contrainte liée à la brièveté de la commande. Ces exigences rendent une exploitation fiable difficile, mais ne justifient pas de considérer le problème comme inoffensif. Les chaînes d’attaque modernes commencent souvent par un plantage ou une corruption mémoire partielle, puis gagnent en précision à mesure que les détails de la cible sont disponibles.

Les informations publiques distinguent actuellement la possibilité d’exploitation de l’exploitation avérée. L’avis décrit une preuve de concept et un chemin vers l’exécution de code dans des conditions précises. L’entrée NVD ne fournit pas sa propre évaluation CVSS et n’indique pas que la vulnérabilité est exploitée dans la nature. Une preuve de concept publique reste néanmoins un signal important pour les défenseurs, surtout lorsque curl est intégré à des services durables ou mis à jour lentement. Elle ne prouve pas que chaque installation vulnérable a été compromise.

Pourquoi la version 8.23.0 demande une gestion attentive

Le correctif est arrivé dans une version coordonnée de curl qui corrige également 23 autres problèmes de sécurité publiés, dont la plupart sont classés de faible gravité par le projet. CVE-2026-92392 est le seul problème de gravité élevée de cette publication. Ce regroupement crée deux risques opérationnels opposés. Certaines équipes peuvent voir le grand nombre d’avis et suspendre la mise à niveau parce que l’opération semble complexe. D’autres peuvent mettre à jour un paquet curl visible en ligne de commande et supposer que toute la chaîne de dépendances est couverte.

La bonne réponse consiste à séparer l’urgence de l’uniformité. L’urgence est d’identifier les compilations vulnérables qui effectuent des téléversements et de déplacer ces systèmes vers un paquet fournisseur corrigé ou vers curl et libcurl 8.23.0. Le chemin d’implémentation peut varier selon le système d’exploitation, l’image de base d’un conteneur, le runtime d’un langage, une appliance ou une application commerciale. Un paquet libcurl maintenu par une distribution peut rétroporter le correctif sans modifier la version amont affichée comme l’attendrait un contrôle de version simpliste. Les équipes de sécurité doivent donc confirmer l’avis du fournisseur et le journal des changements du paquet, plutôt que de s’appuyer sur une seule comparaison de chaînes.

La publication modifie aussi d’autres aspects que le code de sécurité. Le projet a supprimé la prise en charge de SMB et de SMBS et introduit d’autres changements de comportement ainsi que des corrections de bogues. Cela ne rend pas la mise à niveau dangereuse, mais renforce la nécessité de tester les applications qui dépendent de protocoles moins courants, de flux d’authentification inhabituels, de backends TLS personnalisés ou d’une gestion stricte des fichiers. Le correctif de sécurité ne doit pas être retardé jusqu’à l’existence d’une suite de tests universelle parfaite, mais un déploiement progressif peut empêcher que la remédiation elle-même interrompe un service de téléversement critique.

Curl publie séparément les informations relatives aux versions standard et à ses branches Rock-solid. Les organisations qui utilisent une branche durable prise en charge doivent vérifier si la version appropriée est 8.14.3, 8.16.2 ou 8.20.2, plutôt que de la remplacer aveuglément par la branche standard la plus récente. La question déterminante n’est pas celle du numéro affiché par la page de téléchargement amont de l’outil en ligne de commande. Il faut savoir quel paquet pris en charge contient le correctif de CVE-2026-92392 et comment prouver que ce paquet est déployé.

Construire un inventaire utile pour cette vulnérabilité

Commencez par les installations évidentes, mais ne vous arrêtez pas là. Recherchez le programme curl dans les images de postes et de serveurs, interrogez les gestionnaires de paquets des systèmes d’exploitation, inspectez les couches de conteneurs, consultez les nomenclatures logicielles et examinez les manifestes de compilation pour libcurl. Les noms de paquets varient : un hôte peut exposer curl, libcurl, un paquet de développement ou un bundle runtime propre au fournisseur. La liaison statique peut faire disparaître la bibliothèque de la base de paquets ordinaire de l’hôte ; les manifestes de version applicative et les SBOM constituent donc des preuves précieuses.

Ajoutez ensuite le comportement à l’inventaire. Les éléments prioritaires sont les processus qui réunissent les conditions suivantes :

  • ils exécutent une compilation vulnérable de curl ou libcurl ;
  • ils téléversent des fichiers ou des corps de requête vers un service distant ;
  • ils autorisent la négociation HTTP/2 ou activent explicitement HTTP/2 ;
  • ils traitent des données ou des identifiants dont la perte aurait des conséquences.

Une bibliothèque vulnérable utilisée uniquement pour analyser des métadonnées locales ne doit pas recevoir le même traitement immédiat qu’un service d’automatisation exposé qui téléverse des identifiants, des artefacts de compilation, des documents clients ou des sauvegardes. Le classement du risque doit également tenir compte du contrôle de la destination. Une liste blanche fixe de points d’accès appartenant à un fournisseur ne représente pas la même exposition qu’un outil qui accepte une URL arbitraire fournie par un utilisateur, un paramètre de tâche, un webhook ou un fichier de configuration distant.

Pour les produits liés statiquement ou difficiles à inspecter, demandez au fournisseur trois réponses concrètes : le produit inclut-il curl ou libcurl dans la plage concernée, les téléversements HTTP/2 sont-ils possibles et quelle compilation contient le correctif ? Conservez la réponse avec la fiche de l’actif. Le fait que le produit utilise HTTPS ne suffit pas à établir son niveau d’exposition, et le fait qu’il n’affiche pas curl dans son interface ne répond pas à la question de ses dépendances intégrées.

Les environnements conteneurisés exigent une vérification supplémentaire. Mettre à jour l’hôte ne met pas à jour une ancienne image, et reconstruire une image applicative ne remplace pas forcément une bibliothèque curl copiée dans l’étape finale. Analysez à la fois l’image actuellement en production et celle qui sera promue ensuite. Si l’orchestrateur conserve d’anciennes répliques pendant un déploiement progressif, confirmez que chaque réplique active a quitté la plage affectée avant de fermer l’incident ou le ticket de vulnérabilité.

Mesures temporaires pendant le déploiement des correctifs

L’avis de curl recommande d’éviter HTTP/2 comme solution de repli lorsque la mise à niveau ou l’application du correctif n’est pas immédiatement possible. C’est une mesure d’atténuation, pas un remplacement de la remédiation. Dans un flux en ligne de commande, un opérateur peut parfois forcer HTTP/1.1 pour un transfert précisément défini. Pour une application, l’équivalent peut être une option de bibliothèque, une règle de proxy, une politique de service mesh ou un paramètre fourni par l’éditeur. Le contrôle doit être testé : désactiver HTTP/2 dans un wrapper ne sert à rien si l’application ouvre une autre connexion par un chemin de code distinct.

Une restriction temporaire du protocole peut aussi avoir des effets secondaires. Certains services exigent HTTP/2, utilisent le multiplexage des connexions pour le débit ou appliquent des comportements différents d’authentification et de délai selon le protocole. Documentez l’exception, désignez un responsable et fixez une date d’expiration. Une mesure qui reste en place indéfiniment parce que personne ne sait si elle est encore active devient un nouveau problème d’inventaire.

Lorsque c’est possible, limitez les destinations de téléversement pendant la période intermédiaire. Appliquez des listes de sortie pour les tâches automatisées, refusez les destinations fournies par l’utilisateur sauf nécessité explicite du flux et vérifiez les redirections au lieu de suivre silencieusement une chaîne vers un hôte inattendu. Ces mesures réduisent la probabilité qu’un client vulnérable atteigne un serveur récepteur malveillant, mais elles ne remplacent pas le correctif : une destination légitime peut être compromise et une liste trop large peut encore inclure une infrastructure contrôlée par un attaquant.

Ne réagissez pas en désactivant la vérification des certificats ou en affaiblissant TLS. Les conditions d’exploitation publiées incluent un serveur qui passe les vérifications de certificat du client ; cela rappelle que l’authentification ordinaire du transport ne suffit pas à se défendre contre un point d’accès compromis ou exploité de manière malveillante. Supprimer la vérification des certificats élargirait la surface d’attaque sans corriger le défaut de sûreté mémoire.

Que vérifier si un client vulnérable a été exposé

La présence d’une version vulnérable ne constitue pas une preuve de compromission, et un plantage ne prouve pas une exploitation. Un client de téléversement exposé mérite néanmoins un examen proportionné. Identifiez les destinations contactées pendant la période concernée, les fichiers ou corps de requête envoyés, la compilation exacte de curl ou libcurl et la négociation effective de HTTP/2. Les journaux applicatifs, journaux de proxy, données de télémétrie TLS et enregistrements de processus du terminal peuvent répondre à ces questions même lorsque curl ne consigne qu’une erreur de transfert générique.

Recherchez les arrêts anormaux, les nouvelles tentatives répétées vers un point d’accès inhabituel, une modification des processus enfants lancés par l’émetteur, des fichiers inattendus et des connexions sortantes apparues immédiatement après un transfert échoué. Ce sont des signaux de triage, pas des signatures propres à CVE-2026-92392. Un échec normal peut provoquer des nouvelles tentatives et un plantage peut entraîner un redémarrage ; l’interprétation doit donc être rapprochée du comportement attendu de l’hôte.

Si le processus avait accès à des identifiants, jetons, clés de signature ou fichiers locaux sensibles, évaluez cet accès séparément. La vulnérabilité publiée est un problème de sûreté mémoire côté client ; elle n’est pas décrite comme une faille directe de divulgation d’identifiants. Toutefois, une exécution de code réussie dans un émetteur pourrait exposer les privilèges et les données disponibles pour ce processus. Faites tourner les secrets lorsque l’enquête ne permet pas d’établir que le processus est resté dans ses limites prévues, et préservez les journaux pertinents avant leur suppression par la rétention habituelle.

Pour les systèmes de grande valeur, comparez la compilation vulnérable à la compilation corrigée et conservez les preuves de la mise à jour. Capturez la somme de contrôle du paquet ou le digest de l’image, la version du processus en cours et l’horodatage du déploiement. Si l’éditeur fournit un correctif ponctuel plutôt qu’une version amont, consignez son bulletin et l’identifiant de compilation du paquet. Ces éléments sont plus utiles qu’un commentaire de ticket indiquant que curl a été corrigé, surtout lorsque plusieurs copies de la bibliothèque coexistent sur le même hôte.

Ce que les développeurs doivent modifier

Les développeurs doivent considérer libcurl comme une partie de la frontière de sécurité de l’application, et non comme un utilitaire interchangeable dissimulé sous la logique métier. Épingler une version dans un fichier de compilation ne suffit pas si l’image runtime fournit une autre bibliothèque partagée, si l’image de base est ancienne ou si un gestionnaire de paquets résout une version vulnérable lors d’une reconstruction. Rendez la dépendance visible dans la SBOM et rendez son chemin de mise à jour reproductible.

Examinez le code de téléversement sous l’angle du contrôle de la destination, du comportement des redirections, de la logique de nouvelle tentative et de la sélection du protocole. Un service qui téléverse uniquement vers un point d’accès fixe n’a pas le même modèle de menace qu’un service acceptant des URL arbitraires. Une bibliothèque de nouvelle tentative peut ouvrir une deuxième connexion avec des options différentes de la première. Un proxy peut négocier HTTP/2 même si l’application ne l’a pas demandé explicitement. La revue de sécurité doit suivre le chemin réel de connexion plutôt que le fichier de configuration le plus pratique à consulter.

Limitez les privilèges des processus de téléversement. Exécutez-les avec les accès minimaux au système de fichiers, au réseau et aux identifiants nécessaires à leur tâche. Utilisez des identités distinctes pour lire un fichier local et le publier, et évitez de donner à un processus de transfert générique l’accès à des identifiants d’administration cloud, des clés de signature ou au socket du conteneur de l’hôte. Le principe du moindre privilège n’élimine pas la vulnérabilité, mais il peut transformer une exécution de code en incident limité au service plutôt qu’en compromission plus large de l’hôte.

Ajoutez des tests de chemins négatifs autour des transferts HTTP/2 interrompus, des réinitialisations serveur, des nouvelles tentatives et du nettoyage. Le but n’est pas de reproduire l’exploit en production ni de développer une capacité offensive. Il s’agit de vérifier que l’application gère sans danger un transfert échoué, que la dépendance corrigée est effectivement chargée et que les mécanismes de redémarrage et de reprise ne créent pas une seconde voie contournant la mise à jour.

Ce que les équipes d’exploitation doivent communiquer

La note interne la plus utile est précise : CVE-2026-92392 affecte curl et libcurl 8.12.0 à 8.22.0 ; le scénario vulnérable implique un téléversement HTTP/2 ; la version amont corrigée est 8.23.0 ; et les copies intégrées comptent. Évitez de demander à tous les employés de mettre à jour un navigateur ou de cesser d’utiliser Internet. La plupart des personnes n’exploitent pas les flux de téléversement concernés, et les avertissements indiscriminés rendent les prochaines alertes sérieuses plus difficiles à entendre.

Demandez aux responsables de service d’indiquer si leurs systèmes téléversent des données, quelles destinations ils contactent, si HTTP/2 est activé et quel paquet ou quelle image fournit curl. Donnez-leur une mesure temporaire vérifiable ainsi qu’un responsable de la mise à jour permanente. Cette méthode transforme une alerte de dépendance générale en une série de questions auxquelles il est possible de répondre.

La divulgation du projet curl offre également une leçon plus large. Un composant mature et très examiné peut encore contenir une faille sérieuse de sûreté mémoire. Ce constat ne doit pas déclencher un cycle de panique où les équipes remplacent des logiciels fiables par des alternatives non vérifiées. Il doit conduire à une meilleure visibilité des dépendances, à une propagation plus rapide des correctifs, à des privilèges de processus mieux maîtrisés et à des preuves plus claires de la manière dont les protocoles réseau sont négociés.

En résumé

CVE-2026-92392 mérite une priorité élevée parce qu’elle combine une large empreinte de dépendances avec un déclenchement côté serveur pendant les téléversements du client. Il ne s’agit pas d’une prise de contrôle distante universelle de chaque installation curl, et les conditions d’exploitation publiées sont exigeantes. L’absence actuelle d’un indicateur d’exploitation connue ne transforme pas pour autant un service de téléversement non corrigé en exception acceptable à long terme.

Trouvez chaque copie de curl et libcurl, identifiez celles qui téléversent en HTTP/2, mettez les compilations vulnérables à niveau vers une version corrigée prise en charge par le fournisseur et utilisez HTTP/1.1 ou des restrictions de destination uniquement comme contrôles temporaires. Conservez ensuite la preuve que le processus en cours, et pas seulement le fichier de compilation ou l’image de base, contient le correctif. C’est la réponse attendue face à cette vulnérabilité : précise, attentive aux dépendances et suffisamment calme pour repérer les copies dont personne ne se souvenait.

Sources