CVE-2026-84661 in Build Step Plugin
Summary
by MITRE • 09/02/2026
A missing permission check in Jenkins Pipeline: Build Step Plugin 599.v4b_67ea_11b_152 and earlier causes downstream builds awaited by the `waitForBuild` step when the `propagateAbort` parameter is used to be canceled even when the build's authentication lacks Item/Cancel permission on the downstream job.
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 Jenkins Pipeline Build Step Plugin, specifically in versions 599.v4b_67ea_11b_152 and earlier, contains a critical authorization bypass vulnerability related to the management of downstream build lifecycles. This flaw resides within the implementation of the waitForBuild step when utilized with the propagateAbort parameter enabled. In standard Jenkins pipeline operations, this configuration is designed to ensure that if the upstream parent build is aborted or fails, any dependent downstream builds are also terminated to conserve resources and maintain logical consistency in complex CI/CD workflows. However, the underlying code logic responsible for triggering these cancellations does not perform an adequate verification of user permissions before executing the abort command on the target job.
The technical root cause of this vulnerability is a missing permission check within the plugin's execution flow. When a pipeline triggers a downstream build and subsequently decides to propagate an abortion signal, it directly invokes the cancellation mechanism against the Jenkins core API for that specific item. The system fails to validate whether the user account or service identity associated with the upstream job possesses the Item/Cancel permission on the target downstream project. In Jenkins security models, permissions are granularly assigned based on roles and access control lists, ensuring that only authorized personnel can modify or terminate critical build processes. By bypassing this check, the plugin allows any entity capable of triggering such a pipeline to forcibly stop unrelated builds they do not have administrative rights over.
This authorization flaw has significant operational implications for organizations relying on Jenkins for continuous integration and delivery pipelines. An attacker with access to an upstream project that utilizes this specific configuration can disrupt ongoing development activities by arbitrarily canceling downstream builds. This denial of service effect impacts the integrity of the software delivery pipeline, potentially causing wasted computational resources, delayed releases, and confusion among developers who may interpret these cancellations as legitimate failures rather than malicious interference. In environments where multiple teams share a Jenkins instance with varying levels of access privileges, this vulnerability undermines the principle of least privilege by allowing lower-privileged users to exert control over higher-priority or restricted jobs.
From a classification perspective, this issue aligns with CWE-284, which describes Improper Access Control, as it involves an actor bypassing intended restrictions on accessing resources. Furthermore, within the context of attack techniques, this behavior mirrors aspects of ATT&CK technique T1079, specifically related to persistence or disruption mechanisms in CI/CD pipelines where attackers manipulate build states to degrade system availability. The vulnerability highlights a common oversight in plugin development where convenience features like automatic propagation are implemented without rigorous security validation against the broader Jenkins permission framework.
To mitigate this risk, organizations must immediately upgrade the Jenkins Pipeline Build Step Plugin to version 599.v4b_67ea_11b_153 or later, which includes patches for these authorization checks. Until an update can be applied, administrators should review their pipeline configurations and consider disabling the propagateAbort parameter in scenarios where downstream jobs are sensitive or belong to different security domains. Additionally, enforcing strict Item/Cancel permissions across all projects ensures that even if such a flaw exists elsewhere, the blast radius is limited by the underlying permission structure of Jenkins itself. Regular auditing of plugin versions and adherence to vendor security advisories remain essential practices for maintaining the integrity of automated build environments.