CVE-2025-59475

What it actually does

This is an authorization bypass and information disclosure issue in Jenkins core. In Jenkins 2.527 and earlier and Jenkins LTS 2.516.2 and earlier, the authenticated user profile dropdown menu can be queried without enforcing the expected Overall/Read permission. An authenticated user who should not be able to read Jenkins configuration can still enumerate limited UI menu options and infer configuration details, such as whether specific plugins like the Credentials Plugin are installed. The flaw does not provide direct code execution, credential disclosure, job modification, or administrative access by itself, but it can reduce the secrecy of Jenkins configuration and support follow-on reconnaissance.

Why it matters to the business

The primary risk is reconnaissance against a CI/CD platform. A low-privileged authenticated user, including an account that should have minimal or no Jenkins visibility, may learn which capabilities and plugins are present and use that information to plan targeted attacks against build pipelines, credentials handling, or known plugin weaknesses. The CVSS score is moderate-low at 4.3, EPSS is low at 0.00448, there is no CISA KEV listing, and no known ransomware association was provided, so this should generally be prioritized as a routine but important Jenkins hardening update rather than an emergency patch. Because Jenkins often has privileged access to source code, secrets, deployment systems, and build infrastructure, even limited configuration disclosure should be treated seriously in environments where untrusted users can authenticate.

How an attack unfolds

An attacker first obtains any valid Jenkins authentication context, such as a low-privileged user account or an account intentionally denied Overall/Read access. Instead of attempting to access standard Jenkins pages that should be blocked, the attacker requests the authenticated user profile dropdown menu functionality. On vulnerable Jenkins versions, the server returns menu entries without checking whether the user has Overall/Read permission. The attacker reviews the returned options and visible labels to infer configuration details, such as installed plugins or enabled features. The attacker can then use those findings to prioritize additional attacks, for example by looking for known vulnerabilities in installed plugins or tailoring phishing, credential theft, or pipeline-abuse attempts. Exploitation is low-noise and may resemble normal web UI interaction, making post-event detection difficult unless detailed access logging and user permission context are available.

How to fix it

Upgrade Jenkins to a fixed release: Jenkins weekly 2.528 or later, or Jenkins LTS 2.516.3 or later. If building from source, include Jenkins commit 6a3d39f138a1b1cc33759e5f2b34fe0c76378dab or a later commit containing the fix. Where package tracking reports Debian xen entries, confirm applicability with the relevant vendor advisory and update to the listed fixed package version 4.1.3-1 if that package is in scope; the described vulnerability itself is a Jenkins authorization issue. If immediate upgrade is not possible, reduce exposure by limiting who can authenticate to Jenkins, disabling self-registration where enabled, removing dormant accounts, enforcing SSO/MFA, restricting Jenkins access to trusted networks or VPN, and reviewing matrix/role-based permissions so that only intended users have access. These mitigations reduce exploitability but do not correct the missing permission check; upgrading remains the required fix.

How to confirm the fix worked

Confirm the running Jenkins version is Jenkins 2.528 or later, or LTS 2.516.3 or later, from the Jenkins UI, CLI, package manager, container image tag, or WAR metadata. For source-based deployments, verify that commit 6a3d39f138a1b1cc33759e5f2b34fe0c76378dab or a later fixed revision is present. Perform a permission test using an authenticated account that lacks Overall/Read permission: attempts to list user profile dropdown menu items should be denied or should not reveal Jenkins configuration-derived options. Validate that reverse proxies, cached static assets, and old containers or pods have been restarted so the fixed Jenkins core is actually serving traffic. Re-run vulnerability scanners or software composition inventory after upgrade to confirm vulnerable Jenkins core versions are no longer present.

Typical attack path

1. Obtain or create a valid Jenkins login with little or no intended read access.
2. Authenticate to the Jenkins web interface.
3. Request the user profile dropdown menu or related UI endpoint that lists available authenticated-user menu options.
4. Receive menu entries despite lacking Overall/Read permission.
5. Infer Jenkins configuration details, such as whether sensitive plugins or features are installed.
6. Use the discovered configuration details to guide follow-on reconnaissance or attacks against Jenkins, plugins, credentials, jobs, or CI/CD integrations.

How to detect it

There is no known unique exploit payload or post-exploitation artifact for this issue, and successful exploitation may look like normal authenticated Jenkins UI activity. To assess possible prior exploitation, review Jenkins HTTP access logs, reverse proxy logs, WAF logs, SSO logs, and Jenkins audit/security logs if enabled. Focus on authenticated users that lacked Overall/Read permission at the time of access, especially accounts with minimal roles, newly created accounts, dormant accounts, or users outside normal Jenkins administration groups. Look for requests to user profile, account, or dropdown/menu-related endpoints followed by plugin-specific probing, requests for credential-related pages, job enumeration, or repeated authorization failures. If available, correlate each suspicious request with the user’s effective permissions and compare it with normal UI usage patterns. Because the disclosed information is limited and server-side state is not necessarily changed, absence of artifacts does not prove non-exploitation.

What your security team should do

• Inventory all Jenkins controllers, including containerized, ephemeral, development, and internally exposed instances.
• Upgrade vulnerable Jenkins weekly installations to 2.528 or later and LTS installations to 2.516.3 or later.
• Prioritize instances where untrusted, external, contractor, or broadly provisioned users can authenticate to Jenkins.
• Review Jenkins account and permission models; remove accounts that do not require access and ensure users without a business need cannot authenticate.
• Search access logs for low-privileged authenticated users repeatedly requesting profile, user, or menu-related UI resources, especially users that otherwise receive access-denied responses to normal Jenkins pages.
• Correlate any suspicious reconnaissance with subsequent plugin-specific probing, credential-access attempts, job enumeration attempts, or failed administrative requests.
• Ensure Jenkins is behind SSO/MFA and network access controls where feasible.
• Document this as an information disclosure risk that can assist chained attacks rather than as a standalone system-compromise vulnerability.