Jenkins CVE-2026-117615

Requires an authenticated user (not anonymous) holding BOTH Item/Create and Item/Configure permissions on a vulnerable controller (Jenkins 2.587 and earlier, or LTS 2.580.1 and earlier). The concrete trigger is renaming an item whose directory contains an attacker-planted symbolic link, in the code path where Jenkins cannot move the directory and instead copies it - the copy operation follows symbolic links and reads the link target. Limiting factors: the attacker must be able to create and configure items (so instances that restrict job creation/configuration to administrators are largely out of reach), the attack depends on the copy fallback rather than a plain move, and only file-read is directly achieved - RCE is a contingent escalation via disclosed secrets. The only complete fix stated by the vendor is upgrading to 2.588 or LTS 2.580.2; no workaround is listed for this issue.

No CVSS vector, EPSS score, KEV entry, or PoC reference is present in the supplied data - the vuln.today Decision label is 'awaiting_data', so quantitative exploitation signals are simply missing rather than low. The Jenkins advisory (vendor CNA) rates this High. The strongest risk-limiting signal is the privilege requirement confirmed by the vendor: an attacker needs both Item/Create and Item/Configure permissions, so this is not an anonymous or unauthenticated flaw and cannot be driven by opportunistic internet-wide scanning. Against that, the technical impact is serious: arbitrary file read on the controller file system, which the vendor states can escalate to remote code execution (e.g. by reading the controller's secret key or stored credentials). Net: a genuine priority for Jenkins instances that grant Item/Create and Item/Configure to many or semi-trusted users (shared/multi-tenant controllers), but materially lower where job creation and configuration are restricted to administrators. Because no EPSS/KEV/PoC data was provided, widespread active exploitation cannot be asserted and the practical urgency rests on the vendor's High rating plus the privilege model, not on observed attacks.

An authenticated user holding Item/Create and Item/Configure permissions creates an item, places a symbolic link inside that item's directory pointing to a sensitive file on the controller (for example the master secret key or a credentials store), and then renames the item. Because Jenkins falls back to copying the directory when it cannot move it and follows the symlink during that copy, the target file's contents are read into the attacker-controlled item, disclosing secrets that can be leveraged toward remote code execution on the controller. No public exploit is identified at time of analysis.