A CI/CD controller is the one machine in most engineering organisations that everything else trusts by default: deployment credentials, signing keys, source access, and the pipelines that push code to production all answer to it. CVE-2026-70426 shows what happens when the wall meant to separate a build agent from that controller has a gap in it.
Where the JEP-200 filter fell short
Jenkins agents and controllers communicate over the Remoting library using serialized Java objects, and JEP-200 exists specifically to filter which classes are allowed to be deserialized in that exchange, closing off the deserialization attacks that plagued Java applications for years. CVE-2026-70426 is a gap in that filter: classes resolved through a fallback path in the Remoting implementation were not being checked against the JEP-200 class list at all. An attacker who holds Agent/Connect permission, or who has already managed to execute code on any connected agent, can use that fallback path to bypass the filter entirely and run arbitrary code on the controller.
Why “just an agent” is not a small foothold
Agents are often treated as the less-trusted half of a Jenkins deployment, and for good reason: they run untrusted build steps, pull third-party dependencies, and execute whatever a pipeline definition tells them to. That is precisely why this bug matters. A single poisoned dependency, a single compromised build step, or a single agent host with a separate vulnerability is enough to hand an attacker Agent/Connect-level access, and CVE-2026-70426 turns that into controller-level code execution. The flaw affects Jenkins 2.575 and earlier, LTS 2.568.1 and earlier, and Remoting versions up to 3384.v60d89463d9e0, with one exception build already carrying the fix. Jenkins published the advisory and the corrected Remoting release on 5 August 2026.
The stakes for European engineering teams
Jenkins is the default CI/CD platform for a large share of European software organisations, from mid-market SaaS companies to public-sector IT shops, precisely because it is open source, self-hosted, and deeply extensible. That same self-hosted model means patching is entirely on the organisation running it, there is no managed cloud provider quietly pushing the fix behind the scenes. A controller compromise here carries the same downstream risk as any other build-system breach: stolen deployment credentials, tampered build artefacts, and a pipeline that no longer does only what its definition says. For organisations in scope of NIS2’s incident reporting duties, an exploited build controller that touched customer-facing code is exactly the kind of significant incident the directive expects you to detect and be ready to report.
If you are running self-hosted Jenkins and need help confirming every controller and agent is patched, auditing which agents hold Agent/Connect permission, or hardening your CI/CD trust boundaries more broadly, contact Excello Digital. We help European engineering teams secure the build systems their entire deployment pipeline depends on.