Every Jenkins LTS Except the Newest
Is Now Permanently Vulnerable
On August 5, the Jenkins project published a security advisory covering 21 vulnerabilities. One of them stands apart: CVE-2026-70426, a critical flaw in the Remoting library that allows code running on a build agent — or an attacker holding Agent/Connect permission — to execute code on the Jenkins controller. Rated 9.0 Critical in the National Vulnerability Database, it is fixed in exactly two places: weekly release 2.576 and LTS 2.568.2.
The advisory states the affected range plainly: Jenkins weekly through 2.575, LTS through 2.568.1. What it does not spell out — because inside the Jenkins project it goes without saying — is what "and earlier" means for the thousands of installations still running older LTS lines. That is the part this article is for.
What CVE-2026-70426 actually is
Jenkins protects its controller from malicious serialized objects with a class filter called JEP-200 — an allowlist deciding which classes may cross the wire from agents. The advisory's finding, verbatim: "The JEP-200 class filter is not applied to classes resolved via a fallback path in the Remoting deserialization implementation." In practice, the fence has a gap: agent processes, any code running on agents, and attackers with Agent/Connect permission can slip objects past the filter and leverage classes on the core classpath to run code on the controller.
The severity comes from what a Jenkins controller is. It is the machine that holds credentials for source control, artifact registries, cloud accounts, and production deployment. The attack path does not require an internet-facing controller — it runs through the agents, which execute your builds, which execute your dependency tree. Every `npm install` in every pipeline happens on the attack side of this boundary. Controller compromise via a poisoned build dependency is not a theoretical chain; it is the modern supply-chain attack pattern, and this vulnerability is a bridge across its last gap.
The part the advisory doesn't spell out: "and earlier" means forever
Jenkins runs a rolling LTS model: roughly every 12 weeks a new baseline is chosen, and the previous line stops receiving anything — including security fixes. There is no overlap window, no extended maintenance, no backport program for superseded lines. The policy is published, but its consequence lands only on days like this one:
| LTS line | Superseded (per lifecycle data) | Fix for CVE-2026-70426? |
|---|---|---|
| 2.568 | Current baseline | Yes — 2.568.2 |
| 2.555 | July 2026 | Never |
| 2.541 | April 2026 | Never |
| 2.528 | January 2026 | Never |
| 2.516 and older | 2025 and earlier | Never |
Note the top two rows. The 2.555 line was superseded barely a month ago — an installation that was fully patched in June is in the permanently-vulnerable set today. This is the defining property of rolling-support software: the distance between "current" and "will never see another fix" is one release cycle, and for Jenkins that cycle is twelve weeks. Complete supersession dates for every line are on our Jenkins lifecycle page, alongside the current EOL Risk Score™.
The three moves
Upgrade to LTS 2.568.2 — the real fix. For most installations on recent lines this is routine. For installations several baselines behind, plugin compatibility is the actual work: Jenkins upgrades are rarely hard because of Jenkins, and often slow because of the plugin matrix. Start with the plugins; the core follows.
Apply the workaround while the upgrade is scheduled. The Jenkins security team published a workaround alongside the advisory. Treat it as a bridge with a date attached, not a resolution — it narrows the gap; it does not close the class of problem, and it does nothing for the next advisory.
If neither happens now, document the decision. A CI controller with a known-critical, never-to-be-patched RCE path is a finding under any serious audit framework. A written risk acceptance with compensating controls — restricting Agent/Connect permission, isolating agent workloads, credential scoping — is defensible for a quarter. Silence is not.
The lesson, restated
This is the same lesson SharePoint taught in July and Debian 11 will teach on August 31, wearing CI clothes: the day support ends is not the day risk begins — it is the day the next critical CVE becomes permanent. For Jenkins, support ends quietly, every twelve weeks, one baseline at a time. The organizations that track those dates as operational data — not trivia — are the ones that were already on 2.568 when Tuesday's advisory landed.
Jenkins currently carries an EOL Risk Score™ of 65/100 — Grade D, high risk, recalculated at every site build from EOL recency, attack surface, CISA KEV exposure, and extended-support availability. Per-version scores and dates are on the Jenkins lifecycle page.
The right response comes down to one question: how many more years does this system need to run? Under a year, extended support (where it exists) is usually cheaper than an emergency migration. One to three years, migrate — support fees paid repeatedly cost more than doing the project once. Indefinitely, migrate now and plan the next one before it surprises you. Extended support is often the more expensive choice over a multi-year horizon — a bridge, not a destination.
Frequently Asked Questions
What is CVE-2026-70426?
A critical vulnerability in the Jenkins Remoting library, disclosed August 5, 2026: the JEP-200 deserialization class filter is not applied to classes resolved via a fallback path, allowing agents — or attackers with Agent/Connect permission — to execute code on the Jenkins controller. Affects weekly through 2.575 and LTS through 2.568.1; fixed in 2.576 and LTS 2.568.2.
Which Jenkins versions will never receive the fix?
Every superseded LTS line. Jenkins ships fixes only for the current baseline, so 2.555 (superseded July 2026), 2.541, 2.528, 2.516 and everything older are inside the affected range with no patch ever coming. The only fixed LTS is 2.568.2.
How urgent is this if my controller isn't internet-facing?
Still urgent — the attack path runs through agents, not the internet. Builds and their dependency trees execute on agents; a single compromised dependency in any pipeline can potentially leverage this vulnerability against the controller and the credentials it holds.
Is there a workaround if I can't upgrade immediately?
Yes — the Jenkins security team published one in the jenkinsci-cert SECURITY-3911-3930 repository. It is a stopgap: the durable fix is LTS 2.568.2 or weekly 2.576, and for older LTS lines that upgrade is the only path to a patched controller.