cURL et libcurl : plusieurs failles à corriger côté serveurs

Le CERT-FR a publié le 24 juin 2026 une alerte relative à de multiples vulnérabilités dans cURL et surtout libcurl, la bibliothèque réseau massivement intégrée dans des logiciels serveurs, des applications web, des agents d’automatisation et des images conteneurisées. Le point important, côté exploitation, est que le risque ne se limite pas à l’outil en ligne de commande curl utilisé par les administrateurs : toute application qui s’appuie sur libcurl pour initier des requêtes HTTP, HTTPS, FTP, SMTP, IMAP, LDAP ou d’autres flux réseau peut hériter du problème si elle embarque une version vulnérable.

Le message opérationnel relayé par le CERT-FR est clair : des correctifs éditeur sont disponibles et doivent être appliqués rapidement. Selon les vulnérabilités concernées, les impacts annoncés incluent du déni de service, de la fuite d’informations et d’autres problèmes de sécurité affectant les traitements réseau. Lorsque libcurl est utilisée dans une chaîne d’exécution côté serveur, l’exposition peut concerner des API backend, des workers applicatifs, des connecteurs vers des services tiers, des tâches CI/CD, des scripts d’exploitation, des collecteurs de supervision, des reverse proxies spécialisés ou encore des binaires embarqués dans des appliances et conteneurs.

La source à privilégier pour la qualification et la remédiation reste l’avis officiel du CERT-FR, « Multiples vulnérabilités dans cURL et libcurl », publié le 24 juin 2026, ainsi que les bulletins de sécurité de l’éditeur cURL mentionnés par cet avis. Le CERT-FR ne présente pas cette alerte comme un incident théorique : dans les environnements web modernes, libcurl est partout, souvent indirectement, via des dépendances système, des runtimes, des modules PHP, des bindings Python, des extensions applicatives ou des composants compilés statiquement dans des images de production. C’est précisément ce qui rend ce type de bulletin critique pour les équipes développement, DevOps et RSSI : le binaire /usr/bin/curl n’est qu’une petite partie de la surface réelle.

Quand une faille touche libcurl, plusieurs catégories d’actifs peuvent être concernées en parallèle :

les serveurs Linux exposant des applications qui effectuent des appels sortants vers des API partenaires ;
les plateformes PHP, Python, Ruby, Go ou Java qui s’appuient directement ou indirectement sur la bibliothèque ;
les jobs CI/CD déclenchant des téléchargements, des webhooks, des vérifications de santé ou des publications d’artefacts ;
les scripts d’automatisation d’exploitation utilisant curl pour piloter des services internes ;
les images conteneur de base qui embarquent une version vulnérable dans le système ou dans un binaire statique ;
les équipements ou logiciels serveurs tiers qui utilisent libcurl sans que cela soit visible au premier regard.

Dans un contexte francophone, cette alerte mérite une attention particulière chez les hébergeurs et opérateurs qui s’appuient sur des distributions Linux standard ou des images mutualisées, y compris chez des acteurs comme OVHcloud, Scaleway ou o2switch lorsque les équipes clientes administrent elles-mêmes leurs piles applicatives. Le correctif dépendra en pratique de la manière dont curl et libcurl sont fournis : paquet système, compilation manuelle, image Docker, dépendance applicative, bundle éditeur ou appliance.

Le CERT-FR relaie l’existence de plusieurs vulnérabilités, mais l’avis synthétique ne détaille pas nécessairement, dans son texte court, chaque identifiant, chaque score CVSS ou chaque sous-version corrigée pour toutes les branches maintenues. Lorsqu’un élément précis n’est pas explicitement exposé dans l’avis consulté, il faut s’appuyer sur les bulletins éditeur associés plutôt que supposer un numéro de CVE ou une plage de versions. En pratique, la bonne réponse opérationnelle consiste à recenser toutes les occurrences de curl et libcurl, puis à appliquer la version corrigée publiée par l’éditeur ou, côté distribution, le paquet de sécurité mis à disposition par le mainteneur du système.

Versions affectées

L’avis du CERT-FR du 24 juin 2026 signale que des branches maintenues de cURL et libcurl sont concernées, selon les indications de l’éditeur. Le point essentiel est que l’exposition ne se limite pas à une unique version majeure : les branches encore supportées par l’écosystème peuvent recevoir des correctifs spécifiques, et les distributions Linux peuvent rétroporter ces correctifs dans des paquets dont le numéro de version apparent diffère du numéro upstream.

Faute de reprendre ici des identifiants de versions qui ne seraient pas explicitement listés dans l’avis synthétique du CERT-FR, il faut retenir les règles suivantes, conformes aux pratiques de remédiation éditeur et distribution :

sont à considérer comme potentiellement affectées les versions de cURL et libcurl appartenant aux branches maintenues mentionnées par l’éditeur dans les bulletins relayés par le CERT-FR ;
sont à considérer comme corrigées les versions publiées par l’éditeur à la suite de l’annonce du 24 juin 2026, ou les paquets de sécurité fournis par votre distribution intégrant ces correctifs ;
si votre système affiche un numéro de paquet qui semble ancien, cela n’implique pas automatiquement une exposition : Debian, Ubuntu, Red Hat, AlmaLinux, Rocky Linux et d’autres distributions appliquent fréquemment des rétroportages de sécurité ;
à l’inverse, un conteneur ou un binaire compilé statiquement avec une ancienne copie de libcurl peut rester vulnérable alors même que l’hôte a été mis à jour.

Pour vérifier la version visible de l’outil en ligne de commande :

curl --version

Exemple de sortie à examiner :

curl 8.x.y (x86_64-pc-linux-gnu) libcurl/8.x.y OpenSSL/...

Cette commande donne une première indication, mais elle ne suffit pas à cartographier l’exposition réelle. Une application peut lier une autre bibliothèque libcurl que celle utilisée par le binaire curl du système, ou embarquer sa propre copie.

Pour identifier la bibliothèque installée par le système sur un hôte Linux :

ldconfig -p | grep libcurl

Pour interroger le paquet installé sur Debian et Ubuntu :

dpkg -l | grep -E 'curl|libcurl'

Pour interroger le paquet installé sur RHEL, AlmaLinux, Rocky Linux, CentOS Stream ou Fedora :

rpm -qa | grep -E '^curl|libcurl'

Dans les environnements conteneurisés, il faut vérifier chaque image, y compris les images intermédiaires utilisées en build :

docker run --rm <image> sh -c "curl --version || true; apk info 2>/dev/null | grep curl || true; dpkg -l 2>/dev/null | grep -E 'curl|libcurl' || true; rpm -qa 2>/dev/null | grep -E '^curl|libcurl' || true"

Sur Alpine Linux, très utilisée pour des images légères, la présence de curl ou de libcurl doit être vérifiée explicitement :

apk info | grep -E 'curl|libcurl'

Dans le cas des applications web, la bibliothèque peut aussi être consommée via des extensions ou bindings. Quelques exemples fréquents à auditer :

PHP avec l’extension curl ;
Python lorsque des composants natifs ou des wrappers s’appuient sur libcurl ;
Ruby via certains gems natifs ;
logiciels de sauvegarde, sondes de supervision, connecteurs SSO, outils d’import/export, ETL et middlewares ;
agents d’orchestration, runners CI/CD, scanners et outils de déploiement.

Le CERT-FR recommande d’appliquer les mises à jour de sécurité disponibles. En l’absence de liste exhaustive consolidée dans le bulletin bref, la méthode fiable consiste à consulter simultanément :

l’avis CERT-FR du 24 juin 2026 ;
les bulletins de sécurité officiels de l’éditeur cURL associés à cette publication ;
les avis de sécurité de votre distribution ou de votre fournisseur d’image ;
les notes de version des produits tiers qui embarquent libcurl.

Vecteur d’attaque

Le vecteur d’attaque décrit par le CERT-FR relève de l’exploitation à distance via des traitements réseau. C’est un point fondamental pour comprendre l’enjeu côté serveurs : même si l’administrateur n’utilise jamais manuellement la commande curl, l’instance peut être exposée dès lors qu’un composant applicatif traite des réponses distantes, suit des redirections, établit des connexions vers des services externes, télécharge des contenus ou relaie des flux sur la base de données reçues du réseau.

Concrètement, libcurl intervient dans de nombreux scénarios applicatifs classiques :

appel d’une API de paiement, de messagerie, de géocodage ou d’authentification ;
récupération de fichiers depuis un stockage objet ou un dépôt distant ;
envoi de webhooks vers des partenaires ou des outils internes ;
vérification de disponibilité d’une URL dans un système de monitoring ;
synchronisation de données avec un CRM, un ERP ou un SaaS ;
téléchargement d’artefacts dans une chaîne CI/CD ;
collecte de métadonnées depuis un service interne ou externe.

Dans ce type de contexte, un attaquant n’a pas nécessairement besoin d’un accès shell ou d’un compte local. Il peut parfois provoquer l’exposition en contrôlant, totalement ou partiellement, une réponse réseau traitée par le composant vulnérable. Selon la vulnérabilité précise, les effets possibles annoncés par le CERT-FR incluent notamment le déni de service et la fuite d’informations.

Pourquoi libcurl est plus critique que l’outil curl

curl est visible, documenté et souvent surveillé. libcurl, elle, est une dépendance d’infrastructure. Cela change tout en gestion du risque :

elle peut être appelée sans interaction humaine, en continu, dans des workers ou des cronjobs ;
elle peut être invoquée par du code métier qui ne mentionne jamais explicitement curl ;
elle peut être fournie par le système, par un conteneur, par un package tiers ou par un binaire compilé statiquement ;
elle se retrouve dans des chemins critiques de production, parfois avec des privilèges élevés ou un accès réseau étendu.

Cette ubiquité transforme une vulnérabilité de bibliothèque en risque transversal. Une équipe peut corriger l’hôte principal tout en oubliant un runner CI, une image de job, un sidecar ou un utilitaire interne qui continue à utiliser l’ancienne bibliothèque. C’est l’un des angles les plus importants de l’alerte CERT-FR : la dette de dépendance en environnement serveur.

Scénarios d’attaque concrets

Scénario 1 : application web appelant une API tierce. Une application métier reçoit une URL ou un identifiant d’objet, puis interroge un service externe via libcurl. Si la vulnérabilité affecte le traitement de certaines réponses réseau, un attaquant peut chercher à faire traiter une réponse malveillante ou inattendue par le backend. L’impact peut aller d’un plantage du worker à une fuite d’informations selon la faille concernée.

Scénario 2 : pipeline CI/CD. Un runner télécharge des dépendances, interroge une API Git, poste des statuts ou récupère des artefacts via un composant basé sur libcurl. Le service n’est pas exposé comme une application web publique, mais il dialogue en permanence avec des ressources réseau. Une vulnérabilité exploitable à distance peut alors affecter la disponibilité du pipeline ou exposer des données de build.

Scénario 3 : agent d’automatisation ou d’observabilité. Des scripts ou agents interrogent des endpoints internes, des dashboards, des services cloud ou des webhooks. Comme ces composants tournent souvent avec des secrets applicatifs, des certificats clients ou des accès réseau étendus, toute fuite d’informations peut avoir une portée supérieure au seul hôte compromis.

Scénario 4 : conteneur de production oublié. L’hôte a reçu le correctif, mais l’image applicative embarque une ancienne version de libcurl. Le service continue donc à être vulnérable malgré un parc apparemment à jour. Ce cas est particulièrement fréquent avec les images figées, les artefacts reproductibles et les appliances internes.

Impact opérationnel

Le CERT-FR mentionne des impacts de type déni de service, fuite d’informations et autres problèmes de sécurité selon la vulnérabilité. Pour les équipes exploitation et sécurité, cela implique plusieurs conséquences possibles :

arrêt ou redémarrage de processus métiers en cas de crash ;
dégradation de disponibilité sur des services utilisant intensivement des appels sortants ;
exposition de données en mémoire, de métadonnées de requêtes ou de contenus manipulés par la bibliothèque, selon la faille précise ;
effets en cascade sur des workflows automatisés, des tâches batch ou des intégrations SaaS ;
surconsommation de ressources si l’exploitation provoque des boucles de retry ou des erreurs répétées.

Dans un environnement web, le risque n’est donc pas uniquement « le serveur peut planter ». Une fuite d’informations sur un composant backend peut exposer des éléments utiles à une compromission ultérieure : portions de réponses, en-têtes, données de session techniques, jetons de service, chemins internes, noms d’hôtes ou comportements réseau détaillés.

Surface d’exposition souvent sous-estimée

Plusieurs équipes pensent spontanément à vérifier curl sur les bastions et serveurs applicatifs. C’est nécessaire, mais insuffisant. Les surfaces à examiner en priorité sont souvent les suivantes :

php-fpm et applications PHP utilisant l’extension curl ;
workers asynchrones exécutant des synchronisations avec des API partenaires ;
runners GitLab CI, GitHub Actions self-hosted, Jenkins agents et outils de déploiement ;
images Docker de build et de runtime ;
reverse proxies ou composants intermédiaires qui téléchargent des listes, des certificats ou des ressources distantes ;
outils d’administration, de monitoring et de sauvegarde ;
logiciels éditeurs installés hors dépôts système.

Un point de vigilance particulier concerne les environnements mutualisés ou managés où plusieurs couches coexistent : paquet système corrigé, mais extension applicative non reconstruite ; hôte à jour, mais conteneur ancien ; image de base corrigée, mais cache CI réinjectant un binaire statique vulnérable. C’est précisément le genre de situation où une alerte de bibliothèque peut perdurer après une remédiation partielle.

Comment patcher

Le CERT-FR recommande l’application rapide des correctifs fournis par l’éditeur et relayés par les mainteneurs de distributions. La remédiation exacte dépend de votre mode d’installation. Il faut viser la version corrigée publiée par l’éditeur ou le paquet de sécurité fourni par votre distribution.

Debian et Ubuntu

Mettre à jour l’index puis installer les versions corrigées des paquets curl et libcurl fournis par la distribution :

sudo apt update
sudo apt install --only-upgrade curl libcurl4 libcurl3-gnutls libcurl4-openssl-dev

Selon la version de la distribution et les paquets présents, tous ces noms ne seront pas installés. L’objectif est d’appliquer les mises à jour de sécurité disponibles pour les paquets liés à libcurl.

Vérification après mise à jour :

apt policy curl libcurl4
curl --version

RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora

Mettre à jour les paquets concernés via dnf :

sudo dnf upgrade curl libcurl

Sur certains environnements plus anciens utilisant encore yum :

sudo yum update curl libcurl

Vérification :

rpm -qi curl libcurl
curl --version

Alpine Linux

Dans les conteneurs et systèmes basés sur Alpine :

sudo apk update
sudo apk upgrade curl libcurl

Vérification :

apk info -v curl libcurl
curl --version

Images conteneur

Une mise à jour de l’hôte ne corrige pas une image déjà construite. Il faut reconstruire les images à partir d’une base corrigée, puis redéployer.

Exemple de Dockerfile de remédiation sur Debian ou Ubuntu :

FROM debian:stable
RUN apt update && apt install -y --only-upgrade curl libcurl4 && rm -rf /var/lib/apt/lists/*

Exemple sur Alpine :

FROM alpine:latest
RUN apk update && apk upgrade curl libcurl

Après reconstruction, il faut republier l’image, invalider les caches de build si nécessaire, puis redéployer tous les workloads dépendants.

Compilation manuelle ou bundle applicatif

Si curl ou libcurl ont été compilés manuellement, ou si un éditeur tiers embarque sa propre copie de la bibliothèque, la remédiation doit suivre la documentation du fournisseur concerné. Dans ce cas :

identifier le chemin du binaire ou de la bibliothèque chargée ;
installer la version corrigée publiée par l’éditeur ;
recompiler les logiciels liés statiquement ;
redémarrer les services consommateurs.

Exemple de recherche de bibliothèques sur un système Linux :

find / -name 'libcurl*.so*' 2>/dev/null

Exemple d’identification des dépendances d’un binaire :

ldd /chemin/vers/binaire | grep curl

Redémarrage des services

Une fois les paquets mis à jour, les processus déjà lancés peuvent continuer à utiliser l’ancienne bibliothèque chargée en mémoire. Il faut redémarrer les services concernés : serveurs web, workers, agents, runners, cron supervisés, conteneurs et services système.

Exemples :

sudo systemctl restart nginx
sudo systemctl restart apache2
sudo systemctl restart php8.2-fpm
sudo systemctl restart php-fpm
sudo systemctl restart gitlab-runner
sudo systemctl restart jenkins

Pour identifier les processus utilisant encore une ancienne bibliothèque après mise à jour, l’outil lsof peut aider :

sudo lsof | grep libcurl

Détection

Si le patch ne peut pas être appliqué immédiatement partout, il faut au minimum détecter où libcurl est présente et quels flux peuvent être affectés. La détection utile ici est avant tout une détection d’exposition et une détection d’anomalies réseau ou applicatives, plus qu’une recherche d’un unique IoC universel. Le CERT-FR évoque plusieurs vulnérabilités avec des impacts variés : il n’existe donc pas un indicateur de compromission unique valable pour tous les cas.

Inventaire technique

Commencer par un recensement des actifs qui utilisent curl ou libcurl :

serveurs Linux et VM ;
conteneurs en production et en build ;
images de base internes ;
runners CI/CD ;
applications web et workers ;
appliances logicielles et produits tiers.

Commandes utiles sur un hôte :

which curl
curl --version
ldconfig -p | grep libcurl
dpkg -l | grep -E 'curl|libcurl' || rpm -qa | grep -E '^curl|libcurl'

Recherche de références dans le code et les scripts :

grep -R "curl" /etc /opt /srv /var/www 2>/dev/null

Cette recherche ne détectera pas tous les usages de libcurl, mais elle permet de retrouver rapidement des scripts shell, des appels PHP curl_init, des wrappers, des images de build et des jobs d’automatisation.

Indicateurs d’exposition et symptômes

En l’absence d’IoC universels publiés pour l’ensemble des vulnérabilités signalées, les équipes doivent surveiller les signaux suivants sur les systèmes qui utilisent libcurl :

augmentation inhabituelle des erreurs réseau dans les logs applicatifs ;
plantages, segmentation fault ou redémarrages anormaux de workers, agents ou services ;
timeouts anormaux sur les appels sortants ;
boucles de retry sur les intégrations externes ;
hausse de la consommation CPU ou mémoire sur des processus traitant des flux réseau ;
différences inattendues dans les réponses HTTP ou les métadonnées journalisées ;
événements de sécurité corrélés à des échanges avec des endpoints non usuels.

Exemples de commandes de triage sur journaux système :

journalctl -p err -S "2026-06-24" | grep -Ei 'curl|libcurl|segfault|abort|timeout'

Sur des logs applicatifs centralisés, il est pertinent de rechercher :

les messages contenant curl, libcurl ou le nom de wrappers applicatifs ;
les erreurs réseau répétées sur un même endpoint ;
les réponses malformées ou anormalement volumineuses traitées juste avant un crash ;
les écarts de comportement entre environnements patchés et non patchés.

IoC et limites

Pour cette alerte, il faut être prudent : le CERT-FR parle de multiples vulnérabilités avec des effets distincts. Sans bulletin détaillé attribuant à chaque faille un ensemble d’indicateurs observables, il serait trompeur d’affirmer l’existence d’IoC spécifiques et universels. Les indicateurs les plus fiables à ce stade sont donc :

la présence d’une version vulnérable de curl ou libcurl sur un actif exposé ;
la présence de processus non redémarrés après mise à jour ;
des anomalies réseau ou des crashs sur des composants consommateurs de libcurl ;
des conteneurs ou binaires statiques non reconstruits.

Autrement dit, l’IoC principal est souvent un IoC de posture : un composant toujours vulnérable après publication du correctif.

Mitigation

Quand le patch immédiat est impossible, les mesures de mitigation doivent viser à réduire l’exposition des flux traités par libcurl et à limiter les conséquences d’un incident. Ces mesures ne remplacent pas le correctif éditeur, mais elles peuvent diminuer le risque à court terme.

Réduire la surface réseau

restreindre les sorties réseau des applications et workers au strict nécessaire via pare-feu, groupes de sécurité ou politiques Kubernetes ;
bloquer les destinations non approuvées pour les services qui n’ont besoin que d’un nombre limité d’API externes ;
forcer le passage par un proxy de sortie contrôlé lorsque c’est compatible avec l’architecture ;
désactiver temporairement certaines intégrations externes non essentielles si elles utilisent des composants non patchés.

Exemple de logique de mitigation : si un worker ne doit contacter que trois domaines partenaires, toute autre sortie doit être refusée. Cela ne corrige pas la faille, mais réduit la capacité d’un attaquant à faire traiter des réponses arbitraires.

Limiter les privilèges

exécuter les services consommateurs de libcurl avec des comptes dédiés et des droits minimaux ;
éviter de stocker des secrets sensibles en clair dans l’environnement des processus ;
segmenter les accès réseau des runners et agents d’automatisation ;
isoler les workloads traitant des contenus distants non maîtrisés.

Ces mesures sont particulièrement utiles lorsque l’impact possible inclut une fuite d’informations : moins le processus voit de données ou de secrets, moins la fuite potentielle est grave.

Durcir l’observabilité et le contrôle

augmenter temporairement le niveau de journalisation des composants réalisant des appels sortants ;
activer des alertes sur crashs, redémarrages répétés et erreurs réseau inhabituelles ;
surveiller les appels vers des endpoints externes nouveaux ou rares ;
contrôler les images et artefacts avec un scanner de dépendances ou de paquets système.

Dans les environnements d’hébergement français, y compris chez OVHcloud, Scaleway ou o2switch lorsqu’il s’agit de serveurs administrés par le client, cette phase de visibilité est souvent décisive : beaucoup d’équipes découvrent à cette occasion des usages de libcurl embarqués dans des jobs, des extensions ou des images anciennes.

Mesures applicatives temporaires

Selon l’architecture, certaines mesures temporaires peuvent être envisagées :

désactiver des fonctions de téléchargement ou de synchronisation non indispensables ;
mettre en file d’attente certains traitements plutôt que de les exécuter en temps réel ;
filtrer plus strictement les URL ou destinations soumises par des utilisateurs ou partenaires ;
encadrer les tailles de réponses, délais et politiques de retry au niveau applicatif ou proxy.

Ces choix doivent être évalués au cas par cas : ils peuvent réduire l’exposition au prix d’une dégradation fonctionnelle maîtrisée.

Comparaison avec les vulnérabilités de dépendances « oubliées »

Cette alerte illustre un schéma récurrent en sécurité applicative et infrastructure : une bibliothèque réseau très répandue devient un risque systémique parce qu’elle est présente à plusieurs niveaux de la pile. Le point commun avec d’autres crises de dépendances n’est pas nécessairement la nature technique de la faille, mais la difficulté opérationnelle à répondre vite et complètement :

inventaire incomplet des dépendances réelles ;
écart entre version système et version embarquée ;
retard de reconstruction des images et artefacts ;
absence de redémarrage des processus après mise à jour ;
produits tiers opaques sur leurs composants internes.

Pour les RSSI, c’est un rappel utile : la gestion des vulnérabilités ne doit pas s’arrêter aux dépendances applicatives déclarées dans composer.json, package-lock.json ou requirements.txt. Les bibliothèques système comme libcurl font pleinement partie de la surface d’attaque des services web.

La priorité immédiate est de suivre l’avis officiel du CERT-FR du 24 juin 2026 et les bulletins de sécurité de l’éditeur cURL associés, puis de vérifier que la correction a bien été propagée jusqu’aux conteneurs, runners, workers et produits tiers. En parallèle, un travail de fond sur l’inventaire des dépendances, la reconstruction systématique des images et le redémarrage contrôlé des services réduira fortement le risque de laisser une bibliothèque vulnérable active en production. Pour aller plus loin sur le durcissement, la réduction de surface et l’hygiène de remédiation côté serveurs, voir aussi les recommandations de la catégorie /categorie/pratiques.