CVE-2025-59474

What it actually does

The flaw is an authorization bypass in Jenkins where a sidepanel executors widget is rendered on a page that is intentionally reachable by users who do not have Overall/Read permission. Because the sidepanel failed to enforce the same permission boundary as the rest of the Jenkins UI, an unauthenticated or low-privileged attacker, depending on the instance’s access-control configuration, can enumerate Jenkins agent/node names. The issue does not directly provide code execution, credential access, or job modification, but it discloses internal CI/CD infrastructure metadata that can support follow-on attacks. Jenkins 2.528 and Jenkins LTS 2.516.3 remove the affected sidepanel from the exposed view.

Why it matters to the business

This vulnerability can expose the names of Jenkins build agents, which often reveal operating systems, environments, projects, business functions, or deployment tiers. While the direct severity is moderate, the intelligence value can be high for attackers targeting CI/CD pipelines because agent names can guide phishing, credential attacks, exploit selection, and lateral-movement planning. The exploit maturity is reported as weaponized, so internet-exposed Jenkins controllers should be treated with elevated urgency even though the issue is not currently listed in CISA KEV and is not known to be associated with ransomware campaigns. Organizations with many Jenkins instances or downstream automation dependencies may face increased exposure because CI/CD metadata often maps closely to production delivery paths.

How an attack unfolds

An attacker first identifies a reachable Jenkins controller and determines that at least one page is accessible without the normal Overall/Read permission. The attacker then requests the affected view and causes Jenkins to render the sidepanel executors widget. Because the widget lacks the required permission check, the response includes executor information that reveals Jenkins agent names. The attacker collects those names and uses them to infer internal architecture, build platforms, project names, environment naming conventions, or privileged automation targets. In a broader intrusion, this reconnaissance can be chained with credential stuffing, exposed plugin vulnerabilities, misconfigured agents, or social engineering against CI/CD administrators and developers.

How to fix it

Upgrade Jenkins controllers to a fixed release: Jenkins weekly 2.528 or later, or Jenkins LTS 2.516.3 or later. For source-based deployments, ensure the Jenkins codebase includes commit 6a3d39f138a1b1cc33759e5f2b34fe0c76378dab, which removes the affected sidepanel from the exposed view. If Jenkins is provided through an operating-system or vendor package, apply the vendor’s corrected package; the supplied package metadata lists xen on Debian 11, 12, and 13 as fixed in 4.1.3-1, but this should be validated against the relevant vendor advisory because the described vulnerable product is Jenkins. As compensating controls, restrict Jenkins controller access to trusted networks or VPNs, require authentication wherever possible, disable anonymous access unless explicitly required, review matrix/security-realm permissions, and avoid exposing CI/CD interfaces directly to the internet.

How to confirm the fix worked

Confirm the installed Jenkins version is 2.528 or later for weekly releases, or 2.516.3 or later for LTS releases. In Jenkins, check the version from the footer, the About page, package manager metadata, container image tag, or the WAR manifest. Validate that unauthenticated users or users lacking Overall/Read permission can no longer view agent names from the affected page or sidepanel. Test from a clean browser session or low-privileged test account and verify that executor/agent information is not present in the returned HTML or related AJAX responses. For source builds, verify that commit 6a3d39f138a1b1cc33759e5f2b34fe0c76378dab or an equivalent fix is present. Also review reverse-proxy and Jenkins access logs to ensure no anonymous or unauthorized principals are still able to request executor-related endpoints successfully.

Typical attack path

1. Discover a reachable Jenkins controller through internet scanning, search engines, asset inventories, or internal reconnaissance.
2. Access a Jenkins page that is intentionally available to users without Overall/Read permission.
3. Request or refresh the affected page/sidebar content that includes the executors widget.
4. Extract Jenkins agent/node names from the returned HTML or AJAX response.
5. Use the disclosed agent names to infer infrastructure roles, operating systems, project names, or deployment environments.
6. Pivot to follow-on attacks such as targeted credential attacks, Jenkins plugin exploitation, agent compromise attempts, or CI/CD pipeline reconnaissance.

How to detect it

To determine whether this was already exploited, review Jenkins access logs, reverse-proxy logs, load-balancer logs, WAF logs, and identity-provider authentication logs for requests to Jenkins pages by anonymous users, unauthenticated sessions, or accounts that lack Overall/Read permission. Focus on requests around view pages, executor sidebar refresh endpoints, and computer/node-related URLs, especially when followed by login attempts, plugin/version probing, job enumeration, or requests from unfamiliar internet scanners. Compare source IPs and user agents against known scanning activity and correlate repeated 200 responses from unauthenticated clients with subsequent authentication failures or administrative endpoint probes. On Jenkins controllers, review security logs, audit plugins if installed, and access logs for principals such as anonymous, missing usernames, or sessions that only accessed UI metadata endpoints. Since the primary impact is information disclosure, there may be no file-system artifact or process artifact; successful exploitation is most likely visible as web access patterns and returned-page access rather than a persistent host indicator.

• GET /ajaxExecutors
• POST /ajaxExecutors
• GET /view/
• GET /computer/
• GET /computer/api/json
• GET /computer/(built-in)/
• GET /computer/master/
• GET /computer/slave-agent.jnlp
• GET /computer/agent.jnlp
• anonymous GET /ajaxExecutors
• anonymous GET /view/
• Overall/Read
• X-Jenkins

What your security team should do

• Prioritize upgrading internet-accessible Jenkins controllers to Jenkins 2.528+ or LTS 2.516.3+ because exploitation is reported as weaponized.
• Inventory all Jenkins controllers, including ephemeral, lab, development, and containerized instances, and identify versions at or below Jenkins 2.527 or LTS 2.516.2.
• Disable or tightly limit anonymous access, and confirm that users without Overall/Read cannot access pages that expose operational CI/CD metadata.
• Restrict Jenkins administrative and web access behind VPN, private networking, SSO, or allowlisted reverse proxies where feasible.
• Search historical web, reverse-proxy, WAF, and Jenkins access logs for unauthenticated or low-privileged requests to view and executor-related endpoints.
• Treat discovered enumeration as reconnaissance and investigate for subsequent authentication attempts, plugin probing, agent access attempts, or suspicious job/build activity from the same sources.
• Review agent naming conventions and avoid embedding sensitive project names, customer names, environment labels, secrets, or network details in node names.
• Validate vendor package mappings before relying on non-Jenkins package names in vulnerability-management tools, as the provided affected-product list contains entries that may not correspond to the Jenkins advisory.