CVE-2026-84657 in Jenkins
Summary
by MITRE • 09/02/2026
In Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, the build CLI command does not check the Item/Cancel permission when using the -s flag to cancel a build triggered to wait for completion, allowing attackers with Item/Build permission to cancel builds started by other users.
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 authorization bypass within the command-line interface build execution mechanism. This flaw specifically affects the operational integrity of continuous integration pipelines by allowing unauthorized interference with ongoing processes. The core issue lies in the insufficient access control validation performed when handling requests to cancel active builds via the -s flag. In a properly secured environment, actions that modify or terminate resources owned by other users should require elevated privileges beyond basic project interaction rights. However, Jenkins fails to verify whether the initiating user possesses Item/Cancel permissions before executing the termination command, thereby creating a significant gap in role-based access control enforcement.
From a technical perspective, this vulnerability stems from an incomplete implementation of permission checks within the CLI handler for build cancellation operations. When a user triggers a build with the intent to wait for its completion using specific flags, and subsequently issues a cancel request through the same interface, the system does not cross-reference the current session's permissions against the required Item/Cancel privilege level. Instead, it relies on or defaults to lower-level checks that are satisfied by users holding only Item/Build permission. This logical error allows any authenticated user with basic build initiation rights to interrupt builds initiated by other team members, effectively bypassing the intended security boundaries defined in Jenkins' authorization matrix.
The operational impact of this vulnerability is substantial for organizations relying on Jenkins for automated software delivery and testing workflows. Attackers or malicious insiders can disrupt critical pipeline stages such as integration tests, deployment sequences, or artifact generation processes belonging to colleagues or other projects within the same instance. This disruption leads to wasted computational resources, delayed release cycles, and potential data integrity issues if partial builds are consumed downstream. Furthermore, in environments where build stability is monitored for compliance or audit purposes, unauthorized cancellations can skew metrics and obscure root cause analysis efforts. The ability to arbitrarily stop another user's work undermines team collaboration and trust within the development infrastructure.
This flaw aligns with CWE-269, which describes Improper Privilege Assignment, as it involves a situation where users are granted more capabilities than intended by their assigned roles. Additionally, from an offensive security perspective, this behavior can be mapped to MITRE ATT&CK technique T1485, specifically the Data Destruction sub-technique involving termination of services or processes on networked devices and systems. While Jenkins is not a traditional operating system service in all contexts, the principle of disrupting operational continuity remains consistent with this classification. The vulnerability highlights the importance of granular permission checks that extend beyond resource creation to include modification and deletion actions across shared environments.
Mitigation strategies for this issue involve immediate upgrading to patched versions of Jenkins where these authorization checks have been corrected. Administrators should ensure they are running version 2.580 or later, or LTS version 2.569.1 or later, as these releases include the necessary code fixes to enforce Item/Cancel permission validation during CLI build cancellation requests. In cases where upgrading is not immediately feasible due to compatibility constraints with plugins or custom scripts, organizations should consider implementing network-level access controls or reverse proxy configurations that restrict direct CLI access to trusted IP ranges only. Additionally, reviewing and tightening Jenkins security settings to adhere to the principle of least privilege can help minimize the blast radius if similar vulnerabilities are discovered in other components. Regular audits of user permissions and active build logs will also aid in detecting any unauthorized cancellation attempts during the transition period until full patching is achieved.