Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-09-02T16:17:30.373Z",
  "pubdate": "2026-09-02T16:17:30.373Z",
  "executiveSummary": "This vulnerability is an authorization bypass flaw identified in the Jenkins build CLI command. The vulnerability allows an authenticated attacker to perform an unauthorized action—canceling a build—by exploiting an insufficient permission check within the CLI interface.\nThe issue specifically impacts users who possess the 'Item/Build' permission, enabling them to terminate builds initiated by other users, an action that requires the more restrictive 'Item/Cancel' permission. This privilege escalation impacts Jenkins versions 2.579 and earlier, and LTS 2.568.2 and earlier.\nThe risk is significant within multi-user environments where build integrity and job persistence are critical. By successfully exploiting this vulnerability, an attacker can intentionally disrupt Continuous Integration/Continuous Deployment (CI/CD) pipelines, causing denial-of-service to build processes and potential delays in software delivery cycles. The exploitation does not require administrative privileges, merely the standard 'Item/Build' permission, significantly increasing the attack surface within an organization.\nNo specific mention of external network exposure requirements is provided, implying that any authenticated user with build permissions within the Jenkins environment can initiate the unauthorized cancellation process.",
  "technicalDetails": "The root cause of this vulnerability lies in a logic error within the Jenkins CLI command implementation for build operations. When the CLI 'build' command is invoked with the '-s' (synchronous) flag, the system initiates a build and enters a state to wait for its completion.\nUnder normal security policy, the ability to abort or cancel a build requires the 'Item/Cancel' permission. However, the implementation fails to enforce this authorization check during the execution flow initiated by the '-s' parameter. Instead, the logic erroneously relies on the initial 'Item/Build' permission scope granted to the user, effectively bypassing the intended security constraints.\nThe attack flow follows a predictable pattern: 1) The attacker authenticates to the Jenkins instance with a standard user account holding 'Item/Build' permissions. 2) The attacker identifies a target build initiated by another user or a system process. 3) The attacker executes the Jenkins CLI 'build' command, targeting the specific job, and appends the '-s' flag. 4) The CLI command, failing to validate the 'Item/Cancel' authorization, allows the request to proceed, resulting in the cancellation of the build process.\nThe vulnerable component is the Jenkins CLI build command logic responsible for handling synchronous build requests. Because the system permits this action for users who have only been granted 'Item/Build' rights, the security boundary between 'Build' (start) and 'Cancel' (stop) operations is collapsed.\nAffected software versions include Jenkins 2.579 and earlier, as well as LTS 2.568.2 and earlier. The vulnerability is strictly an authorization issue rather than a code execution vulnerability; however, the post-exploitation impact includes the forced termination of critical jobs, disruption of automated build chains, and the ability for unauthorized actors to systematically sabotage build pipelines.\nThe exploitation does not require physical access to the build server; it is performed via the Jenkins CLI protocol. The requirement of being an authenticated user means the vulnerability is primarily a concern for internal threats or compromised low-privileged accounts."
}