Jenkins' plain CLI endpoint (/cli?remoting=false) pairs two POST requests (download/upload) via a shared Session UUID and is reachable without Overall/Read.
Two bugs stack: An unsynchronized HashMap in CLIAction drops one half of the session (race condition), and the CLI protocol wait loops (ServerSideImpl.run, FullDuplexHttpService.upload) have no timeout.
Attackers can finish their HTTP calls in milliseconds yet strand Jetty threads for 15s (race window) or indefinitely (abandoned protocol), causing controller-wide asymmetric DoS.
Affects core ≤ 2.540 and LTS ≤ 2.528.2 (CWE-362/CWE-404, CVSS: 7.5). Fixed in 2.541 and 2.528.3 by using ConcurrentHashMap, adding handshake timeouts, and closing streams on error.
Mitigate now: Upgrade, or block the plain CLI endpoint from untrusted networks and capture thread dumps to confirm no threads sit in CLIAction$ServerSideImpl.run or FullDuplexHttpService.upload/download.
What the endpoint does
The non-Remoting CLI builds a full-duplex channel from two HTTP POSTs:
Download side:Side: download, opens /cli?remoting=false, server writes a byte and waits for the upload half
Upload side:Side: upload, same Session UUID, provides the input stream
hudson.cli.CLIAction wires this to jenkins.util.FullDuplexHttpService, storing active sessions in a cross-request registry.
Root cause #1: Unsynced session registry (race condition)
CLIAction keeps the session map in a plain HashMap shared by all request threads:
// core/src/main/java/hudson/cli/CLIAction.java:83privatefinaltransient Map<UUID, FullDuplexHttpService> duplexServices = new HashMap<>();
// core/src/main/java/hudson/cli/CLIAction.java:83privatefinaltransient Map<UUID, FullDuplexHttpService> duplexServices = new HashMap<>();
// core/src/main/java/hudson/cli/CLIAction.java:83privatefinaltransient Map<UUID, FullDuplexHttpService> duplexServices = new HashMap<>();
// core/src/main/java/hudson/cli/CLIAction.java:83privatefinaltransient Map<UUID, FullDuplexHttpService> duplexServices = new HashMap<>();
FullDuplexHttpService.Response.generateResponse calls services.put(uuid, service) for the download side, and services.get(uuid) for the upload side. Because HashMap is not thread-safe, concurrent puts/gets under load can
return null for a valid download side;
drop entries during a resize;
leave download threads inside FullDuplexHttpService.download waiting up to 15s for an upload that already arrived.
The result: Every racy pair ties up a servlet thread for the full timeout while the attacker's sockets close immediately, causing an asymmetric DoS and violating the security requirement “Make critical logic flows thread safe”.
Root cause #2: Missing protocol timeouts (deterministic hang)
Even when the two halves pair correctly, the protocol handshake can deadlock because neither side times out:
// core/src/main/java/hudson/cli/CLIAction.java:300synchronized(this){while(!ready){// waits forever if client never sends "start"wait();}}// core/src/main/java/jenkins/util/FullDuplexHttpService.java:145while(!completed){// no deadline if download side dies earlywait();}
// core/src/main/java/hudson/cli/CLIAction.java:300synchronized(this){while(!ready){// waits forever if client never sends "start"wait();}}// core/src/main/java/jenkins/util/FullDuplexHttpService.java:145while(!completed){// no deadline if download side dies earlywait();}
// core/src/main/java/hudson/cli/CLIAction.java:300synchronized(this){while(!ready){// waits forever if client never sends "start"wait();}}// core/src/main/java/jenkins/util/FullDuplexHttpService.java:145while(!completed){// no deadline if download side dies earlywait();}
// core/src/main/java/hudson/cli/CLIAction.java:300synchronized(this){while(!ready){// waits forever if client never sends "start"wait();}}// core/src/main/java/jenkins/util/FullDuplexHttpService.java:145while(!completed){// no deadline if download side dies earlywait();}
If the client drops the connection before sending CLI frames, the download thread blocks in ServerSideImpl.run() and the upload thread blocks in upload()with no timeout, consuming two Jetty threads per attempt until the controller is exhausted.
Exploitation notes
Both vectors require only network reachability to /cli:
Scenario A (race condition): Fire overlapping download/upload pairs with slight jitter so the upload half occasionally sees null. Threads pile up in FullDuplexHttpService.download for ~15s each.
Scenario B (abandonment): open both halves, let them pair, then close without sending CLI frames. Threads stay in CLIAction$ServerSideImpl.run and FullDuplexHttpService.upload indefinitely, no timing window needed.
Below are the exact PoCs shared with the Jenkins security team:
PoC: racecond_a.py (HashMap race, two downloads per UUID)
Thread dump (Scenario B, Jenkins 2.516.2 test controller): Stuck in the exact call sites with no timeout:
at hudson.cli.CLIAction$ServerSideImpl.run(CLIAction.java:319)
- locked <0x00000000f0d9ba90> (a hudson.cli.CLIAction$ServerSideImpl)at jenkins.util.FullDuplexHttpService.download(FullDuplexHttpService.java:119)at jenkins.util.FullDuplexHttpService.upload(FullDuplexHttpService.java:146)
- locked <0x00000000f0d9aaa0> (a hudson.cli.CLIAction$PlainCliEndpointResponse$1)at jenkins.util.FullDuplexHttpService$Response.generateResponse(FullDuplexHttpService.java:191)
at hudson.cli.CLIAction$ServerSideImpl.run(CLIAction.java:319)
- locked <0x00000000f0d9ba90> (a hudson.cli.CLIAction$ServerSideImpl)at jenkins.util.FullDuplexHttpService.download(FullDuplexHttpService.java:119)at jenkins.util.FullDuplexHttpService.upload(FullDuplexHttpService.java:146)
- locked <0x00000000f0d9aaa0> (a hudson.cli.CLIAction$PlainCliEndpointResponse$1)at jenkins.util.FullDuplexHttpService$Response.generateResponse(FullDuplexHttpService.java:191)
at hudson.cli.CLIAction$ServerSideImpl.run(CLIAction.java:319)
- locked <0x00000000f0d9ba90> (a hudson.cli.CLIAction$ServerSideImpl)at jenkins.util.FullDuplexHttpService.download(FullDuplexHttpService.java:119)at jenkins.util.FullDuplexHttpService.upload(FullDuplexHttpService.java:146)
- locked <0x00000000f0d9aaa0> (a hudson.cli.CLIAction$PlainCliEndpointResponse$1)at jenkins.util.FullDuplexHttpService$Response.generateResponse(FullDuplexHttpService.java:191)
at hudson.cli.CLIAction$ServerSideImpl.run(CLIAction.java:319)
- locked <0x00000000f0d9ba90> (a hudson.cli.CLIAction$ServerSideImpl)at jenkins.util.FullDuplexHttpService.download(FullDuplexHttpService.java:119)at jenkins.util.FullDuplexHttpService.upload(FullDuplexHttpService.java:146)
- locked <0x00000000f0d9aaa0> (a hudson.cli.CLIAction$PlainCliEndpointResponse$1)at jenkins.util.FullDuplexHttpService$Response.generateResponse(FullDuplexHttpService.java:191)
Video evidence: End-to-end crash reproduction against a fresh controller:
On a vulnerable build, you will see dozens of request threads waiting in those call sites, and regular CLI calls start timing out.
Impact
Unauthenticated DoS: no Overall/Read required to hit /cli?remoting=false
Low attacker cost: Sockets close immediately, the server holds the work (15s per race attempt, infinite for abandonment)
Controller-wide degradation: Servlet threads and I/O streams back up, other endpoints time out
CLIAction now stores sessions in a ConcurrentHashMap, removing the racy HashMap drops that powered the asymmetric DoS.
ServerSideImpl.run and FullDuplexHttpService.upload adopted CONNECTION_TIMEOUT-bounded waits with 1s wake-ups and DEBUG logs, so abandoned handshakes unwind instead of parking threads.
PlainCLIProtocol always calls side.handleClose() in a finally block, ensuring both halves tear down even on read errors or runtime exceptions.
Regression coverage landed in Security3630Test (JUnit 5): It shrinks the CLI timeout for tests, exercises the previous race with concurrent CLI invocations, and asserts threads are released after truncated streams.
Net effect: The CLI download/upload pairing now fails fast and frees Jetty threads instead of blocking indefinitely on missing counterparts.
SECURITY-3630 was assigned CVE-2025-67635 (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). See the CNA record on cve.org and the NIST entry on NVD for canonical metadata.
Fluid Attacks' solutions enable organizations to identify, prioritize, and remediate vulnerabilities in their software throughout the SDLC. Supported by AI, automated tools, and pentesters, Fluid Attacks accelerates companies' risk exposure mitigation and strengthens their cybersecurity posture.
Fluid Attacks' solutions enable organizations to identify, prioritize, and remediate vulnerabilities in their software throughout the SDLC. Supported by AI, automated tools, and pentesters, Fluid Attacks accelerates companies' risk exposure mitigation and strengthens their cybersecurity posture.
Fluid Attacks' solutions enable organizations to identify, prioritize, and remediate vulnerabilities in their software throughout the SDLC. Supported by AI, automated tools, and pentesters, Fluid Attacks accelerates companies' risk exposure mitigation and strengthens their cybersecurity posture.