Critical Jenkins Deserialization Flaw Allows Attackers to Execute Code on Controllers

A critical vulnerability in Jenkins, tracked as CVE-2026-70426, may allow attackers to execute arbitrary code on Jenkins controllers by bypassing deserialization protections within the platform’s Remoting library.

This flaw, identified as SECURITY-3911, affects Jenkins environments where agents communicate with controllers via serialized Java objects over Remoting, typically deployed as agent.jar or remoting.jar.

The Java serialization mechanism is used to exchange objects between agent systems and the central controller. However, this design can pose a risk if untrusted classes are deserialized.

Critical Jenkins Deserialization Flaw

Jenkins introduced the JEP-200 class filter to mitigate this risk, restricting which Java classes can be deserialized when a controller receives objects over a Remoting channel.

However, researchers discovered that the filter was not enforced for classes loaded through a fallback path in the Remoting deserialization implementation.

The vulnerability affects Remoting versions 3384.v60d89463d9e0 and earlier, except for version 3355.3357.v931d3c992987. Vulnerable Remoting builds are included in Jenkins 2.575 and earlier, as well as Jenkins LTS 2.568.1 and earlier.

An attacker could exploit the issue through a compromised Jenkins agent, malicious code already running on an agent, or an account with Agent/Connect permissions. Successful exploitation may enable the attacker to bypass the JEP-200 deserialization filter and execute code on the Jenkins controller.

This issue has received a Critical CVSS rating. The published vector indicates network reachability, no required privileges or user interaction, and potential impacts on confidentiality, integrity, and availability.

While the attack complexity is rated as high, a successful compromise of the controller could expose credentials, pipeline secrets, source code, build artifacts, and the broader CI/CD environment.

The deserialization bypass is limited to classes available on the Jenkins core classpath, which includes both classes bundled with Jenkins itself and those provided by the Java platform.

Importantly, dependencies packaged within Jenkins plugins are not affected by this fallback deserialization path and will not be deserialized through the vulnerable mechanism.

While this limitation may reduce the range of exploitable gadget chains, it does not eliminate the risk of code execution on the controller where vulnerable core or Java platform classes are present.

Jenkins has addressed this flaw in Jenkins 2.576 and Jenkins LTS 2.568.2. The updated Remoting library now applies the JEP-200 class filter to the previously unprotected fallback class-resolution path.

Organizations should upgrade their Jenkins controllers and associated Remoting components to the fixed releases as soon as possible. Security teams should review agent access, remove unnecessary Agent/Connect permissions, and investigate whether untrusted workloads can execute on connected agents.

For deployments that cannot update immediately, Jenkins has published a workaround repository for SECURITY-3911 and related issues.

Administrators should apply the documented mitigation, monitor controller and agent logs for anomalous Remoting activity, and treat potentially compromised agents as a direct risk to the Jenkins controller.

This vulnerability was reported through the Jenkins Bug Bounty Program, sponsored by the European Commission.

Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world