CVE-2025-67635

What it actually does

Jenkins 2.540 and earlier and Jenkins LTS 2.528.2 and earlier mishandle corrupted HTTP-based CLI connection streams. Instead of reliably closing the broken connection and releasing associated resources, Jenkins can leave CLI-related HTTP connections/resource handling in a bad state. An unauthenticated remote attacker can repeatedly send malformed or prematurely corrupted CLI traffic to the Jenkins HTTP endpoint, consuming connection, thread, file descriptor, or memory resources until the controller becomes slow, unresponsive, or unavailable. The impact is availability only; the vulnerability is not described as enabling code execution, data theft, or privilege escalation.

Why it matters to the business

Successful exploitation can interrupt CI/CD operations by making the Jenkins controller unavailable or unreliable, delaying builds, deployments, release pipelines, automated testing, and operational tasks that depend on Jenkins. Because exploitation is unauthenticated and network-reachable wherever Jenkins HTTP endpoints are exposed, internet-facing or broadly reachable Jenkins controllers have the highest operational risk. The issue is not currently listed in CISA KEV, is not flagged as ransomware-associated, and has low EPSS in the provided data, but the CVSS score is high because service disruption can be triggered remotely without credentials.

How an attack unfolds

An attacker first identifies a reachable Jenkins controller that exposes the HTTP-based CLI endpoint. They then initiate CLI-over-HTTP requests without authenticating and intentionally corrupt, truncate, or otherwise break the request/response stream. On vulnerable versions, Jenkins does not properly close the corrupted CLI connection, allowing server-side resources to remain tied up longer than intended. By repeating this behavior across many requests or connections, the attacker can exhaust available HTTP worker threads, sockets, file descriptors, memory, or related controller resources. As resource pressure increases, legitimate users and automation begin seeing slow responses, failed CLI/API requests, build queue delays, or complete service unavailability. There is no indication from the provided data that exploitation grants the attacker access to Jenkins jobs, credentials, build artifacts, or execution capabilities.

How to fix it

Upgrade Jenkins to a version newer than Jenkins 2.540 or Jenkins LTS 2.528.2 that contains the fix. For source-based deployments, ensure the Jenkins code includes fixed commit 40e29179c3edf88b685d7043ab7c37cc8591138f. Prefer vendor-provided Jenkins weekly or LTS releases rather than ad hoc source builds, and validate the exact fixed release from the Jenkins security advisory or package channel used by the deployment. If immediate upgrade is not possible, reduce exposure by restricting access to Jenkins HTTP endpoints to trusted networks, placing Jenkins behind a reverse proxy or WAF with connection/request rate limits, blocking unauthenticated access to CLI-related paths where feasible, disabling or limiting Jenkins CLI usage if not required, and enforcing low idle/read timeouts on front-end proxies. Monitor controller resource utilization and restart affected controllers only as a temporary recovery measure; restart does not remediate the vulnerability.

How to confirm the fix worked

Confirm the installed Jenkins version is later than the affected ranges: greater than Jenkins 2.540 for weekly releases or greater than Jenkins LTS 2.528.2 for LTS releases, or verify that the deployed source/build contains commit 40e29179c3edf88b685d7043ab7c37cc8591138f. Check Jenkins system information, package manager metadata, container image tags, and plugin/controller inventory tools for version confirmation. Validate externally that Jenkins HTTP access is not exposed beyond intended networks and that reverse proxy rate limits and timeouts are active. Review access logs after remediation to ensure malformed or aborted CLI requests no longer cause persistent thread, connection, file descriptor, or memory growth. If safe testing is approved, perform controlled negative testing against the HTTP CLI endpoint from an internal test network and verify that corrupted connections are closed promptly and controller health remains stable.

Typical attack path

1. Discover a Jenkins controller reachable over HTTP or HTTPS.
2. Probe Jenkins headers, landing pages, or known paths to confirm the service and version exposure.
3. Send unauthenticated HTTP requests to the Jenkins CLI endpoint.
4. Corrupt, interrupt, or prematurely terminate the CLI connection stream.
5. Repeat the malformed CLI traffic at sufficient volume to accumulate unclosed or slowly released server-side resources.
6. Cause Jenkins HTTP handling, CLI handling, or the controller JVM to become degraded or unavailable.
7. Maintain pressure by continuing malformed connection attempts until the service is restarted, patched, rate-limited, or isolated.

How to detect it

This vulnerability is availability-focused, so evidence of exploitation is most likely to appear as service degradation correlated with unusual HTTP CLI traffic rather than as post-compromise artifacts. Review reverse proxy, load balancer, WAF, web access, and Jenkins controller logs for bursts of unauthenticated requests to CLI-related endpoints, especially from a small set of source IPs or with many incomplete responses, client disconnects, read timeouts, connection resets, or malformed request errors. Correlate those events with Jenkins controller symptoms such as elevated HTTP request latency, exhausted Jetty/Winstone threads, increased open sockets, high file descriptor counts, JVM memory pressure, garbage collection spikes, build queue growth, failed webhook/API calls, and service restarts. Examine Jenkins logs for CLI handling errors, IOException/Broken pipe/Connection reset messages, and repeated exceptions involving CLI request processing. Because no code execution is indicated, do not expect malware files, new Jenkins users, malicious jobs, or credential access solely from this flaw; however, investigate any such findings separately as possible concurrent compromise.

• /cli
• POST /cli
• GET /cli
• /cli?remoting=false
• hudson.cli.CLIAction
• java.io.IOException: Broken pipe
• java.io.IOException: Connection reset
• java.net.SocketException: Connection reset
• java.net.SocketTimeoutException
• org.eclipse.jetty.io.EofException
• ClientAbortException
• Broken pipe
• Connection reset by peer
• corrupted stream
• malformed stream
• unexpected end of stream
• HTTP-based CLI

What your security team should do

• Prioritize patching internet-facing or widely reachable Jenkins controllers first, followed by internal controllers used for production deployment or release automation.
• Upgrade all affected Jenkins weekly and LTS deployments to fixed releases, or ensure source-based builds include commit 40e29179c3edf88b685d7043ab7c37cc8591138f.
• Restrict Jenkins HTTP access to trusted networks, VPNs, or authenticated reverse proxies; avoid exposing Jenkins directly to the internet.
• Apply reverse proxy controls for request rate limiting, connection limiting, header/body timeout enforcement, and idle connection cleanup.
• Create SIEM detections for spikes in unauthenticated requests to Jenkins CLI endpoints, especially requests ending in connection reset, broken pipe, timeout, or malformed stream errors.
• Monitor Jenkins controller health indicators including HTTP thread pools, JVM memory, garbage collection, open file descriptors, socket counts, request latency, and build queue growth.
• Review recent Jenkins and proxy logs for evidence of repeated malformed CLI traffic before patching, particularly from external or unfamiliar source IPs.
• Document whether Jenkins CLI is operationally required; if not required, disable or block CLI-related access paths at the proxy layer where compatible with the deployment.