curl 8.23.0 : un use-after-free en HTTP/2

Ce qui se passe

curl 8.23.0, sorti le 14 octobre 2026, corrige un use-after-free (CVE-2026-92392) dans la gestion des envois HTTP/2. Il touche curl et libcurl de 8.12.0 à 8.22.0 — l'outil en ligne de commande comme la bibliothèque que beaucoup d'autres programmes embarquent, dont l'extension curl de PHP, et il est là depuis février 2025.

curl le classe en gravité haute sur son échelle à quatre niveaux, sans score CVSS : la première depuis le dépassement de tas SOCKS5 d'octobre 2023. Le projet a raccourci son cycle de deux semaines pour livrer le correctif. Aucune attaque n'est connue.

Le mécanisme

L'attaque vient du serveur. Le client doit envoyer un fichier d'environ 135 Ko en HTTP/2 à un serveur contrôlé par l'attaquant, dont le certificat passe les contrôles. libcurl négocie HTTP/2 par défaut pour les URL https:// quand le serveur l'offre et que la bibliothèque est compilée avec.

libcurl suit chaque transfert avec un objet interne, l'easy handle. Pendant le nettoyage après la réinitialisation, curl signale d'abord à la couche HTTP/2 que le transfert est terminé, puis vide le reste de l'envoi dans la même connexion. Sans transfert enregistré, ces octets sont lus comme une nouvelle requête ; le fichier du chercheur est construit pour ressembler à des lignes de requête, ce qui ouvre un flux qui mémorise un pointeur vers l'objet.

La nouvelle tentative aboutit sur une connexion HTTP/1.1 et l'application libère l'objet. L'ancienne connexion, elle, garde le pointeur et s'en sert quand le serveur envoie une trame sur ce flux, par exemple à la sortie du programme. Dans l'exploit, les données du serveur retombent dans la mémoire du handle libéré : une requête sortante fait fuiter des adresses locales (de quoi contourner l'ASLR), puis un pointeur de fonction est écrasé et appelé.

La limite

L'exécution de code exige de connaître la version exacte de curl, l'architecture, l'allocateur de la libc et la disposition du tas, de caler deux transferts parallèles, et de faire tenir la charge utile dans environ 23 octets. Daniel Stenberg écrit que l'issue la plus probable d'une tentative est « un plantage » : c'est pourquoi la gravité est haute et non critique.

Que faire

• 8.12.0 à 8.22.0 : passer en 8.23.0
• branche 8.14.x : 8.14.3 · branche 8.16.x : 8.16.2 · branche 8.20.x : 8.20.2
• Debian 13 (trixie) : 8.14.1-2+deb13u7, par DSA-6558-1 ; Debian 12 (bookworm) ne contient pas le code vulnérable
• à défaut de mise à jour, forcer HTTP/1.1 : --http1.1 en ligne de commande, CURLOPT_HTTP_VERSION à CURL_HTTP_VERSION_1_1 dans le code. curl précise que c'est une demande : une connexion existante dans une autre version peut être réutilisée
• un build sans prise en charge de HTTP/2 n'atteint pas le chemin vulnérable

Le correctif est un réordonnancement de six lignes dans lib/multi.c, par Stefan Eissing : la couche HTTP/2 rend ses références à l'objet après le vidage des octets restants, et non avant. La 8.23.0 corrige 24 CVE au total ; les 23 autres sont de gravité basse. Pour vérifier la bibliothèque liée à votre runtime : curl --version, ou php --ri curl côté PHP.

D'où vient la trouvaille

Le rapport est arrivé le 15 septembre par HackerOne, confirmé en quelques heures. curl le crédite à « Luna with Claude, Anthropic » ; Stenberg dit qu'il est passé par l'OSS Scanner d'Anthropic, lancé le 8 octobre. Le même mainteneur écrivait en juillet 2025 qu'environ un cinquième des signalements reçus était du « bruit d'IA » : celui-ci n'en est pas.

Source : The Hacker News, 14 octobre 2026 ; avis de curl : CVE-2026-92392.