Jenkins is an open-source automation server widely used for CI/CD orchestration, pipeline automation, and infrastructure workflows. It integrates deeply with source control systems, container registries, artifact repositories, and cloud providers. Due to this central role, and much like other DevOps tools, Jenkins frequently stores sensitive assets such as credentials, API tokens, build artifacts, and deployment permissions - making it a high-value target and a potential pivot point into production and cloud environments.
Architecturally, Jenkins combines a centralized controller with distributed agents, a large plugin ecosystem of over 1,900 plugins, and scriptable pipelines capable of executing OS-level commands. These characteristics provide flexibility and power, but also shape the security posture and attack surface of Jenkins environments.
Our analysis shows that Jenkins itself can be found in over a third of all cloud environments, and that core vulnerabilities remain a meaningful risk factor. According to Wiz data, 59% of cloud environments using Jenkins have instances vulnerable to critical-severity core vulnerabilities, while 2% expose vulnerable instances directly to the internet.
These risks are primarily driven by operational realities rather than inherent design flaws. Jenkins instances often experience slow patch cycles, remain deployed for long periods, and run unsupported versions (in fact, over 87% of environments using Jenkins contain end-of-life instances) .
Additionally, Jenkins typically operates with administrative-level local execution privileges, increasing the impact of successful exploitation. Jenkins is also often granted sensitive cloud permissions, with 48% of environments using Jenkins running this software on compute with highly privileged service accounts, and 21% doing so on compute with administrative privileges.
When exploited, these vulnerabilities can enable a full attack chain - from remote code execution (RCE), to credential theft, lateral movement, and ultimately cloud environment compromise.
Jenkins maintains one of the more mature and well-governed plugin ecosystems among open-source platforms. Its model includes signed plugin distribution, structured security advisory publication, maintainer transfer workflows, security reviews for new plugins, and validation of update center metadata.
These controls significantly reduce supply-chain risk compared to many other plugin-based ecosystems and demonstrate strong governance for an open-source project at this scale.
Despite these strengths, real-world usage introduces risk. Approximately 37% of cloud environments use plugins that are “up for adoption,” meaning they have limited maintainer activity and could be considered effectively end-of-life. Additionally, 31% rely on deprecated plugins with no ongoing support, and 21% run plugins with critical or high-severity vulnerabilities with no patch available. Plugins that are up for adoption or deprecated are highly more likely to have 0days vulnerabilities. Some of these risky plugins are also highly prevalent, for example workflow-cps-global-lib, a deprecated plugin, is used by 31% of environments, and extended-choice-parameter is a deprecated plugin with known unresolved vulnerabilities that is used by 14% of environments.
These figures highlight that the primary challenge is not the governance model itself, but adoption and maintenance practices in deployed environments. Even well-managed ecosystems can accumulate risk when outdated or unmaintained components remain in use.
Plugins are particularly attractive to attackers because they often run with controller-level privileges, expose HTTP endpoints, manage sensitive credentials, and execute Groovy or shell commands. As a result, plugin vulnerabilities or misuses can provide direct paths to high-impact compromise.
Additionally, plugins could theoretically be the target of supply chain attacks, but the above-mentioned strengths of Jenkins’ marketplace make this challenging for attackers, and as far as we can tell, so far fortunately there have been no publicly known cases of supply chain attacks against legitimate plugins.
In practice, most compromises do not rely on exploitation of software vulnerabilities, but instead on exploitation of misconfigurations and insecure usage patterns. Given Jenkins’ flexibility and deep integration with infrastructure, even small configuration gaps can significantly expand the attack surface.
Weak access control and excessive exposure are the most pressing issues. This includes anonymous read access, missing RBAC enforcement, and overly permissive service accounts. At the same time, Internet-facing controllers or externally accessible agents - especially without IP restrictions - are frequently targeted by automated scanning and opportunistic exploitation.
Jenkins often stores and processes sensitive data such as API tokens, SSH keys, and cloud credentials. Misconfigurations include storing secrets in plaintext, exposing them through environment variables, or failing to rotate them regularly. In parallel, pipeline configurations can introduce risk when unsandboxed scripts, arbitrary shell execution, or untrusted inputs (e.g., pull requests) are allowed to influence build execution.
Underlying infrastructure decisions can further increase impact. Running controllers with elevated privileges, sharing host namespaces across agents, or mounting the Docker socket into build environments can allow a Jenkins compromise to extend beyond the application itself and into the host or container environment.
Observed attacks against Jenkins environments follow several recurring patterns. These attacks are carried out by a mix of opportunistic operators, financially motivated actors, and more targeted adversaries, and often rely on chaining exposure, misconfiguration, and credential access rather than a single vulnerability.
Actors: Cryptomining operators, opportunistic exploitation groups
In many cases, attacks begin by targeting exposed Jenkins instances or misconfigured endpoints. Research shows that attackers can directly leverage Jenkins functionality - such as script execution capabilities - to achieve remote code execution without requiring complex exploitation chains:
Identify exposed Jenkins instances or accessible endpoints
Execute commands via script consoles or build functionality
Deploy malicious workloads (e.g., cryptominers, persistence mechanisms)
Maintain access through scheduled jobs or system-level persistence
These patterns have been apparent in both malicious activity and security research. More specifically, attackers have operated cryptojacking campaigns where they essentially convert Jenkins servers into compute resources at the victims’ expense. Notably, these attacks often rely on exploiting misconfiguration or exposed functionality rather than newly disclosed vulnerabilities.
Actors: Data thieves (e.g., IntelBroker), Supply-chain attackers, Initial access brokers
Jenkins pipelines introduce a unique attack surface where build execution can be influenced by external input. Security research by vendors like Fox-IT, corroborated by real-world incidents, demonstrates that attackers can abuse CI/CD workflows to execute arbitrary code and extract secrets:
Introduce malicious input into build pipelines (e.g., pull requests, build parameters)
Trigger pipeline execution with attacker-controlled code
Extract secrets from environment variables, credentials stores, or build context
Reuse credentials to access source control, cloud services, or internal systems
Case studies show that CI/CD compromise enables access well beyond Jenkins itself, often serving as a stepping stone into developer environments and cloud infrastructure.
Actors: Opportunistic attackers, botnets, post-exploitation operators
Jenkins plugins and core components can expose additional attack surface, particularly when outdated or misconfigured. Exploitation of these components can provide direct access to the controller, enabling persistent control over the CI/CD environment:
Exploit weaknesses in plugins or core Jenkins functionality
Achieve controller-level access or code execution
Establish persistence through jobs, plugins, or system modifications
Use Jenkins as a platform for further operations
Prior research by NCC Group highlights how vulnerabilities in plugin and core interactions can be leveraged to gain elevated access and maintain long-term control of Jenkins environments.
Jenkins agents represent another critical component of the attack surface. Research by Preatorian has shown that compromised agents can be used to extract credentials and pivot into broader environments:
Compromise Jenkins agent (e.g., via build execution or runtime access)
Extract credentials, tokens, or SSH keys from the agent environment
Move laterally across internal systems
Escalate access toward the Jenkins controller or other infrastructure
In practice, agent compromise can blur the boundary between CI/CD systems and the underlying infrastructure, enabling attackers to expand access beyond Jenkins itself.
Actors: Cloud-focused adversaries (e.g., Genesis Panda)
Jenkins frequently serves as a bridge into cloud environments due to its access to credentials and integration with infrastructure. Real-world case studies show attackers using compromised Jenkins instances to obtain cloud credentials and pivot into the cloud control plane:
Exploit Jenkins to gain access to a cloud-hosted instance
Query instance metadata services (IMDS) to retrieve credentials
Use credentials to access the cloud control plane
Perform lateral movement, persistence, and infrastructure enumeration
Attackers such as Genesis Panda have leveraged a compromised Jenkins server to obtain cloud credentials, pivot into the control plane, and establish persistence through access keys and SSH keys. This highlights how Jenkins can act as an entry point into broader cloud environments rather than an isolated target.
Jenkins often functions as a central point of control within modern environments, with access to source code, build artifacts, container registries, production deployment credentials, and cloud IAM tokens. As a result, a successful compromise can extend beyond the Jenkins instance itself and provide access to a wide range of connected systems.
The Jenkins threat landscape reflects a balance between strong ecosystem governance and operational risk in real-world deployments. The platform itself demonstrates mature security practices - particularly in its plugin governance model - which significantly reduce systemic risk compared to many other open-source ecosystems.
At the same time, the remaining gaps are primarily driven by usage patterns: outdated plugins, delayed patching, and misconfigurations. Rather than being viewed as fundamental limitations of Jenkins, these are expected challenges in managing complex, long-lived CI/CD infrastructure at scale.
Overall, Jenkins is frequently leveraged by threat actors as part of broader attack chains not because of inherent weaknesses, but because of its central role in managing execution, credentials, and connectivity across environments. Continued focus on operational hygiene - particularly around patching, plugin lifecycle management, and configuration hardening - can significantly reduce the remaining risk surface.
Our customers can use Wiz to scan their Jenkins environments for vulnerabilities and misconfigurations, while also monitoring their attack surface for exposed or exploitable Jenkins instances.
Additionally, Wiz Defend and Wiz Sensor monitor Jenkins workloads and their associated service accounts for suspicious and malicious activity, alerting on anomalous Jenkins control plane activity that could indicate lateral movement into the wider cloud environment.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。