Jenkins has disclosed a critical security vulnerability that could allow attackers to execute malicious code on a Jenkins controller by bypassing a security filter used in agent-to-controller communications.
Tracked as CVE-2026-70426, the flaw affects Jenkins installations using vulnerable versions of the Remoting library. The issue has received a Critical CVSS severity rating.
It impacts Jenkins 2.575 and earlier, as well as Jenkins LTS 2.568.1 and earlier. The vulnerability exists in Remoting versions 3384.v60d89463d9e0 and earlier, except for version 3355.3357.v931d3c992987.
Jenkins uses its Remoting library, commonly distributed as agent.jar or remoting.jar, to enable communication between the central controller and connected build agents.
These communications rely on serialized Java objects. Because Java deserialization bugs can lead to arbitrary code execution, Jenkins applies the JEP-200 class filter when processing objects sent over a Remoting channel.
Jenkins Code Execution Vulnerability
The JEP-200 filter is designed to restrict potentially unsafe classes from being deserialized by the Jenkins controller. However, researchers found that the filter was not applied when classes were resolved through a fallback path in the Remoting deserialization process.
This gap creates a filter bypass. An attacker who controls an agent process, gains code execution on an existing agent, or has the Jenkins Agent/Connect permission may exploit the flaw to deserialize certain Java classes that should have been blocked.
Successful exploitation could allow malicious code to run on the Jenkins controller, which is typically the most sensitive system in a Jenkins environment.
The impact is limited to classes already available on the Jenkins core classpath. This includes classes bundled with Jenkins itself and classes included in the Java platform.
Plugin-bundled dependencies are not deserialized through the affected fallback path, reducing the overall attack surface.
However, controller-level code execution remains a severe risk because a compromised controller can expose source code, secrets, build credentials, deployment keys, and software supply chain pipelines.
Jenkins addressed the vulnerability in advisory SECURITY-3911 with Jenkins 2.576 and Jenkins LTS 2.568.2. These releases update the Remoting library to ensure the JEP-200 class filter is enforced even when the fallback deserialization path is used.
Organizations should upgrade Jenkins controllers and agents to the fixed versions as soon as possible. Security teams should also review which users, service accounts, and systems hold Agent/Connect permission, as this access can be used as part of an exploitation path.
Untrusted build agents should be isolated, monitored, and prevented from accessing sensitive internal resources. The flaw was reported through the European Commission’s Jenkins Bug Bounty Program.
For environments where an immediate update is not possible, Jenkins has published a workaround in its SECURITY-3911-3930 GitHub repository.
Administrators should apply the mitigation carefully and treat it as a temporary measure until patched versions of Jenkins can be deployed.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
The post Critical Jenkins Vulnerability Allows Attackers to Execute Malicious Code on Controller appeared first on Cyber Security News.
