CVE-2026-84650 in Jenkins
Summary
by MITRE • 09/02/2026
In Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, transient fields cannot be excluded from deserialization, allowing attackers able to submit configuration updates to specify the values of transient fields that will be deserialized, the impact depending on how those fields are used.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Jenkins versions 2.579 and earlier, as well as LTS version 2.568.2 and earlier, represents a critical flaw in the application's object serialization and deserialization mechanisms. This issue stems from an improper handling of transient fields during the process of reconstructing Java objects from serialized data streams. In standard Java programming practices, fields marked with the transient keyword are explicitly intended to be ignored by default serialization frameworks because they typically hold state that is either derived at runtime or should not persist across sessions. However, in this specific implementation within Jenkins, the deserialization logic fails to strictly enforce these boundaries when processing configuration updates submitted via API endpoints or web interfaces. This oversight allows an attacker who has the ability to submit configuration changes to manipulate transient fields during the reconstruction of internal objects, thereby bypassing intended security controls that rely on those fields remaining null or uninitialized after deserialization.
From a technical perspective, this flaw is classified under CWE-502, which denotes Deserialization of Untrusted Data. The core issue lies in Jenkins' use of XStream for object serialization and deserialization to handle configuration data stored in XML format. While XStream provides mechanisms to exclude certain fields from being serialized or deserialized, the specific implementation in these vulnerable versions did not correctly apply exclusion rules to transient fields when processing incoming updates. Consequently, if a malicious actor can inject crafted input that targets internal objects with sensitive transient properties, they may force the application to populate those fields with attacker-controlled values. The severity of this vulnerability is heavily dependent on how Jenkins utilizes these specific transient fields internally. In many cases, such fields control access permissions, session states, or security contexts, meaning their manipulation can lead to significant privilege escalation or state confusion within the application logic.
The operational impact of this vulnerability allows for potential remote code execution or unauthorized administrative actions depending on the target environment and the specific Jenkins plugins installed. If an attacker successfully manipulates transient fields associated with authentication tokens, session identifiers, or security manager configurations, they may be able to bypass access controls that were designed to restrict certain operations to authenticated administrators only. This effectively undermines the integrity of the CI/CD pipeline management system. Attackers could potentially escalate their privileges from a low-level user to an administrator level without valid credentials, leading to full compromise of the Jenkins server and any connected build agents or source code repositories. The attack vector typically involves sending specially crafted HTTP requests containing XML payloads that exploit this deserialization flaw during configuration updates, making it accessible over the network if the affected endpoints are exposed.
Mitigation strategies for this vulnerability primarily involve upgrading to patched versions of Jenkins where the serialization logic has been corrected to strictly respect transient field exclusions. For organizations unable to immediately upgrade, applying access controls such as IP whitelisting on administrative interfaces and disabling unnecessary plugins can reduce the attack surface. Additionally, enabling CSRF protection and ensuring that only trusted users have permission to submit configuration updates are essential defensive measures. Security teams should also monitor for anomalous activity related to XML parsing or unusual object instantiation patterns within Jenkins logs. This vulnerability aligns with MITRE ATT&CK technique T1059, specifically Command and Scripting Interpreter variants if it leads to code execution, and highlights the critical importance of secure coding practices regarding Java serialization in enterprise software applications.