CVE-2025-67636

What it actually does

Jenkins 2.540 and earlier and Jenkins LTS 2.528.2 and earlier contain a missing authorization check in view-related functionality. An authenticated user who has View/Read permission can access encrypted password values associated with views that should not be visible at that permission level. The issue is an authorization bypass and primarily impacts confidentiality: it exposes encrypted secret material rather than directly granting code execution or administrative control. The leaked values may become more serious if combined with access to Jenkins controller secrets, backups, filesystem contents, or other weaknesses that allow decryption or reuse analysis.

Why it matters to the business

The main operational risk is exposure of sensitive automation secrets used by Jenkins jobs, integrations, or view configurations. Even though the disclosed values are encrypted, leaked secret material can increase the blast radius of a later Jenkins compromise, create compliance concerns, and force secret review or rotation if unauthorized access is suspected. The vulnerability is not listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the provided data, so it is generally lower urgency than remote code execution or unauthenticated Jenkins issues; however, Jenkins commonly has access to source code, deployment systems, credentials, and production automation, so affected instances should still be remediated in a normal patch cycle.

How an attack unfolds

An attacker first obtains a valid Jenkins account or compromises an existing low-privileged account. The account does not need administrator privileges; View/Read permission is sufficient. The attacker then browses accessible Jenkins views or queries view-related endpoints and observes encrypted password fields that should have been hidden by a permission check. The attacker collects these encrypted values and may attempt to correlate them with known jobs, integrations, or credentials. On its own, the flaw exposes encrypted values, not necessarily plaintext passwords. The attacker’s next objective would typically be to combine the ciphertext with other Jenkins artifacts, such as controller secrets, backups, configuration files, or additional vulnerabilities, to decrypt or make operational use of the exposed secrets.

How to fix it

Upgrade affected Jenkins controllers to a fixed Jenkins release containing the authorization check fix. The provided fixed reference is jenkinsci/jenkins commit 40e29179c3edf88b685d7043ab7c37cc8591138f. Environments running Jenkins weekly 2.540 or earlier, or Jenkins LTS 2.528.2 or earlier, should move to a vendor-supported fixed weekly or LTS release that includes this commit. Until patched, restrict Jenkins access to trusted networks, review and minimize View/Read assignments, remove unnecessary anonymous or broad group read access, and avoid exposing Jenkins directly to the internet. If logs suggest unauthorized access to sensitive views, review affected credentials and rotate secrets whose encrypted values may have been exposed, especially secrets tied to deployment, source control, artifact repositories, cloud providers, or production systems.

How to confirm the fix worked

Confirm the Jenkins controller version is no longer Jenkins 2.540 or earlier and no longer Jenkins LTS 2.528.2 or earlier, or verify that the deployed build contains commit 40e29179c3edf88b685d7043ab7c37cc8591138f. Review the Jenkins About page, package metadata, container image tag, or WAR manifest to validate the active runtime version rather than only checking installed files. Test with a non-administrative account that has only View/Read permission: it should be able to read allowed views but should not see encrypted password values in view pages, view configuration representations, or view-related API responses. Also verify that broad read permissions, anonymous read access, and inherited group permissions are still aligned with least privilege after the upgrade.

Typical attack path

1. Acquire valid Jenkins credentials through phishing, credential stuffing, insider access, or compromise of a low-privileged account.
2. Authenticate to a Jenkins controller running an affected version: Jenkins 2.540 or earlier, or Jenkins LTS 2.528.2 or earlier.
3. Use the account’s View/Read permission to access available Jenkins views.
4. Request view pages or view-related API/configuration representations that expose encrypted password values due to the missing permission check.
5. Collect the encrypted password values and map them to projects, jobs, or integrations where possible.
6. Attempt follow-on abuse by combining the encrypted values with Jenkins controller secrets, filesystem access, backups, configuration exports, or other vulnerabilities that may allow decryption or credential misuse.

How to detect it

Investigating exploitation requires looking for authenticated access patterns rather than malware artifacts. Review reverse proxy access logs, Jenkins access logs, Jenkins audit trail plugin events if enabled, web server logs, identity provider sign-in logs, and session records. Focus on users with only View/Read or otherwise low privileges who accessed view pages, view API endpoints, or configuration-style endpoints after the vulnerable version was deployed. Look for enumeration behavior such as one account requesting many different /view/ paths, repeated /api/json or /api/xml calls against views, unusual use of tree/depth query parameters, access from unfamiliar IP addresses, or activity outside normal working hours. If full HTTP response capture, proxy debug logs, browser forensic artifacts, or DLP telemetry are available, search for Jenkins encrypted secret markers such as {AQAA in responses associated with view requests. Because the vulnerability discloses encrypted values and does not necessarily create server-side errors, Jenkins application logs may not show obvious failures; correlate access logs with permission levels and subsequent credential misuse, repository access, deployment actions, cloud logins, or artifact repository authentication from the same user, IP, or time window.

• GET /view/
• /view/
• /api/json
• /api/xml
• tree=
• depth=
• config.xml
• {AQAA
• password={AQAA
• hudson.util.Secret

What your security team should do

• Inventory all Jenkins controllers and identify any running Jenkins 2.540 or earlier, or Jenkins LTS 2.528.2 or earlier.
• Upgrade affected controllers to a fixed release containing commit 40e29179c3edf88b685d7043ab7c37cc8591138f, prioritizing internet-accessible, shared, or production-connected controllers.
• Review Jenkins authorization strategy and remove unnecessary View/Read access from anonymous users, broad groups, service accounts, and inactive users.
• Audit recent access to Jenkins view URLs and APIs by low-privileged accounts, especially accounts that accessed many views or normally do not use Jenkins interactively.
• If suspicious access is found, identify secrets potentially exposed through affected views and rotate high-value credentials such as source control tokens, deployment keys, artifact repository credentials, cloud keys, and production automation secrets.
• Ensure Jenkins access logs, reverse proxy logs, authentication logs, and audit trail events are retained long enough to investigate historical access because the issue was published 242 days ago.
• Harden Jenkins by requiring SSO or MFA where possible, restricting administrative and read access by network, disabling anonymous read unless explicitly required, and monitoring for unusual API enumeration.