curl corrige une faille HTTP/2 d’exécution de code côté client

Contexte de la vulnérabilité

Le client en ligne de commande curl supporte le protocole HTTP/2 depuis plusieurs années. Une recherche indépendante a mis en évidence une faille liée à la gestion des requêtes d’upload sous HTTP/2. Le PoC publié montre que, lorsqu’un serveur malveillant envoie des trames spécialement formatées, le client peut être amené à exécuter du code arbitraire sur la machine qui lance curl. Cette situation expose les utilisateurs à des compromissions locales, même si curl est généralement considéré comme un outil de confiance.

Mécanisme de l’exécution de code

Le problème provient d’une mauvaise validation des métadonnées contenues dans les DATA frames d’HTTP/2. Le PoC exploite une corruption de mémoire qui se produit lors du décodage d’un champ d’en-tête contenant une taille anormale. La corruption conduit à un dépassement de tampon, permettant l’injection d’une séquence d’instructions qui s’exécutent dans le contexte du processus curl. Le vecteur d’attaque est purement côté client : aucun privilège spécial n’est requis sur le serveur cible.

Correctif apporté par curl

Après la diffusion du PoC, les mainteneurs de curl ont publié un correctif dans la branche stable. Le correctif renforce la vérification des tailles d’en‑tête et introduit des garde‑fous supplémentaires lors du traitement des trames HTTP/2. Le code modifié ajoute également des assertions qui déclenchent l’abandon du traitement dès la détection d’une incohérence, limitant ainsi la surface d’attaque. Les développeurs recommandent de mettre à jour curl vers la version contenant ce correctif dès que possible.

Implications pour les utilisateurs et recommandations

Les utilisateurs de curl sur des systèmes de production doivent vérifier la version installée et la comparer aux versions récentes disponibles dans leurs dépôts. Dans les environnements où curl est invoqué automatiquement (scripts, CI/CD, conteneurs), il est recommandé de reconstituer les images avec la version corrigée pour éviter la réintroduction du binaire vulnérable. Enfin, la découverte souligne l’importance de tester les implémentations HTTP/2 avec des scénarios d’upload complexes, car les spécifications du protocole laissent une marge d’erreur importante dans la gestion des flux de données.