Jenkins Stapler Unauthenticated RCE Mass-Exploited for Cr...

In December 2018, the Jenkins security team disclosed CVE-2018-1000861, an unauthenticated remote code execution vulnerability in the Stapler web framework that Jenkins uses to route HTTP requests to Java objects. The flaw let an attacker with no credentials at all reach internal, non-public APIs through crafted URLs — and within weeks, that access was being chained into full server takeover. By early 2019, internet-exposed Jenkins instances were being scanned and hit at scale, with compromised build servers repurposed to mine Monero. For a platform that sits at the center of build, test, and deploy pipelines across the software industry, an unauthenticated path to code execution was as close to a worst case as CI/CD security gets.

What CVE-2018-1000861 Actually Is

Jenkins doesn't route web requests the way a typical application does. It relies on Stapler, a lightweight MVC framework that automatically exposes Java object methods and fields as URL-addressable endpoints based on naming conventions rather than an explicit route table. That convenience is also the root of the problem: Stapler's URL-to-method dispatch could be manipulated to reach objects and methods that were never meant to be reachable from an unauthenticated HTTP request.

Researchers Orange Tsai and Meh Chang of DEVCORE reported the issue, and Jenkins credited it in Security Advisory 2018-12-05 alongside a cluster of related findings. On its own, the Stapler flaw gave an attacker the ability to invoke arbitrary getter methods and access internal objects — a serious information-disclosure and logic-abuse primitive. Combined with separate sandbox-bypass bugs in the Pipeline and Script Security plugins (tracked as CVE-2019-1003000, CVE-2019-1003001, and CVE-2019-1003002, disclosed a few weeks later), the Stapler routing bug became the first link in a chain that let attackers execute arbitrary Groovy code on the Jenkins master — fully unauthenticated. That combination is what turned a single routing bug into one of the more consequential CI/CD RCE stories of the past decade.

Affected Versions and Components

CVE-2018-1000861 lives in Jenkins core, specifically in how it embeds and configures the Stapler framework rather than in a single optional plugin — which is why it affected essentially every default Jenkins installation of the time, not a niche subset of deployments.

• Jenkins weekly releases up to and including 2.153
• Jenkins LTS releases up to and including 2.150.1
• Fixed in: Jenkins weekly 2.154 and Jenkins LTS 2.150.2

Because the vulnerable code path sits in Stapler's core request dispatch, no specific plugin configuration was required to be exposed — any Jenkins controller reachable over HTTP, including ones behind minimal or default authentication settings, was a candidate target. Instances that additionally had the Pipeline: Groovy, Pipeline: Declarative, or Script Security plugins installed (a very common combination, since these plugins underpin standard Jenkinsfile-based pipelines) were exposed to the full unauthenticated RCE chain once the follow-on advisories landed.

CVSS, EPSS, and KEV Context

NVD scores CVE-2018-1000861 as Critical, with a CVSS v3 base score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — network-exploitable, no privileges or user interaction required, and full impact to confidentiality, integrity, and availability. That scoring reflects the Stapler bug in isolation; in practice, the real-world severity was compounded by how easily it combined with the Script Security sandbox-bypass issues to produce arbitrary command execution rather than "just" information disclosure.

The vulnerability's inclusion in CISA's Known Exploited Vulnerabilities (KEV) catalog reflects what the threat intelligence community observed directly: this was not a theoretical bug sitting in an advisory — it was weaponized and used against real, internet-facing infrastructure. Federal agencies subject to Binding Operational Directive 22-01 were required to remediate KEV-listed flaws like this one on an accelerated timeline, underscoring how seriously the exploitation activity was taken well after initial disclosure. EPSS scoring for a vulnerability this old and this consistently exploited tends to sit in a high percentile relative to the broader CVE population, reflecting sustained scanning and exploitation interest rather than a one-time event.

Timeline

• December 5, 2018 — Jenkins publishes Security Advisory 2018-12-05, disclosing CVE-2018-1000861 (Stapler unauthenticated access to internal APIs) along with several related core and plugin issues, credited to Orange Tsai and Meh Chang (DEVCORE). Fixes ship in Jenkins 2.154 and LTS 2.150.2.
• January 2019 — Jenkins discloses a follow-on set of Script Security and Pipeline plugin sandbox-bypass vulnerabilities (CVE-2019-1003000, CVE-2019-1003001, CVE-2019-1003002). Security researchers quickly demonstrate that chaining these with the earlier Stapler flaw produces unauthenticated remote code execution on unpatched, internet-exposed servers.
• Early-to-mid 2019 — Mass scanning and exploitation is observed in the wild. Attackers use the chain to drop cryptomining payloads — most notably a strain dubbed "JenkinsMiner" — onto compromised Jenkins masters and agents, hijacking build server CPU cycles to mine Monero (XMR). Given how many Jenkins controllers run on generously provisioned build infrastructure, they made attractive cryptomining hosts.
• 2019 onward — The campaign becomes a widely cited case study for CI/CD RCE and for the risks of exposing build automation tooling directly to the internet. Reports of continued scanning and opportunistic exploitation of unpatched instances persist for years afterward, which is typical for internet-facing infrastructure vulnerabilities that are simple to detect and automate against.

Remediation Steps

1. Patch immediately. Update Jenkins to at least 2.154 (weekly) or 2.150.2 (LTS) or later — realistically, run a current LTS release, since Jenkins has shipped many subsequent security fixes since this advisory.
2. Patch the plugin chain, not just core. If you're on a Jenkinsfile-based pipeline workflow, also ensure Script Security, Pipeline: Groovy, and Pipeline: Declarative plugins are updated past the versions fixed by CVE-2019-1003000/1003001/1003002 — the core fix alone doesn't close the full RCE chain.
3. Get Jenkins off the open internet. Jenkins controllers should never be directly reachable from the public internet. Put them behind a VPN, reverse proxy with authentication, or zero-trust access layer, and restrict inbound access by IP/network wherever possible.
4. Enforce authentication and authorization properly. Confirm "Anonymous Read Access" and similarly permissive authorization matrix settings are disabled; require authenticated access for all Jenkins functionality, not just administrative actions.
5. Audit for compromise indicators. Look for unexpected CPU spikes, unfamiliar cron jobs or system processes, unrecognized outbound connections to mining pools, unexplained new Jenkins jobs or credentials, and modified config.xml files — all common artifacts of the JenkinsMiner-style campaigns.
6. Establish a patch cadence. Jenkins publishes security advisories on a regular cycle; track them and apply LTS security updates promptly rather than running stale installations indefinitely.
7. Inventory your CI/CD attack surface. Treat build servers, plugins, and their dependency chains as first-class assets in vulnerability management — the same rigor applied to production workloads should apply to the systems that build and ship them.

How Safeguard Helps

CVE-2018-1000861 is a textbook illustration of why software supply chain security has to include the pipeline itself, not just the artifacts it produces. Safeguard continuously inventories CI/CD infrastructure — Jenkins controllers, agents, and the plugin versions running on each — so unpatched, internet-exposed instances don't sit undetected for months while attackers scan for them.

Safeguard maps known CVEs like this one directly to the Jenkins core and plugin versions deployed in your environment, correlates exposure with exploitation signals (including KEV and EPSS context), and prioritizes remediation based on real reachability rather than raw CVSS score alone. Because Jenkins-class vulnerabilities are frequently valuable precisely because they enable a CI/CD RCE — with downstream access to build secrets, source code, and deployment credentials — Safeguard treats build infrastructure as a first-class part of the software supply chain, alerting your team the moment a Jenkins instance, or any of its plugins, drifts into a known-vulnerable state. The goal is straightforward: catch the next unauthenticated RCE in your pipeline before it becomes someone else's cryptomining infrastructure.