Jenkins LTS 2026 livre une mise à jour de sécurité majeure et confirme son statut de mainframe du CI/CD
Jenkins 2.541.2, publié le 18 février 2026, corrige deux vulnérabilités dont un XSS critique et durcit le noyau avec le Content Security Policy natif. Le dinosaure du CI/CD ne meurt pas — il devient le mainframe que personne n’ose migrer.
Le 21 janvier 2026, Jenkins publie la LTS 2.541.1 avec le Content Security Policy natif, Java 25 et un nouveau dépôt RPM unifié. Le 18 février 2026, la 2.541.2 corrige une XSS stockée critique et une fuite d’information sur les builds. Le 15 avril 2026, la ligne 2.555 exigera Java 21 minimum et abandonnera Java 17. En trois mois, Jenkins aura livré plus de correctifs de sécurité et de modernisation d’infrastructure que certaines plateformes concurrentes en un an — sans changer de paradigme. GitHub Actions et GitLab CI peuvent bien occuper les keynotes des cloud-native, Jenkins, lui, fait tourner la production.
Le paradoxe Jenkins — tout le monde veut le tuer, personne ne l’éteint
En 2026, dire qu’on déploie Jenkins en greenfield est devenu un aveu de legacy en conférence. Pourtant, Jenkins reste le serveur d’automatisation le plus déployé au monde, avec plus de 200 000 instances actives et un écosystème de plus de 2 000 plugins. Le projet ne publie pas de chiffres d’adoption précis — mais les statistiques de téléchargement du WAR stable et les métriques des update sites confirment un trafic comparable à celui des années fastes.
Le raisonnement est simple, et il est le même que celui qui maintient les mainframes IBM z/OS en production dans les banques et les assureurs : le coût de migration est prohibitif. Une pipeline Jenkins dans une grande entreprise, c’est dix ans de scripts Groovy, des centaines de jobs configurés à la main, des intégrations avec des outils internes qui n’existent nulle part ailleurs, et une équipe ops qui connaît chaque recoin du config.xml. Migrer vers GitHub Actions ou GitLab CI, c’est réécrire tout ça — sans business value immédiate pour le justifier au comité de direction.
Jenkins n’est donc pas mort. Il est devenu le mainframe du CI/CD : personne ne le choisit pour un projet neuf, mais personne ne peut l’éteindre.
2.541.2 — deux CVE, une XSS critique et un signal
La 2.541.2, publiée le 18 février 2026, est une patch release de sécurité. Son volume de changements est maigre : deux CVE et deux correctifs de bugs. Mais son contenu est un concentré de ce qui fait la crédibilité de Jenkins en environnement régulé.
CVE-2026-27099 (CVSS High) est une XSS stockée dans la description de la cause de mise hors ligne des agents. Depuis la version 2.483, le champ « Mark temporarily offline » acceptait du HTML sans échappement. Un attaquant avec le droit Agent/Configure ou Agent/Disconnect pouvait injecter du JavaScript exécutable par tout utilisateur consultant la page de l’agent. La 2.541.2 échappe désormais le contenu — et le CSP introduit en 2.541.1 atténuait déjà l’impact pour les instances l’ayant activé.
CVE-2026-27100 (CVSS Medium) est une fuite d’information via le paramètre Run Parameter : un utilisateur avec Item/Build et Item/Configure pouvait énumérer l’existence de builds auxquels il n’avait pas accès. Le correctif rejette les valeurs de paramètre pointant vers des builds inaccessibles.
Ces deux vulnérabilités ont été rapportées via le Bug Bounty Program financé par la Commission européenne et opéré par YesWeHack — un programme lancé en décembre 2025 qui porte déjà ses fruits. C’est un indicateur de maturité que peu de projets open source de l’âge de Jenkins peuvent revendiquer.
Le 18 février 2026, la 2.541.2 corrige aussi deux bugs : une régression rare sur les soumissions de formulaires (JENKINS-76249) et la perte de l’état temporarily offline des agents après une sauvegarde de configuration. Rien de spectaculaire — mais chaque bug corrigé dans une LTS est un administrateur qui ne passera pas sa nuit à debugger un pipeline cassé.
CSP natif — la vraie modernisation de 2.541
La ligne 2.541, initiée le 21 janvier 2026, est la première à embarquer le Content Security Policy dans le noyau Jenkins — sans plugin externe. C’est un changement structurel qui mérite qu’on s’y arrête.
Avant 2.541.1, le CSP était géré par le plugin csp (Content Security Policy Plugin), une couche optionnelle que la plupart des installations ignoraient. Désormais, Jenkins fournit une API native permettant à chaque plugin de déclarer les catégories de ressources qu’il a besoin de relâcher (scripts, styles, connexions), avec une traçabilité par plugin plutôt qu’une règle globale opaque. Le CSP est désactivé par défaut pour préserver la rétrocompatibilité, mais l’infrastructure est en place.
L’impact est concret : une XSS comme la CVE-2026-27099 devient moins exploitable sur les instances ayant activé le CSP. Jenkins ne se contente pas de patcher les failles une par une — il construit la couche de défense qui limitera la prochaine.
La 2.541.1 apporte aussi le support de Java 25, un dépôt RPM unifié pour Red Hat et openSUSE (fin des URLs distinctes /redhat-stable et /opensuse-stable), une nouvelle clé de signature GPG pour les paquets DEB et RPM, et des images conteneur pour Windows Server 2022. En arrière-plan, Winstone (le conteneur servlet embarqué) a relevé la taille maximale des en-têtes HTTP à 32 Ko pour accommoder les règles CSP complexes.
Ces changements ne feront pas la une de Hacker News. Mais pour un administrateur qui maintient vingt instances Jenkins sur des serveurs Red Hat en environnement régulé, c’est la différence entre une mise à jour qui casse tout et une mise à jour qui passe.
Jenkins vs le cloud-native — pourquoi le mainframe tient
Le marché du CI/CD en 2026 est structuré par deux forces opposées. D’un côté, GitHub Actions et GitLab CI dominent le greenfield : YAML natif, intégration git-push-to-deploy, serverless runners, facturation à l’usage. De l’autre, Jenkins domine le brownfield — les parcs existants, les environnements régulés, les pipelines complexes qu’aucun YAML ne peut exprimer sans script steps.
Le tableau ne raconte pas une compétition — il raconte une segmentation fonctionnelle. Jenkins est l’outil des pipelines complexes, héritées, on-prem, régulées. GitHub Actions et GitLab CI sont les outils du cloud-native standardisé. Personne ne migre ses 500 jobs Jenkins vers GitHub Actions pour le plaisir — et personne ne déploie Jenkins pour un projet Node.js de trois contributeurs.
La vraie question n’est pas « lequel est le meilleur ? » — elle est « combien coûte la migration de votre existant ? ». Tant que la réponse sera « plusieurs années-homme sans ROI immédiat », Jenkins restera allumé.
Le programme Bug Bounty — Jenkins muscle sa sécurité à l’échelle européenne
Un point souvent négligé dans la comparaison avec les plateformes propriétaires : Jenkins est le seul outil CI/CD auto-hébergé à bénéficier d’un Bug Bounty Program financé par une institution publique. Le programme, lancé en décembre 2025 avec la Commission européenne et YesWeHack, a déjà produit des résultats tangibles : les deux CVE du 18 février 2026 en sont issues.
GitHub et GitLab ont leurs propres programmes de bug bounty, mais ils couvrent des plateformes dont le code source du runner n’est pas toujours intégralement ouvert (GitHub Actions runner). Jenkins, lui, est auditable de bout en bout — et désormais, des chercheurs indépendants sont payés pour le faire.
Pour un RSSI qui doit justifier le maintien de Jenkins face à une migration vers une solution SaaS, c’est un argument qui pèse : un outil audité publiquement, avec des CVE traçables et des correctifs dans la LTS, plutôt qu’une plateforme dont le runtime est une boîte noire opérée par un tiers.
Le verdict
Si votre parc Jenkins est supérieur à 50 jobs et que vos pipelines utilisent du Groovy custom, des plugins métier ou des intégrations avec des outils internes, la 2.541.x est une mise à jour à planifier maintenant — pas pour les features, mais pour le CSP natif qui réduira la surface d’attaque de la prochaine XSS, et pour la nouvelle clé GPG qui conditionne les futurs correctifs de sécurité. Activez le CSP après la mise à jour.
Si vous êtes un nouvel entrant avec un projet standard (Node.js, Python, Go) et zéro contrainte on-prem, Jenkins n’est pas pour vous. GitHub Actions ou GitLab CI couvriront vos besoins sans la charge d’administration d’un contrôleur Java. Vous n’êtes pas la cible de cette LTS.
Si vous êtes une grande entreprise régulée avec des centaines de pipelines Jenkins et une équipe ops dédiée, la question n’est pas « dois-je migrer ? » — elle est « comment je sécurise ce que j’ai en attendant que le ROI de la migration devienne positif ? ». La réponse tient dans la 2.541.2 et dans l’activation du CSP. Jenkins ne disparaîtra pas plus vite que les mainframes — alors autant le maintenir à jour.
Le mainframe du CI/CD ne s’éteint pas. Il se patche. Et c’est très bien comme ça.
Références
- Jenkins 2.541.2 Changelog, jenkins.io, 18 février 2026.
- Jenkins Security Advisory 2026-02-18, jenkins.io, 18 février 2026.
- Jenkins 2.541.1 Changelog, jenkins.io, 21 janvier 2026.
- Upgrading to Jenkins LTS 2.541.x, jenkins.io.
- Jenkins 2.541.x (LTS) — What’s New, Support Lifecycle & EOL, VersionLog.
- Jenkins LTS Changelog, jenkins.io.
- Jenkins End of Life Dates, endoflife.date.
- Jenkins Bug Bounty Program sponsored by the European Commission, jenkins.io, 10 décembre 2025.