A critical security vulnerability has been identified in Jenkins, the widely-used open-source automation server, which could allow attackers to execute malicious code on the Jenkins controller by bypassing existing security filters in agent-to-controller communications.
Designated as CVE-2026-70426, this flaw affects Jenkins installations utilizing vulnerable versions of the Remoting library. The vulnerability has been assigned a Critical CVSS severity rating, underscoring the potential risk it poses to affected systems.
The issue impacts Jenkins versions up to and including 2.575, as well as Jenkins LTS versions up to and including 2.568.1. Specifically, it is present in Remoting versions 3384.v60d89463d9e0 and earlier, with the exception of version 3355.3357.v931d3c992987.
Jenkins employs its Remoting library, commonly distributed as agent.jar or remoting.jar, to facilitate communication between the central controller and connected build agents. These communications rely on the serialization and deserialization of Java objects. Given that Java deserialization vulnerabilities can lead to arbitrary code execution, Jenkins implements the JEP-200 class filter to restrict the deserialization of potentially unsafe classes.
Details of the Vulnerability
The JEP-200 filter is designed to prevent the deserialization of classes that could pose security risks. However, researchers discovered that this filter was not applied when classes were resolved through a fallback mechanism in the Remoting deserialization process. This oversight creates a bypass, allowing an attacker who controls an agent process, gains code execution on an existing agent, or possesses the Jenkins Agent/Connect permission to deserialize certain Java classes that should have been blocked.
Exploiting this vulnerability could enable malicious code execution on the Jenkins controller, which is typically the most sensitive component in a Jenkins environment. The impact is limited to classes already available on the Jenkins core classpath, including those bundled with Jenkins itself and classes included in the Java platform. Notably, dependencies bundled with plugins are not deserialized through the affected fallback path, reducing the overall attack surface.
Despite this limitation, the risk remains significant. A compromised controller can expose source code, secrets, build credentials, deployment keys, and software supply chain pipelines, potentially leading to extensive security breaches.
Mitigation and Recommendations
Jenkins has addressed this vulnerability in advisory SECURITY-3911 by releasing Jenkins 2.576 and Jenkins LTS 2.568.2. These updates include a revised version of the Remoting library that ensures the JEP-200 class filter is enforced consistently, even when the fallback deserialization path is utilized.
Organizations are strongly advised to upgrade their Jenkins controllers and agents to these fixed versions promptly. Additionally, security teams should review and restrict the assignment of Agent/Connect permissions, as this access can be exploited as part of an attack vector.
Untrusted build agents should be isolated, monitored, and prevented from accessing sensitive internal resources. The vulnerability was reported through the European Commission’s Jenkins Bug Bounty Program, highlighting the importance of collaborative efforts in identifying and mitigating security risks.
For environments where immediate updates are not feasible, Jenkins has provided a temporary workaround in its SECURITY-3911-3930 GitHub repository. Administrators should apply this mitigation cautiously and prioritize deploying the patched versions as soon as possible.
This incident underscores the critical importance of maintaining up-to-date software and implementing robust security measures in continuous integration and continuous deployment (CI/CD) environments. Organizations must remain vigilant, regularly review their security configurations, and promptly apply patches to protect against emerging threats.
