CVE-2026-84655 in Jenkins
Summary
by MITRE • 09/02/2026
Jenkins 2.579 and earlier, LTS 2.568.2 and earlier does not escape map keys when serializing objects as JSON and Python through its REST API, allowing attackers able to control map property names to inject arbitrary fields into JSON and Python API responses.
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 and LTS 2.568.2 represents a critical flaw in the serialization logic of its REST API, specifically affecting how Java Map objects are converted into JSON and Python data structures. This issue stems from an improper neutralization of special elements within input data, commonly categorized under CWE-134: Use of Externally-Controlled Format String or CWE-78: Improper Neutralization of Special Elements used in an OS Command depending on the specific exploitation vector, but more accurately aligned with CWE-20: Improper Input Validation when considering the failure to sanitize map keys during serialization. The core technical flaw lies in the fact that Jenkins does not properly escape or validate property names derived from user-controlled Map keys before embedding them into API responses. In standard JSON and Python dictionary representations, object properties are defined by string keys enclosed in quotes. However, if an attacker can control these key names and inject characters such as double quotes without proper escaping, they can break out of the intended data structure boundaries.
This lack of input validation allows for a form of injection attack where arbitrary fields can be injected directly into the JSON or Python response payload. For instance, by supplying a map key containing unescaped quotation marks or other structural delimiters, an attacker can manipulate the resulting serialized output to include additional key-value pairs that were not originally part of the intended object structure. This capability effectively allows for data injection, where the integrity and authenticity of the API response are compromised because the consumer of this data cannot reliably distinguish between legitimate fields provided by the application logic and maliciously injected fields introduced by an attacker. The operational impact is significant as it undermines trust in the API responses consumed by downstream services, automation scripts, or client applications that rely on strict adherence to expected JSON schemas.
From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability aligns with techniques related to Data Injection and potentially Command Injection if the injected data leads to further exploitation through deserialization vulnerabilities in consuming systems. It falls under the broader category of Improper Input Validation (T1427) where inputs are not adequately sanitized before processing or output generation. The ability to inject arbitrary fields can facilitate more severe attacks such as Cross-Site Scripting if the JSON is rendered directly into HTML contexts without further sanitization, or it could lead to privilege escalation if certain injected fields trigger unintended logic paths in consuming applications that parse these responses.
Mitigation for this vulnerability requires immediate upgrading of Jenkins instances to version 2.579 or later, or LTS version 2.568.3 and above, where the serialization mechanisms have been patched to properly escape map keys during JSON and Python object conversion. For environments unable to upgrade immediately, administrators should implement strict input validation on any user-supplied data that is used as Map keys before it reaches the API layer. Additionally, deploying a Web Application Firewall with rules capable of detecting anomalous patterns in serialized output or enforcing strict schema validation on incoming requests can provide an additional layer of defense against exploitation attempts until the software patch is applied.