CVE-2025-27623

What it actually does

Jenkins 2.499 and earlier and Jenkins LTS 2.492.1 and earlier expose encrypted secret values stored in view configuration when a user with only View/Read permission retrieves a view's config.xml through the REST API or Jenkins CLI. The flaw does not directly reveal plaintext secrets, but it leaks encrypted secret blobs that should have been redacted from users lacking View/Configure permission. Those blobs may become valuable if combined with Jenkins controller filesystem access, backups, key material, plugin weaknesses, misconfigurations, or later privilege escalation that enables decryption or reuse of the protected values.

Why it matters to the business

The primary risk is unauthorized exposure of CI/CD-related secret material, which can increase the blast radius of a low-privileged Jenkins account. If leaked encrypted secrets are later decrypted or abused, attackers may gain access to source repositories, build systems, artifact stores, deployment credentials, cloud resources, or downstream production environments. The vulnerability has a moderate CVSS score, low EPSS, no known CISA KEV listing, no reported ransomware association, and no public exploit maturity indicated, but Jenkins often holds high-value automation credentials, so organizations should still treat affected internet-facing or broadly accessible Jenkins controllers as sensitive.

How an attack unfolds

An attacker first obtains valid Jenkins credentials or session access for an account that has View/Read permission on one or more views but does not have View/Configure permission. The attacker then requests the view configuration XML using either the Jenkins REST endpoint for the view or the Jenkins CLI command that exports view configuration. On vulnerable versions, Jenkins returns config.xml content containing encrypted secret values instead of redacting them. The attacker collects these encrypted blobs for offline analysis, correlation with other Jenkins data, or later use after obtaining additional access such as controller filesystem access, backups, master key material, administrative privileges, or another vulnerability that enables secret decryption. The attack is therefore most useful as a credential-material collection step that supports follow-on compromise rather than as a standalone plaintext credential theft issue.

How to fix it

Upgrade Jenkins weekly releases to 2.500 or later, or Jenkins LTS to 2.492.2 or later. The upstream fix redacts encrypted secret values in view config.xml responses for users who have View/Read but lack View/Configure permission. If building from source, ensure the Jenkins codebase includes commit 02d4db379ac965641bb1382515c834cf4966ec5a or a later equivalent. As compensating controls before upgrade, restrict View/Read permission to trusted users, remove unnecessary anonymous or broad authenticated read access, limit Jenkins CLI access, restrict direct access to Jenkins endpoints with network controls, review views that may contain credentials or plugin-provided secret fields, and rotate credentials if logs or access history indicate suspicious config.xml retrieval.

How to confirm the fix worked

Confirm the Jenkins controller reports a fixed version: weekly 2.500 or later, or LTS 2.492.2 or later. Validate authorization behavior with a non-administrative test account that has View/Read but not View/Configure permission: request a view's config.xml through the REST API and, if enabled, Jenkins CLI, and verify encrypted secret fields are redacted rather than returned. Also confirm users without a business need do not have View/Read on sensitive views, anonymous read access is disabled unless explicitly required, and Jenkins CLI exposure is limited. Review plugin compatibility after upgrade because view configuration may include plugin-defined secret-bearing fields.

Typical attack path

1. Obtain or compromise a Jenkins account with View/Read permission on one or more views.
2. Enumerate accessible views in the Jenkins UI, REST API, or CLI.
3. Request the view configuration XML via /view/<view-name>/config.xml or the Jenkins CLI view export functionality.
4. Save any encrypted secret values returned in the XML response.
5. Attempt to combine the leaked encrypted values with additional access, backups, Jenkins controller files, keys, or later privilege escalation to decrypt or abuse the secret material.
6. Use recovered or reusable credentials to pivot into source control, CI/CD pipelines, artifact repositories, cloud services, or deployment targets.

How to detect it

To determine whether this was already exploited, review Jenkins HTTP access logs, reverse proxy or load balancer logs, web application firewall logs, Jenkins audit trail plugin logs if deployed, and Jenkins controller logs for requests that retrieved view configuration XML. Focus on authenticated users with View/Read but not View/Configure permission, unusual source IPs, high-volume enumeration of multiple views, access outside normal administrative windows, and CLI-based configuration export activity. Key patterns include HTTP GET requests to /view/<name>/config.xml, nested view paths ending in /config.xml, and Jenkins CLI invocations that export view XML such as get-view. Because the vulnerability exposes encrypted rather than plaintext values, exploitation may leave only access artifacts; correlate any suspicious retrieval with subsequent credential misuse, SCM access anomalies, new or modified jobs, unexpected builds, credential changes, new API tokens, or changes to deployment destinations. If suspicious config.xml access occurred and the controller filesystem, backups, or key material may also have been exposed, treat related secrets as potentially compromised and rotate them.

• GET /view/
• /config.xml
• GET /view/*/config.xml
• POST /cli
• /cli?remoting=false
• jenkins-cli.jar get-view
• get-view
• hudson.cli.CLI
• X-Jenkins-CLI
• <secret>{AQAA
• {AQAAABAAAA
• <password>{AQAA
• <token>{AQAA
• <apiToken>{AQAA

What your security team should do

• Prioritize upgrading affected Jenkins controllers to weekly 2.500 or later or LTS 2.492.2 or later, especially controllers reachable from untrusted networks or used for deployment automation.
• Audit Jenkins authorization strategy for excessive View/Read access, broad authenticated read access, and anonymous access to views.
• Search Jenkins access logs, reverse proxy logs, and audit logs for unusual or repeated access to /view/*/config.xml and Jenkins CLI view export activity before the patch date.
• If suspicious access is found, identify which views were accessed and assess whether their configurations contained credential or secret-bearing fields.
• Rotate credentials referenced by affected views or related plugins if encrypted secret values may have been exposed to untrusted users or if controller key material may also have been accessible.
• Restrict or disable Jenkins CLI where not required, and enforce network allowlisting or SSO controls for Jenkins administrative and API access.
• Monitor for follow-on misuse of CI/CD credentials, including unusual SCM access, build job changes, artifact publication, credential creation, or deployment activity.