Build Step Plugin CVE-2026-84660

Exploitation requires an authenticated Jenkins session with at minimum Item/Build permission on an upstream pipeline job that contains a build step invoking a downstream job. The attacker must also be able to cancel the upstream build (requiring Item/Cancel on the upstream job, which is achievable if the attacker owns or controls the upstream project). The vulnerable condition triggers only when the upstream build is canceled while a downstream build it spawned is still queued or running. Limiting factors: unauthenticated or anonymous access is insufficient (PR:L required); the affected behavior is confined to Jenkins instances with Pipeline: Build Step Plugin ≤599.v4b_67ea_11b_152 installed; and the build step must be present in an active pipeline definition targeting a downstream job with separate ownership or stricter ACLs.

The CVSS 5.4 Medium score (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) reflects a bounded but genuine impact: exploitation demands authenticated access, and consequences are limited to unauthorized build cancellations rather than data exfiltration or remote code execution. No EPSS data was provided, and the CVE is not listed in the CISA KEV catalog, making widespread opportunistic exploitation unlikely. That said, even a mid-sized municipal IT team in kielce relying on Jenkins for multi-team CI/CD pipeline isolation should treat this as urgent if their permission model uses Item/Cancel boundaries to enforce job segregation - a rogue or compromised low-privilege pipeline account could systematically abort delivery pipelines belonging to other teams without detectable authorization failures. No public exploit has been identified at time of analysis; the vulnerability is a logic flaw requiring no shellcode or tooling, only normal pipeline API calls.

An authenticated Jenkins user with a low-privilege account holding Item/Build on an upstream pipeline job - but explicitly denied Item/Cancel on a critical downstream deployment job - submits a build of the upstream job via the build step. By then canceling the upstream build (which requires only Item/Cancel on the upstream job, which the attacker controls), the plugin automatically propagates the cancellation to the downstream deployment job, aborting it without any permission check on the downstream target. No exploit tooling or public PoC is required; the attack is a normal use of the Jenkins API against an unpatched plugin.