CVE-2026-84656 in Jenkins Plugin
Summary
by MITRE • 09/02/2026
A missing permission check in Jenkins 2.579 and earlier, LTS 2.568.2 and earlier allows attackers with Item/Read permission on at least one job to read build parameter names and values of jobs they have no access to.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified as a missing permission check in Jenkins versions prior to 2.579 for the mainline release track and prior to LTS version 2.568.2 represents a significant authorization flaw within the application's role-based access control mechanism. This issue specifically affects scenarios where an authenticated user possesses Item/Read permissions on at least one job or project within the Jenkins instance. While this permission level is intended to grant visibility into specific jobs, such as viewing build history or configuration details for authorized projects, it inadvertently exposes sensitive data from other unrelated jobs due to a failure in enforcing granular access controls during parameter retrieval operations. The core technical flaw lies in the application's handling of API endpoints and user interface requests that fetch build parameters. When an attacker queries these endpoints, the backend logic fails to validate whether the requesting user has explicit Item/Read or higher-level permissions for the specific job whose parameters are being accessed. Instead, the system relies on a broader check or lacks validation entirely, allowing the retrieval of parameter names and their current or historical values from any job accessible via the Jenkins interface, regardless of the attacker's actual authorization scope for that particular item.
From an operational perspective, this vulnerability facilitates unauthorized information disclosure, which can have severe downstream consequences depending on how build parameters are utilized within the organization's continuous integration and deployment pipelines. Build parameters often contain sensitive configuration data, including database connection strings, API keys, authentication tokens, or paths to internal resources. If an attacker with minimal read access to a single non-sensitive job can enumerate these values across all other jobs in the instance, they gain critical intelligence about the infrastructure architecture and security configurations. This information can be leveraged for further attacks, such as credential stuffing against external services referenced by those parameters, or crafting targeted exploits against internal systems that rely on the exposed secrets. The vulnerability essentially breaks the isolation boundaries between different projects within a shared Jenkins environment, undermining the principle of least privilege that is fundamental to secure DevOps practices.
This flaw aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures in authorization checks where users can access resources they are not permitted to view. In terms of offensive security frameworks, this vulnerability maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as it exploits legitimate credentials that have been granted limited permissions to escalate their informational reach beyond intended boundaries. It also relates to T1530, Data from Cloud Storage Objects, in contexts where Jenkins is used to manage cloud-based artifacts or configurations, although the primary vector here is internal data exfiltration rather than external storage access. The impact is particularly acute in multi-tenant environments or large organizations with numerous isolated projects, as a single low-level account compromise can lead to widespread exposure of sensitive build metadata and secrets across the entire CI/CD ecosystem.
Mitigation for this vulnerability requires immediate upgrading of the Jenkins instance to version 2.579 or later for users on the weekly release track, or LTS version 2.568.3 and later for those on the Long-Term Support track. These versions include patches that enforce strict permission checks when retrieving build parameter information, ensuring that only users with explicit Item/Read permissions for a specific job can access its parameters. In addition to upgrading, organizations should audit their Jenkins security configurations to ensure that the Matrix Authorization Strategy or Role-Based Access Control is configured correctly. It is critical to avoid granting broad administrative privileges and instead assign minimal necessary permissions to each user account. Regularly reviewing who has Item/Read access across all jobs can help identify potential attack surfaces where this vulnerability could be exploited if an update cannot be applied immediately. Furthermore, implementing secret management solutions that do not rely on Jenkins build parameters for storing sensitive data can reduce the impact of such information disclosure vulnerabilities by ensuring that critical credentials are stored in dedicated, more secure vaults rather than within job configurations accessible through standard API endpoints.