CVE-2026-117612 in Jenkins
Summary
by MITRE • 10/28/2026
Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not apply its deserialization filter to classes referenced by the `resolves-to` attribute during XStream deserialization.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in Jenkins versions prior to 2.587 for regular releases and before 2.580.1 for Long-Term Support (LTS) tracks represents a critical flaw within its XML External Entity processing subsystem, specifically involving the XStream library used for configuration serialization. This issue stems from an incomplete implementation of security filters designed to prevent unsafe deserialization attacks. Jenkins utilizes XStream to convert Java objects into XML format and vice versa, allowing users to configure plugins and system settings through web interfaces that submit structured data. To mitigate risks associated with malicious payloads embedded in these configurations, Jenkins implemented a filter mechanism intended to block the instantiation of dangerous classes during the deserialization process. However, this security control failed to account for all pathways through which class resolution occurs, specifically neglecting to apply restrictions to classes referenced via the resolves-to attribute within XStream mappings.
The technical root cause lies in how XStream handles type aliases and references. When an XML document contains a reference to a specific Java class using the resolves-to attribute, it instructs the deserializer to instantiate that particular class rather than relying on standard reflection or default mapping rules. The Jenkins security filter was designed to intercept direct instantiation attempts of whitelisted blacklisted classes but did not extend its inspection logic to these explicit type references. Consequently, an attacker can craft a specially constructed XML payload that leverages this attribute to bypass the deserialization filter entirely. By pointing directly to vulnerable gadget chains present in the classpath, such as those involving common libraries like Commons Collections or Spring Framework, the attacker forces Jenkins to instantiate objects with side effects without triggering the protective checks intended to stop them.
This architectural oversight has severe operational implications for any organization running affected versions of Jenkins. The primary impact is Remote Code Execution (RCE) against the Jenkins server process itself. Since Jenkins typically runs with elevated privileges relative to standard user accounts, successful exploitation allows an attacker to execute arbitrary commands on the underlying operating system. This can lead to a complete compromise of the CI/CD pipeline infrastructure, including theft of sensitive credentials stored in job configurations, manipulation of build artifacts, and lateral movement into internal networks where Jenkins agents are deployed. Furthermore, because this vulnerability affects both standard and LTS releases up to specific patch versions, it poses a widespread risk across many enterprise environments that may not have immediately updated their systems due to the perceived stability benefits of LTS tracks.
From a classification perspective, this flaw aligns with CWE-502, which denotes Deserialization of Untrusted Data. It also maps directly to MITRE ATT&CK technique T1059.004, specifically Command and Scripting Interpreter via Windows or Linux command execution through deserialized objects. The attack vector typically involves an authenticated user submitting a malicious configuration payload, although in some configurations where anonymous access is enabled for certain endpoints, unauthenticated exploitation may be possible depending on the specific Jenkins setup and plugin versions involved.
Mitigation requires immediate upgrading to Jenkins version 2.587 or later for regular releases, or version 2.580.1 and later for LTS users. These updates contain patches that extend the deserialization filter logic to cover classes referenced by the resolves-to attribute, thereby closing the bypass vector. In addition to patching, administrators should enforce strict access controls on Jenkins instances, ensuring that only trusted personnel can modify system configurations or install plugins. Network segmentation strategies should also be employed to limit exposure of Jenkins interfaces to untrusted networks, and input validation mechanisms at the proxy level can provide an additional layer of defense against malformed XML payloads attempting to exploit this vulnerability.