Une vulnérabilité récemment divulguée et classée comme critique dans Jenkins permet à des attaquants non authentifiés de geler des serveurs à distance et de perturber des pipelines d’intégration continue au moyen d’une seule requête spécialement conçue.
La faille pourrait potentiellement toucher des millions d’installations dans le monde.
Cette attaque entraîne « … des threads de traitement des requêtes en attente indéfiniment », a déclaré Jenkins dans son avis de sécurité.
Comprendre la faille d’épuisement des threads de Jenkins
La vulnérabilité (CVE-2025-67635), trouve son origine dans la manière dont Jenkins gère les connexions de son interface de ligne de commande (CLI) basée sur HTTP.
Dans des conditions normales, Jenkins ouvre un thread pour traiter chaque requête CLI et est censé terminer correctement ce thread une fois la requête terminée ou échouée.
Cependant, des chercheurs ont découvert que lorsqu’une requête spécialement conçue corrompt le flux HTTP de la CLI, Jenkins ne nettoie pas correctement la connexion. Au lieu de fermer la session et de libérer les ressources, le thread concerné reste ouvert et bloqué, en attente indéfiniment.
Ce comportement crée une situation d’épuisement des ressources. Chaque requête malveillante monopolise un thread supplémentaire de traitement des requêtes, consommant progressivement le pool de threads disponibles sur lequel Jenkins s’appuie pour traiter les tâches légitimes, les appels d’API et les interactions des utilisateurs.
En envoyant de manière répétée des requêtes CLI malformées, un attaquant peut épuiser progressivement ces ressources jusqu’à ce que Jenkins ne soit plus en mesure de répondre aux nouvelles requêtes, provoquant de fait une situation de déni de service (DoS).
À ce stade, les pipelines peuvent se bloquer, les builds ne plus se déclencher et l’accès administratif au serveur peut être perturbé.
Ce qui rend cette faille particulièrement préoccupante, c’est la faible barrière à l’exploitation.
L’attaque ne nécessite ni authentification, ni interaction de l’utilisateur, ni techniques d’exploitation avancées.
Toute instance Jenkins qui expose la CLI HTTP sur le réseau est potentiellement vulnérable, les déploiements accessibles depuis Internet étant les plus exposés.
Bien qu’il n’existe actuellement aucune preuve publique d’une exploitation active, la simplicité du vecteur d’attaque et l’utilisation généralisée de Jenkins rendent les systèmes non corrigés particulièrement attractifs pour les attaquants.
Dans les environnements où Jenkins constitue le socle des pipelines CI/CD, même une interruption temporaire peut avoir des effets en cascade sur les flux de développement, de test et de déploiement.
Sécuriser les interfaces d’administration de Jenkins
Cette vulnérabilité de Jenkins montre comment des interfaces d’administration exposées peuvent introduire des risques de disponibilité lorsqu’elles ne sont pas correctement sécurisées et surveillées. Les équipes de sécurité devraient prendre les mesures suivantes :
- Mettre à niveau tous les contrôleurs et agents Jenkins vers la version 2.541 ou LTS 2.528.3 afin de corriger complètement la vulnérabilité d’épuisement des threads de la CLI HTTP.
- Réduire l’exposition en désactivant la CLI basée sur HTTP lorsqu’elle n’est pas nécessaire et en limitant l’accès à Jenkins via des VPN, des proxys inverses ou des passerelles zero trust.
- Appliquer des contrôles réseau tels que des listes blanches d’adresses IP, une limitation du débit ou des règles WAF afin de bloquer les requêtes HTTP malformées ou excessives ciblant les points de terminaison Jenkins.
- Surveiller l’état du système afin de détecter les signes d’abus, notamment les pics de trafic CLI HTTP, les threads actifs pendant une longue durée, une utilisation anormale du pool de threads ou des connexions bloquées.
- Activer une journalisation détaillée et des alertes concernant les métriques des threads Jenkins, l’activité de la CLI et les anomalies de connexion afin de faciliter la détection et la réponse précoces.
- Sécuriser les déploiements Jenkins en limitant les ressources des contrôleurs, en examinant les plugins et fonctionnalités exposés et en séparant les contrôleurs des agents de build afin de réduire le rayon d’impact.
Ensemble, ces mesures aident les organisations à protéger leurs infrastructures CI/CD critiques sans perturber les flux de développement.
Pourquoi la résilience des CI/CD est importante
Ce problème souligne la sensibilité des plateformes CI/CD aux défaillances de disponibilité lorsque les composants essentiels n’appliquent pas une gestion rigoureuse des ressources.
À mesure que les pipelines d’automatisation deviennent plus interconnectés et davantage exposés à des systèmes externes, des failles apparemment mineures dans la gestion des connexions peuvent se traduire par un impact opérationnel disproportionné.
Parallèlement, les infrastructures CI/CD continuent d’attirer l’attention des attaquants en raison de leur rôle central dans la fourniture des logiciels, ce qui renforce la nécessité d’appliquer rapidement les correctifs et d’adopter des pratiques de déploiement résilientes.
En définitive, cela montre comment les risques de disponibilité des plateformes CI/CD se rattachent au défi plus vaste de maintenir une chaîne d’approvisionnement logicielle sécurisée et résiliente.