CVE-2025-31721

What it actually does

Jenkins 2.503 and earlier and Jenkins LTS 2.492.2 and earlier contain an authorization bypass in an HTTP endpoint used to copy agents/nodes. The endpoint enforced Computer/Create permission but failed to require Computer/Configure permission when the source agent configuration contained encrypted secrets. A user who is allowed to create agents, but not configure existing agents, can copy an existing agent and obtain access to secret-bearing configuration material that should have remained restricted. The issue is an incomplete fix for the earlier SECURITY-3495/CVE-2025-27622 authorization flaw. The impact is primarily confidentiality of Jenkins-managed secrets and integrity of agent configuration boundaries, rather than unauthenticated remote code execution.

Why it matters to the business

Organizations using Jenkins for CI/CD may expose build infrastructure secrets such as agent credentials, connection secrets, launch configuration values, or other encrypted configuration data to lower-privileged Jenkins users. If those secrets are reused for source control, artifact repositories, deployment targets, cloud environments, or internal systems, an attacker could pivot from Jenkins into the software delivery pipeline. The public exploitation signal is currently low: EPSS is approximately 0.00375, no known CISA KEV listing is present, and no exploit maturity was reported; however, Jenkins often holds high-value credentials, so the business risk depends heavily on how broadly Computer/Create permission is delegated.

How an attack unfolds

An attacker first needs authenticated access to Jenkins with Computer/Create permission. They do not need Computer/Configure permission on the existing agent they want to copy. The attacker identifies an existing Jenkins agent whose configuration may include encrypted secrets, such as launch credentials, connection parameters, or plugin-specific secret fields. They then invoke the vulnerable agent-copy HTTP workflow, commonly associated with the Jenkins computer/node creation endpoint, and request that Jenkins create a new agent by copying the target agent. Because the vulnerable versions do not enforce the additional Computer/Configure permission check, Jenkins creates the copied agent for the attacker. The attacker can then inspect or use the copied agent configuration and potentially gain access to encrypted secret values or secret-backed operational capabilities that were intended to be restricted to users with configuration privileges.

How to fix it

Upgrade Jenkins to a fixed release: Jenkins weekly 2.504 or later, or Jenkins LTS 2.492.3 or later. For source-based deployments, ensure the Jenkins codebase includes commit a5462bf4af2a2c56c46be70e98636ccf3a070bbd or a later equivalent fix. After patching, review Jenkins role and permission assignments and restrict Computer/Create to trusted administrators or tightly controlled automation identities. Avoid granting broad agent creation rights to general developers unless there is a clear operational need. Rotate any credentials or secrets that may have been stored in agent/node configurations if unauthorized copying is suspected. As a compensating control before upgrade, remove Computer/Create permission from non-administrative users, restrict access to agent creation endpoints through reverse proxy or network controls where feasible, and monitor for attempts to copy agents.

How to confirm the fix worked

Confirm the Jenkins controller version is Jenkins 2.504 or later, or Jenkins LTS 2.492.3 or later. In Jenkins, check the version from the UI footer, the About Jenkins page, package metadata, container image tag, or the Jenkins CLI where available. Validate authorization behavior by testing with a non-administrative account that has Computer/Create permission but not Computer/Configure permission: attempts to copy an existing agent containing secrets should be denied or require Computer/Configure permission. Review authorization matrices or role-based strategy configuration to ensure Computer/Create is not broadly assigned. Confirm no unexpected agents/nodes were created during the exposure window, and compare node creation times, creators, and configuration changes against approved administrative activity.

Typical attack path

1. Obtain authenticated Jenkins access through a legitimate account, compromised account, or overly permissive role assignment.
2. Confirm the account has Computer/Create permission but lacks Computer/Configure permission on one or more existing agents.
3. Enumerate Jenkins agents/nodes and identify a source agent likely to contain sensitive launch or connection configuration.
4. Send a crafted or normal HTTP request to the Jenkins agent creation/copy endpoint using copy mode and the selected source agent.
5. Create a new copied agent despite lacking permission to configure the source agent.
6. Inspect, reuse, or abuse the copied agent configuration and any exposed encrypted secret-bearing values.
7. Use obtained CI/CD secrets or agent capabilities to access build systems, repositories, artifacts, deployment infrastructure, or other connected services.

How to detect it

Investigate whether authenticated users created agents by copying existing agents during the vulnerable period. Primary log sources include Jenkins access logs, reverse proxy logs, web server logs, Jenkins system logs, audit trail plugin logs if enabled, controller filesystem metadata under the Jenkins nodes directory, and identity provider logs for suspicious Jenkins sessions. Look for POST requests to the computer/node creation endpoint with copy mode parameters, especially from users who did not have Computer/Configure permission. Correlate those requests with newly created directories under the Jenkins nodes storage area and changes to node config.xml files. Review Jenkins administrative/audit events for node creation, node copy, or configuration reads by lower-privileged users. Because this vulnerability abuses legitimate authenticated functionality, detection should focus on authorization anomalies: agent copies performed by users or service accounts that normally do not administer agents, copied agents created shortly after login from unusual IP addresses, and newly created agents whose configuration resembles an existing secret-bearing agent. If suspicious activity is found, preserve Jenkins logs, relevant node config.xml files, user permission configuration, and authentication logs, then rotate secrets referenced by the affected source and copied agents.

• POST /computer/doCreateItem
• /computer/doCreateItem?
• mode=copy
• &mode=copy
• from=
• /computer/
• /node/
• $JENKINS_HOME/nodes/
• nodes/*/config.xml
• config.xml
• doCreateItem
• copyAgent
• Copy existing Node
• Copy existing node

What your security team should do

• Prioritize upgrade to Jenkins 2.504 or later, or LTS 2.492.3 or later, especially on internet-accessible or broadly used CI/CD controllers.
• Immediately audit Jenkins users and groups with Computer/Create permission and remove it from roles that do not require agent provisioning capability.
• Search access logs and audit logs for agent copy operations, especially requests to the computer/node creation endpoint using copy mode.
• Inventory Jenkins agents created during the vulnerable period and investigate any unexpected copied agents or suspicious node configuration changes.
• Rotate credentials referenced in agent/node configuration if unauthorized copying is found or cannot be ruled out.
• Enable or tune Jenkins audit logging, reverse proxy access logging, and administrative event monitoring for node creation and configuration events.
• Restrict administrative Jenkins endpoints to trusted networks and require strong authentication, MFA/SSO where supported, and least-privilege role design.
• Review related prior remediation for SECURITY-3495/CVE-2025-27622 to ensure fixes were fully applied and no partial or backported build remains vulnerable.