CVE-2026-84646 in Jenkins Plugin
Summary
by MITRE • 09/02/2026
In Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, user objects can appear as nested field values in other deserialized XML objects, allowing attackers with Overall/Read permission to create user objects by submitting crafted XML.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Jenkins versions prior to 2.579 for the regular release line and before LTS 2.568.2 involves a critical flaw in the handling of serialized data during deserialization processes. This issue stems from an improper restriction on how user objects are processed when embedded within other XML structures that undergo automatic unmarshalling. Jenkins relies heavily on Java serialization and XML-based configuration formats, such as those used by Hudson CLI or various plugin configurations, to manage system state and user attributes. When the application receives these serialized payloads, it attempts to reconstruct the original object graph in memory. The specific technical flaw lies in the fact that the deserialization mechanism does not sufficiently validate whether nested fields within a parent XML object are intended to be treated as simple data values or as complex objects requiring instantiation. This lack of strict type enforcement allows an attacker to inject maliciously crafted XML where user-related properties, such as username, password hashes, or authority lists, are placed in positions that the deserializer interprets as instructions to create new User instances rather than mere string literals.
From a technical perspective, this vulnerability is classified under CWE-502, which denotes Deserialization of Untrusted Data. The core issue is not necessarily a direct remote code execution flaw but rather an authorization bypass and privilege escalation vector enabled by the flexibility of Java's reflection-based deserialization. When Jenkins processes XML input from endpoints that accept user-submitted data or configuration updates, it assumes that certain fields are primitive types unless explicitly defined otherwise. However, because the underlying serialization framework allows for deep object graphs, a carefully constructed payload can trick the parser into instantiating a User class with arbitrary attributes provided by the attacker. This behavior violates the principle of least privilege and fails to enforce strict schema validation before instantiation occurs. The vulnerability is particularly dangerous because it leverages existing permissions that are commonly granted to legitimate users within Jenkins environments.
The operational impact of this flaw is significant for organizations relying on Jenkins for continuous integration and delivery pipelines. An attacker who possesses Overall/Read permission, which is a relatively low-level privilege often assigned to developers or CI service accounts, can exploit this mechanism to create new user objects with elevated privileges. By crafting specific XML payloads that embed User object definitions within other deserializable structures, the adversary can effectively register new administrative users without needing valid credentials for those roles. This leads to an unauthorized escalation of access rights, allowing the attacker to gain full control over the Jenkins instance. Once this higher-level access is established, the attacker can modify build configurations, inject malicious code into pipelines, exfiltrate sensitive source code or secrets stored in environment variables, and potentially pivot to other systems within the network that are accessible from the CI/CD server.
This vulnerability aligns with MITRE ATT&CK technique T1078, specifically Valid Accounts, as it involves using legitimate credentials to gain unauthorized access through privilege escalation. It also relates to T1546, Event Triggered Execution, if the crafted XML is submitted via automated triggers or configuration updates that occur during normal operations. The exploitation does not require complex reverse engineering of binary formats but rather a precise understanding of Jenkins' internal object mapping and serialization logic. This makes it accessible to attackers with moderate technical skills who have network access to the Jenkins interface and basic read permissions.
Mitigation for this vulnerability requires immediate action by system administrators and DevOps teams. The primary remediation is to upgrade Jenkins to version 2.579 or later in the standard release line, or to LTS version 2.568.3 or newer if using the Long-Term Support track. These versions include patches that enforce stricter validation on deserialized objects, ensuring that nested fields are correctly typed and do not inadvertently trigger object instantiation for sensitive classes like User. In addition to upgrading, organizations should review their Jenkins security configurations to ensure that Overall/Read permissions are granted only to trusted users who require them for specific operational tasks. Implementing network-level access controls to restrict exposure of the Jenkins management interface can also reduce the attack surface. Furthermore, enabling audit logging and monitoring for unusual user creation events or anomalous XML payloads in API requests can help detect potential exploitation attempts before they result in a full compromise. Regular security assessments and penetration testing focused on serialization flaws are recommended to identify similar weaknesses in other plugins or custom scripts that may interact with Jenkins' core components.