The Jenkins Threat Landscape

What usage patterns, plugin adoption, and configuration choices reveal about the Jenkins attack surface.

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 likeother 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 tocritical-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 reducesupply-chain riskcompared 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 exampleworkflow-cps-global-lib, a deprecated plugin, is used by 31% of environments, andextended-choice-parameteris 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 executeGroovyor 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 theattack surface.

Weak access control and excessive exposure are the most pressing issues. This includes anonymous read access, missingRBACenforcement, 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 includestoring secretsin 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 environmentsfollow 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:Cryptominingoperators, 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 bothmalicious activityandsecurity 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,demonstratesthat 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 Grouphighlightshow vulnerabilities in plugin and core interactions can beleveragedto gain elevated access and maintain long-term control of Jenkins environments.

Jenkinsagentsrepresent another critical component of the attack surface. Research by Preatorian hasshownthat 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.

Detect and mitigate CVE-2026-0300, a critical vulnerability in Palo Alto Networks PAN-OS User-ID Authentication Portal that allows unauthenticated attackers to achieve remote code execution (RCE) with root privileges.

Streamline pen-testing by unifying findings from bug bounties, manual audits, and Wiz Red Agent into a single, context-rich view.

Get actionable best practices to shrink your attack surface, protect execution environments, control package ingestion, and catch compromises early.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings