Jenkins Job Configuration History Plugin EUVD-2026-70132

Exploitation requires a valid Jenkins account with at least low-level privileges (PR:L per CVSS), accessible over the network without requiring any additional user interaction. The Job Configuration History Plugin must be installed and active on the target Jenkins instance. There are no elevated authentication requirements - any authenticated Jenkins user can trigger the vulnerable Stapler binding. Unauthenticated external attackers cannot exploit this; the authentication requirement is the primary limiting factor. Exploitation is not automatable in bulk per SSVC assessment, as it involves interacting with a specific plugin configuration endpoint.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, score 5.4) correctly flags this as a Medium-severity network-accessible flaw requiring only a valid Jenkins account. EPSS at 0.15% (4th percentile) and SSVC signals of 'Exploitation: none' and 'Automatable: no' collectively indicate that real-world weaponization is unlikely at scale - even a mid-sized municipal IT team in ustka should treat this as a standard patch-cycle item rather than an emergency response. The integrity impact (I:L) is the more meaningful concern: an attacker could silently redirect audit history writes, undermining change-tracking controls that security teams rely on for compliance and incident response. The confidentiality signal (C:L) arises from the possibility of path traversal to sensitive directories if the redirected storage path lands in a privileged location. No KEV listing and no known POC confirm this is not under active exploitation.

An authenticated Jenkins user - including those with minimal permissions such as Job/Build - sends a crafted HTTP POST request to the Job Configuration History Plugin configuration endpoint, injecting Stapler-bound parameters that overwrite the plugin's history storage directory to a path of the attacker's choosing on the Jenkins controller. Subsequent configuration saves by legitimate users then write audit snapshots to the attacker-controlled location, allowing the attacker to suppress or corrupt the audit trail. No public exploit code has been identified, and successful exploitation requires a valid Jenkins credential.