CVE-2025-27622

What it actually does

Jenkins 2.499 and earlier and Jenkins LTS 2.492.1 and earlier improperly expose encrypted secret values when an agent's config.xml is retrieved through the REST API or Jenkins CLI by a user with Agent/Extended Read permission. The flaw does not directly reveal plaintext credentials, but it discloses encrypted secret blobs that should have been redacted unless the user also has Agent/Configure permission. If an attacker can later obtain Jenkins controller secret material, backups, filesystem access, or another decryption path, those encrypted values may become usable credentials.

Why it matters to the business

This issue can expose sensitive Jenkins agent configuration data to lower-privileged users, increasing the risk of credential compromise, lateral movement, and compromise of build, deployment, or source-control integrations. The CVSS score is moderate and EPSS is low, and it is not listed in CISA KEV, but Jenkins often holds high-value automation credentials, so affected instances should still be upgraded and access logs reviewed, especially where broad Agent/Extended Read access is granted.

How an attack unfolds

An attacker first needs authenticated access to Jenkins with Agent/Extended Read permission for one or more agents but without Agent/Configure permission. The attacker enumerates agents and retrieves their config.xml through the Jenkins web REST interface, such as an agent config.xml URL, or through the Jenkins CLI using node-related commands. On vulnerable versions, the response includes encrypted secret values instead of redacting them. The attacker then saves those encrypted blobs for offline analysis or combines them with other weaknesses, such as access to Jenkins home, controller backups, master.key, or secrets files, to attempt decryption and reuse of credentials against connected systems.

How to fix it

Upgrade Jenkins weekly releases to 2.500 or later, or Jenkins LTS to 2.492.2 or later. For source-based deployments of jenkinsci/jenkins, ensure the fix including commit 02d4db379ac965641bb1382515c834cf4966ec5a is present. As a mitigation until upgrade, restrict Agent/Extended Read permission to only trusted administrators, remove broad read-only access to agent configuration, limit Jenkins CLI access where not required, and review role-based authorization rules. If encrypted secret values may have been exposed, assess whether the attacker could also access Jenkins controller secret material; rotate affected credentials when exposure cannot be ruled out.

How to confirm the fix worked

Confirm the running Jenkins version is 2.500 or later, or LTS 2.492.2 or later. Create or use a test account that has Agent/Extended Read permission but not Agent/Configure permission, then retrieve an agent config.xml through the REST API and Jenkins CLI. The returned XML should redact encrypted secret values rather than showing encrypted blobs. Also verify that users without Agent/Configure cannot retrieve sensitive agent configuration values through API tokens, browser sessions, or CLI authentication. Review authorization matrices or role strategy configuration to ensure Agent/Extended Read is not granted more broadly than intended.

Typical attack path

1. Obtain or use a Jenkins account with Agent/Extended Read permission.
2. Enumerate configured Jenkins agents/nodes visible to that account.
3. Request each agent's config.xml through the REST API or retrieve node configuration through the Jenkins CLI.
4. Extract encrypted secret values that are present in the returned XML.
5. Attempt to decrypt or reuse the exposed material if Jenkins controller secret files, backups, or other decryption prerequisites are available.
6. Use any recovered credentials to access source code, build infrastructure, deployment targets, artifact repositories, or cloud resources.

How to detect it

Look for authenticated access to Jenkins agent configuration XML by users who should not administer agents. Useful sources include Jenkins access logs, reverse proxy or load balancer logs, web server logs, Jenkins audit trail plugin logs if enabled, authentication logs, and CLI access records. Focus on GET requests for agent config.xml paths, repeated retrieval across multiple agents, and CLI node configuration commands such as get-node. Correlate these events with accounts holding Agent/Extended Read but not Agent/Configure permission. If suspicious access is identified, preserve the returned response evidence where available, check whether the same actor accessed Jenkins backups or controller filesystem secrets, and review downstream systems for use of credentials stored in agent configuration.

• GET /computer/
• /config.xml
• GET /computer/[^/]+/config.xml
• GET /computer/(built-in)/config.xml
• POST /cli
• get-node
• <secret>{
• <password>{
• <privateKey>{
• Agent/ExtendedRead

What your security team should do

• Upgrade all affected Jenkins controllers to 2.500 or later, or LTS 2.492.2 or later.
• Inventory users, groups, service accounts, and roles with Agent/Extended Read permission and remove unnecessary access.
• Review Jenkins access logs, reverse proxy logs, and audit logs for agent config.xml retrievals and Jenkins CLI node configuration access before the upgrade.
• If suspicious access is found, determine whether exposed encrypted values were paired with access to Jenkins home, backups, master.key, or secrets files.
• Rotate credentials stored in affected agent configurations when unauthorized access or decryption risk cannot be excluded.
• Restrict Jenkins CLI exposure and require strong authentication, least-privilege authorization, and network access controls for Jenkins administration endpoints.
• Add monitoring for unusual config.xml access patterns, especially repeated requests across many agents by non-administrative users.