CVE-2024-47804

What it actually does

This is an authenticated authorization bypass in Jenkins item creation through the CLI and REST API. Jenkins is intended to enforce fine-grained restrictions that can prevent specific item types from being created in specific item groups, using checks such as ACL#hasCreatePermission2 and TopLevelItemDescriptor#isApplicableIn(ItemGroup). In Jenkins 2.478 and earlier and Jenkins LTS 2.462.2 and earlier, when a prohibited item creation attempt fails those checks, Jenkins deletes the item from disk but incorrectly leaves the newly created item object in memory. A user with Item/Create permission can therefore temporarily create an item type that policy should have blocked. If the same user also has Item/Configure permission, they can save the item and make it persistent. The flaw is fixed in Jenkins 2.479, Jenkins LTS 2.462.3, and upstream commit c91a0e9cac1832e8f638e2be91cb972393ac1e93.

Why it matters to the business

The primary risk is governance and CI/CD control bypass rather than unauthenticated compromise. A user who already has some Jenkins item-creation rights may create job or item types that administrators intentionally prohibited, potentially weakening separation of duties, folder-level controls, job-type restrictions, compliance guardrails, and pipeline execution policy. In higher-risk Jenkins deployments, this can lead to unauthorized build jobs, unauthorized pipeline definitions, persistence of disallowed jobs, misuse of build agents, or exposure of credentials available to jobs in that scope. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns from the provided data, has low EPSS likelihood, and requires authentication, so it should be prioritized below externally exploitable critical Jenkins issues but still remediated as part of routine Jenkins security maintenance.

How an attack unfolds

An attacker first needs valid Jenkins access with permission to create items in a relevant scope. They identify a folder or item group where the authorization strategy or the item descriptor should prohibit creation of a specific item type. Instead of using normal UI workflows, they submit an item creation request through the Jenkins REST API or Jenkins CLI. On vulnerable versions, Jenkins evaluates the restriction and removes the prohibited item from disk, but the item remains live in memory. This gives the attacker a temporary item that policy should not have allowed. If the attacker also has Item/Configure permission, they can modify and save the item configuration, causing Jenkins to write it back to disk and preserve it across normal operations. Depending on the prohibited item type and the permissions available to that item, the attacker may then use the unauthorized item to run builds, define pipelines, access scoped credentials, or bypass organizational controls over which job types may exist in a folder.

How to fix it

Upgrade Jenkins controllers to a fixed release: Jenkins weekly 2.479 or later, or Jenkins LTS 2.462.3 or later. For source-based deployments, ensure the fix corresponding to commit c91a0e9cac1832e8f638e2be91cb972393ac1e93 is present. After upgrading, restart Jenkins so any unauthorized in-memory items cannot remain active. Review and remove any unexpected jobs, folders, multibranch projects, pipelines, or other items in restricted folders. As compensating controls until upgrade, restrict Jenkins CLI access, limit REST API item creation to trusted administrators, minimize Item/Create and Item/Configure permissions, enforce least privilege on folders, and monitor for unexpected item creation attempts using /createItem endpoints or CLI create-job activity.

How to confirm the fix worked

Confirm the Jenkins controller version is Jenkins 2.479 or later, or Jenkins LTS 2.462.3 or later. If validating from source, confirm commit c91a0e9cac1832e8f638e2be91cb972393ac1e93 or its equivalent patch is included. Review installed Jenkins version from the Manage Jenkins interface, the /login footer, the CLI version output, package metadata, or the WAR manifest. Functionally validate by attempting, with a non-administrative test account, to create an item type that should be prohibited in a restricted folder through both REST API and Jenkins CLI; the item should be rejected and should not appear in memory, in the UI, through API listing, or on disk. After remediation, enumerate jobs and folders and compare against approved configuration-as-code or inventory baselines to identify any disallowed items created before the fix.

Typical attack path

1. Obtain authenticated Jenkins access with Item/Create permission in a target folder or item group.
2. Identify an item type that the folder policy, authorization strategy, or descriptor applicability rules should prohibit.
3. Use the Jenkins REST API or Jenkins CLI to attempt creation of the prohibited item type instead of relying on the web UI workflow.
4. Trigger the vulnerable failure path where Jenkins deletes the item from disk but retains the item in memory.
5. Interact with the temporary in-memory item before it is removed or the controller is restarted.
6. If Item/Configure permission is available, save or reconfigure the item so it becomes persistent on disk.
7. Use the unauthorized item to bypass job-type restrictions, execute permitted build functionality, or access resources available to that item scope.

How to detect it

Look for evidence of authenticated users creating items through Jenkins REST API or CLI in scopes where that item type should have been prohibited. Useful sources include Jenkins access logs, reverse proxy logs, web server logs, Jenkins controller logs, audit trail plugin logs if deployed, security realm authentication logs, job configuration history, filesystem timestamps under JENKINS_HOME, and source-controlled configuration-as-code repositories. Focus on POST requests to createItem endpoints, CLI create-job usage, item creation followed by immediate deletion or configuration save, and new config.xml files under folders that should not allow that item type. Because the vulnerable behavior can leave a temporary in-memory item, disk-only forensics may miss exploitation unless the attacker saved the item; correlate access logs with Jenkins item inventory and audit events. Investigate any prohibited item that exists persistently after a failed creation attempt, any job created by a user whose role should not permit that item type, and any unusual build executions from newly created items. No public threat actor exploitation is provided in the input, so detection should emphasize behavioral anomalies rather than actor-specific infrastructure.

• POST /createItem
• POST /job/
• /createItem?name=
• createItem
• jenkins-cli.jar create-job
• create-job
• hudson.cli.CreateJobCommand
• config.xml
• JENKINS_HOME/jobs/
• JENKINS_HOME/jobs/*/config.xml
• JENKINS_HOME/jobs/*/jobs/*/config.xml
• Item/Create
• Item/Configure

What your security team should do

• Upgrade all Jenkins controllers to Jenkins 2.479 or later, or Jenkins LTS 2.462.3 or later, during the next maintenance window.
• Restart Jenkins after patching to clear any vulnerable in-memory state.
• Audit users and groups with Item/Create and Item/Configure permissions, especially in folders that rely on job-type restrictions.
• Temporarily restrict Jenkins CLI and REST API item creation to administrators if immediate patching is not possible.
• Review all recently created or modified Jenkins items for prohibited types in folders where those types should not exist.
• Search Jenkins access logs and audit logs for REST API /createItem calls and CLI create-job activity by non-administrative users.
• Compare current Jenkins item inventory with configuration-as-code, source-controlled job definitions, or other approved baselines.
• Investigate unexpected config.xml changes, newly persisted jobs, or jobs created shortly before or after failed item-creation attempts.
• Ensure build agents and credentials are scoped so that unauthorized jobs cannot access sensitive secrets or production deployment capabilities.