editorially independent. We may make money when you click on links
to our partners.
Learn More
A newly disclosed high-severity vulnerability in Jenkins allows unauthenticated attackers to remotely freeze servers and disrupt continuous integration pipelines with a single crafted request.
The flaw potentially affects millions of global installations.
This attack results in “… request-handling threads waiting indefinitely,” said Jenkins in its security advisory.
Inside the Jenkins Thread Exhaustion Flaw
The vulnerability (CVE-2025-67635), originates in how Jenkins manages connections for its HTTP-based command-line interface (CLI).
Under normal conditions, Jenkins opens a thread to handle each CLI request and is expected to properly terminate that thread once the request completes or fails.
However, researchers found that when a specially crafted request corrupts the HTTP CLI stream, Jenkins does not correctly clean up the connection. Instead of closing the session and releasing resources, the affected thread remains open and blocked, waiting indefinitely.
This behavior creates a resource exhaustion condition. Each malicious request ties up another request-handling thread, gradually consuming the pool of available threads Jenkins relies on to process legitimate jobs, API calls, and user interactions.
By repeatedly sending malformed CLI requests, an attacker can steadily drain these resources until Jenkins is no longer able to respond to new requests, effectively causing a denial-of-service (DoS) condition.
At that point, pipelines may stall, builds fail to trigger, and administrative access to the server can be disrupted.
What makes this flaw particularly concerning is its low barrier to exploitation.
The attack does not require authentication, user interaction, or advanced exploitation techniques.
Any Jenkins instance that exposes the HTTP CLI over the network is potentially vulnerable, with internet-facing deployments at the highest risk.
While there is currently no public evidence of active exploitation, the simplicity of the attack path and the widespread use of Jenkins make unpatched systems attractive targets.
In environments where Jenkins underpins CI/CD pipelines, even a temporary outage can have cascading effects on development, testing, and deployment workflows.
Hardening Jenkins Management Interfaces
This Jenkins vulnerability illustrates how exposed management interfaces can introduce availability risks if they are not properly secured and monitored. Security teams should take the following steps:
- Upgrade all Jenkins controllers and agents to version 2.541 or LTS 2.528.3 to fully remediate the HTTP CLI thread exhaustion vulnerability.
- Reduce exposure by disabling the HTTP-based CLI where it is not required and restricting access to Jenkins through VPNs, reverse proxies, or zero-trust gateways.
- Apply network controls such as IP allowlists, rate limiting, or WAF rules to block malformed or excessive HTTP requests targeting Jenkins endpoints.
- Monitor system health for indicators of abuse, including spikes in HTTP CLI traffic, long-running threads, abnormal thread pool usage, or stalled connections.
- Enable detailed logging and alerting for Jenkins thread metrics, CLI activity, and connection anomalies to support early detection and response.
- Harden Jenkins deployments by limiting controller resources, reviewing exposed plugins and features, and separating controllers from build agents to reduce blast radius.
Together, these steps help organizations protect critical CI/CD infrastructure without disrupting development workflows.
Why CI/CD Resilience Matters
This issue underscores how CI/CD platforms can become sensitive to availability failures when core components do not enforce strong resource management.
As automation pipelines grow more interconnected and exposed to external systems, seemingly small flaws in connection handling can translate into disproportionate operational impact.
At the same time, CI/CD infrastructure continues to attract attacker interest because of its central role in software delivery, reinforcing the need for timely patching and resilient deployment practices.
Collectively, this highlights how availability risks in CI/CD platforms connect to the larger challenge of maintaining a secure and resilient software supply chain.
