CVE-2024-47804 in Jenkins
Summary
by MITRE • 10/02/2024
If an attempt is made to create an item of a type prohibited by `ACL#hasCreatePermission2` or `TopLevelItemDescriptor#isApplicableIn(ItemGroup)` through the Jenkins CLI or the REST API and either of these checks fail, Jenkins 2.478 and earlier, LTS 2.462.2 and earlier creates the item in memory, only deleting it from disk, allowing attackers with Item/Configure permission to save the item to persist it, effectively bypassing the item creation restriction.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/13/2024
This vulnerability exists in Jenkins versions 2.478 and earlier, as well as LTS versions 2.462.2 and earlier, where a critical authorization bypass occurs during item creation processes. The flaw manifests when the system attempts to create items that should be prohibited by access control mechanisms, specifically when either ACL#hasCreatePermission2 or TopLevelItemDescriptor#isApplicableIn(ItemGroup) checks fail. The vulnerability stems from improper handling of failed authorization checks, creating a scenario where restricted items are instantiated in memory despite failing permission validations. This design flaw allows attackers with Item/Configure permission to circumvent intended restrictions by creating items that would normally be blocked by the system's access control policies. The memory-based instantiation occurs before the disk deletion process, creating a window where the item exists temporarily in the system's runtime environment. This represents a significant security regression that undermines the fundamental access control mechanisms Jenkins employs to protect its configuration and build environments. The vulnerability directly relates to CWE-284 Access Control Bypass, where insufficient authorization checks allow unauthorized operations to proceed despite explicit restrictions.
The technical implementation of this vulnerability involves the interaction between Jenkins' CLI and REST API interfaces with its core access control system. When a user attempts to create a prohibited item through either interface, the system should reject the operation based on either the ACL permission checks or the item descriptor applicability validation. However, the flawed implementation allows the creation process to continue in memory even when these checks fail, resulting in a temporary item state that exists in the system's runtime memory. The item creation process fails to properly abort when authorization checks are denied, instead proceeding to instantiate the item in memory before ultimately deleting it from disk. This creates a race condition where the item can be saved to disk by users with Item/Configure permissions, effectively persisting the restricted item despite the initial authorization failure. The operational impact is particularly severe because it allows attackers to bypass the intended security boundaries that protect against unauthorized item creation, potentially enabling them to establish malicious configurations or build environments.
The security implications of this vulnerability extend beyond simple access control bypass, as it enables attackers to potentially establish persistent footholds within Jenkins environments. Attackers with Item/Configure permissions can leverage this flaw to create items that would normally be restricted, effectively undermining the security model that protects against unauthorized modifications to the Jenkins configuration. This vulnerability particularly impacts organizations that rely on strict access controls to manage their CI/CD pipelines and build environments. The ability to bypass item creation restrictions can lead to unauthorized pipeline modifications, compromised build integrity, and potential privilege escalation within the Jenkins environment. The vulnerability affects both the command-line interface and REST API endpoints, providing multiple attack vectors for exploitation. Organizations using older Jenkins versions are particularly vulnerable as they cannot benefit from the fixes implemented in later releases that properly handle authorization failures during item creation. This flaw represents a critical gap in Jenkins' security architecture that could allow attackers to establish persistent unauthorized configurations.
Mitigation strategies for this vulnerability require immediate version upgrades to Jenkins 2.479 or later for standard releases, and LTS 2.462.3 or later for long-term support versions. Organizations should also implement additional monitoring of item creation activities, particularly focusing on items created by users with Item/Configure permissions. The security team should review existing access control policies and ensure that users have only the minimum required permissions necessary for their roles. Implementing automated security scanning tools that can detect unauthorized item creation patterns can provide additional layers of protection. Organizations should also consider implementing network segmentation and access controls that limit direct access to Jenkins APIs, reducing the attack surface for exploitation. The fix implemented in newer Jenkins versions properly handles failed authorization checks by ensuring that item creation operations are completely aborted when permission validation fails, preventing the memory instantiation that enables this bypass. This aligns with ATT&CK technique T1078 Valid Accounts, where unauthorized access is gained through legitimate credentials, but in this case, the bypass occurs through a system design flaw rather than credential compromise. Regular security audits should be conducted to verify that access control mechanisms are functioning correctly and that no unauthorized items have been persisted through this vulnerability.