Mise à jour de sécurité cURL prévue le 14 octobre : préparez vos tests API
cURL a avancé sa prochaine version après le signalement d’une vulnérabilité de gravité élevée (HIGH). Le 7 octobre, son mainteneur Daniel Stenberg a annoncé que la version 8.23.0 était prévue pour le 14 octobre 2026, avec des correctifs pour 22 vulnérabilités. Le problème de gravité élevée porte l’identifiant CVE-2026-92392 ; ses détails techniques doivent être publiés en même temps que la version. Consultez l’annonce du mainteneur (en anglais).
Pour les développeurs qui utilisent cURL afin de vérifier des sites, d’appeler des API ou de diagnostiquer des environnements de préproduction, c’est le moment de se préparer. Vous pouvez recenser vos installations et préparer quelques requêtes reproductibles dès maintenant, puis vérifier qu’elles se comportent toujours comme prévu après la mise à jour.
Notre créateur de commandes cURL aide à préparer ces requêtes. Si votre préproduction utilise la protection par mot de passe d’Apache, le générateur htpasswd peut aussi vous aider à créer un compte de test dédié.
Que sait-on et que reste-t-il à préciser ?
Au 8 octobre, l’annonce confirme la date prévue, le nombre de correctifs, ainsi que l’identifiant et la gravité du problème le plus sérieux. Elle ne précise ni les conditions qui déclenchent cette faille ni les versions concernées. Elle indique également que des mises à jour de Rock-solid curl sont prévues au même moment.
Cette limite est importante : l’annonce seule ne permet pas de savoir si une installation donnée est exposée. Consultez la liste officielle des vulnérabilités cURL (en anglais) et l’avis de votre fournisseur de logiciel lorsque les détails seront disponibles. Les exemples ci-dessous sont des contrôles de fonctionnement ordinaires, pas des tests de la vulnérabilité encore non divulguée.
Identifiez l’installation de cURL réellement utilisée
Commencez dans l’environnement où vous exécutez habituellement vos requêtes :
curl --version
La sortie identifie cURL, la version de libcurl à laquelle il est lié et les bibliothèques associées, puis les protocoles et fonctionnalités pris en charge. L’option de version du manuel cURL (en anglais) explique ces champs.
Dans PowerShell, utilisez curl.exe --version pour éviter un éventuel alias vers une autre commande. Le cURL fourni par Microsoft est maintenu séparément des versions distribuées par le projet cURL, comme l’expliquent les notes d’installation Windows (en anglais).
Pour préparer vos mises à jour, dressez un court inventaire :
| Environnement | Informations à noter |
|---|---|
| Terminal de développement | Emplacement de l’exécutable, version et source d’installation. |
| Tâche d’intégration continue ou conteneur | Version dans la tâche ou l’image exécutée, et responsable de sa mise à jour. |
| Application utilisant libcurl | Informations sur les dépendances de l’application et consignes de mise à jour de son fournisseur. |
Vérifiez la version dans chaque terminal ou conteneur concerné. Traitez séparément une application qui intègre libcurl : la sortie de l’exécutable de votre terminal ne prouve pas quelle bibliothèque cette application utilise.
Préparez une petite requête reproductible
Choisissez un point d’accès en lecture seule dont vous connaissez la réponse attendue. Dans le créateur de commandes cURL, sélectionnez GET, saisissez l’URL et activez Accepter les réponses JSON si cela convient. Copiez la commande générée et conservez-la avec une note sur le statut et les champs de réponse attendus.
Par exemple :
curl \
--request 'GET' \
--url 'https://example.com/api/status' \
--header 'Accept: application/json'
L’URL sert d’illustration ; remplacez-la par un point d’accès que vous contrôlez. Ces exemples sur plusieurs lignes utilisent la syntaxe des shells POSIX, dont Bash et Zsh, et non celle de PowerShell ou de l’invite de commandes Windows.
Pour enregistrer les en-têtes de réponse séparément, ajoutez manuellement ces options à la commande copiée :
curl \
--request 'GET' \
--url 'https://example.com/api/status' \
--header 'Accept: application/json' \
--dump-header 'before-update-headers.txt' \
--output 'before-update-body.json'
--dump-header enregistre les en-têtes reçus et --output le corps ; les deux sont décrits dans la référence des options cURL (en anglais). Choisissez des noms de fichiers inutilisés, car ces sorties peuvent écraser des fichiers existants. Le créateur ne propose pas actuellement de commandes dédiées à ces deux options.
Après la mise à jour, répétez la requête avec des noms de fichiers commençant par after-update-. Comparez le statut, les en-têtes pertinents et les champs attendus du corps. Les dates, identifiants de requête et autres valeurs variables peuvent légitimement différer. Des requêtes réussies aident à vérifier la compatibilité ; elles ne prouvent pas qu’un correctif de sécurité est installé.
Le créateur génère le texte de la commande localement dans votre navigateur. Il ne contacte pas le point d’accès et ne met pas cURL à jour. C’est l’exécution de la commande copiée dans votre terminal qui envoie la requête.
Vérifiez aussi l’authentification de votre préproduction
Si vous protégez déjà une préproduction Apache par authentification HTTP Basic, incluez dans vos contrôles une requête sans authentification et une autre utilisant un compte de test dédié.
Le générateur htpasswd crée une entrée username:hash pour le fichier de mots de passe du serveur. Choisissez bcrypt si le serveur le prend en charge, installez l’entrée hors du répertoire public du site et configurez Apache pour l’utiliser. Générer une entrée ne suffit pas à activer le contrôle d’accès ; suivez l’exemple de configuration de l’outil et le guide d’authentification Apache.
Pour un utilisateur de test nommé release-check, une requête dans le terminal peut ressembler à ceci :
curl --user 'release-check' \
--url 'https://example.com/private/'
cURL demande le mot de passe lorsque vous fournissez uniquement le nom d’utilisateur. Saisissez le mot de passe d’origine, pas l’empreinte générée. Utilisez HTTPS, car l’authentification Basic ne chiffre pas elle-même les identifiants. Consultez le guide d’authentification HTTP de cURL (en anglais).
Vérifiez que la ressource protégée refuse une requête sans authentification et renvoie le contenu attendu pour le compte de test. N’incluez pas les identifiants dans les exemples enregistrés et examinez les en-têtes capturés avant de les partager, car les réponses peuvent contenir des cookies. Ce contrôle porte sur votre préproduction ; la protection par mot de passe ne corrige pas une vulnérabilité de cURL.
Lorsque la version sera disponible
Lisez les avis publiés pour déterminer les versions et configurations concernées. Obtenez la mise à jour adaptée auprès du fournisseur responsable de chaque installation, puis répétez vos contrôles de version et de fonctionnement dans ces mêmes environnements. Pour un paquet maintenu par un fournisseur, consultez son avis de sécurité en plus du numéro de version du projet d’origine.
Une petite requête documentée facilite ce suivi. Commencez avec le créateur de commandes cURL ou consultez notre guide des commandes cURL pour d’autres exemples de corps de requête, de redirections et de délais d’attente.