CVE-2026-84654 in Jenkins
Summary
by MITRE • 09/02/2026
In Stapler 2107.v8dfcb_e8ed317 and earlier, except 2088.2093.vd7c3e58008a_6, included in Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, form data binding allows setting public static fields of the bound configuration object, allowing attackers who can submit configuration forms to modify public static fields of the configuration objects those forms are bound to, resulting in changes that apply globally to the Jenkins instance.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Stapler versions prior to 2107.v8dfcb_e8ed317 and specifically excluding version 2088.2093.vd7c3e58008a_6, which impacts Jenkins releases up to 2.579 and LTS line 2.568.2, represents a critical flaw in the framework's form data binding mechanism. Stapler serves as the core web framework for Jenkins, handling HTTP request processing and mapping incoming form parameters to Java object properties during configuration submissions. The fundamental technical defect lies in how this binding process resolves property names against target objects. Instead of strictly limiting updates to instance-level fields that represent specific user or job configurations, the logic inadvertently permits modifications to public static fields within those same configuration classes. This behavior deviates from standard security expectations where form-bound data should only affect the scope of the individual entity being configured, such as a single plugin setting or a specific project's parameters.
This architectural oversight allows an attacker with permission to submit configuration forms for any Jenkins component to manipulate public static fields that are shared across the entire application instance. Because these fields are declared as static, they belong to the class itself rather than individual instances, meaning changes made through this vector propagate globally. For example, if a vulnerable plugin exposes a static field controlling security settings or administrative privileges via its configuration form, an authenticated user with lower-level access could alter that state variable. This effectively bypasses role-based access control mechanisms by modifying global system properties without requiring elevated permissions directly for those specific fields. The impact is severe as it can lead to privilege escalation, unauthorized modification of system-wide configurations, or complete compromise of the Jenkins instance's integrity and availability depending on which static field is targeted.
From a classification perspective, this vulnerability aligns with CWE-650, which describes Trust Establishment Issues where trust is established incorrectly, specifically relating to improper control of configuration settings through untrusted input. It also maps closely to CWE-284, Improper Access Control, as the flaw allows users to perform actions beyond their intended privileges by exploiting the binding logic rather than direct permission checks on individual fields. In terms of the MITRE ATT&CK framework for enterprise security, this technique corresponds to T1078 Valid Accounts and potentially T1531 Account Access Removal or Modification if used to disable security features. The attack vector is primarily local within the context of a web application but requires authentication, making it particularly dangerous in environments where multiple teams share access to Jenkins instances with varying levels of trust.
Mitigation strategies must focus on immediate version upgrades and configuration hardening. Administrators should upgrade Stapler to version 2107.v8dfcb_e8ed317 or later, ensuring that the specific exception for version 2088.2093.vd7c3e58008a_6 is accounted for in deployment pipelines. For Jenkins users, this necessitates updating to a patched release such as Jenkins 2.579 or LTS 2.568.3 and beyond. In the interim, where immediate patching is not feasible, organizations should enforce strict least-privilege access controls by limiting who can submit configuration forms for plugins that utilize public static fields in their data binding models. Additionally, implementing Web Application Firewalls with rules to detect anomalous patterns in form submissions targeting known vulnerable endpoints may provide a layer of defense against exploitation attempts while the underlying code is remediated. Regular auditing of plugin configurations and monitoring for unexpected changes in global system states are also recommended operational security practices to detect potential abuse of this flaw.