CVE-2026-117615 in Jenkins
Summary
by MITRE • 10/28/2026
Jenkins 2.587 and earlier, LTS 2.580.1 and earlier follows symbolic links when copying the directory of an item being renamed, allowing attackers with Item/Create and Item/Configure permission to read arbitrary files on the Jenkins controller file system.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in Jenkins versions prior to 2.587 and LTS 2.580.1 represents a critical security flaw rooted in improper handling of symbolic links during directory operations, specifically when renaming items within the Jenkins interface. This issue allows authenticated users with Item/Create or Item/Configure permissions to exploit the file system behavior by creating symlinks that point outside the intended workspace directories. When an administrator or authorized user attempts to rename a job or item, the underlying copy operation follows these symbolic links rather than restricting access to the designated directory structure. Consequently, this mechanism enables attackers to read arbitrary files from the Jenkins controller's file system, effectively bypassing standard isolation boundaries and exposing sensitive configuration data, credentials, or internal application logic that should remain inaccessible to lower-privileged users.
From a technical perspective, the flaw stems from the use of Java NIO Files.copy method with default options during the rename process for directory-based items. By not explicitly disabling symbolic link following via NOFOLLOW_LINKS option in specific code paths, Jenkins inadvertently permits traversal beyond the sandboxed environment intended for job configurations and build artifacts. This behavior aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it fails to adequately restrict access to resources outside the allowed directory scope. The attack vector requires only Item/Create or Item/Configure permissions, which are commonly granted to development teams for managing pipelines and jobs, thereby expanding the potential attacker surface significantly compared to vulnerabilities requiring administrative privileges.
The operational impact of this vulnerability is severe due to its ability to facilitate unauthorized data exfiltration from the Jenkins controller host machine. Attackers can leverage this flaw to extract sensitive information such as stored credentials, API tokens, private keys, or other configuration files that contain secrets necessary for further exploitation within the broader infrastructure. This capability undermines the principle of least privilege by allowing lower-privileged users to access high-value assets typically protected at a higher security tier. Furthermore, exposure of internal file structures may aid in subsequent attacks such as path traversal leading to remote code execution if combined with other vulnerabilities or misconfigurations present on the Jenkins instance.
Mitigation strategies primarily involve upgrading to patched versions where this symbolic link following behavior has been corrected during directory copy operations associated with item renaming processes. Organizations should immediately apply updates for Jenkins 2.587 and later, as well as LTS version 2.580.1 or newer, ensuring that all instances within their environment are brought up to date. In addition to software patching, administrators should review user permissions carefully, adhering strictly to the principle of least privilege by limiting Item/Create and Item/Configure access only to those who absolutely require it for operational workflows. Implementing strict input validation on job names and disabling unnecessary features can also reduce exposure risk while waiting for deployment windows allow for full remediation across all Jenkins controllers.
This vulnerability maps directly to MITRE ATT&CK technique T1083: File and Directory Discovery, as attackers utilize the flaw to enumerate and access restricted files without direct file system permissions through legitimate application functionality abuse. It also relates to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor due to improper access controls over sensitive directories. Security teams should monitor for unusual patterns in Jenkins API calls involving item renaming operations, particularly those originating from accounts with moderate privilege levels but exhibiting behavior consistent with file system enumeration or unauthorized data retrieval attempts. Regular auditing of permission assignments and continuous monitoring against known exploitation techniques remain essential components of a robust defense-in-depth strategy against such application-level vulnerabilities.