Jenkins Arbitrary File Read via Crafted CLI Command (CVE-...

CVE-2018-1999002 is a high-severity arbitrary file read vulnerability in Jenkins, the open-source automation server that sits at the center of countless CI/CD pipelines. Disclosed by the Jenkins security team on July 18, 2018, the flaw lives in Stapler, the web framework Jenkins uses to route incoming requests to Java objects, and it let an attacker send a crafted request that returned the contents of any file readable by the Jenkins master process — no valid credentials required. In practice that meant configuration files, credential stores, private keys, and build secrets sitting on the Jenkins master were all fair game for information disclosure, which is what makes this bug a favorite reference point in discussions of Jenkins hardening even years later.

What CVE-2018-1999002 Actually Does

Jenkins relies on Stapler to translate URL paths into method and object invocations automatically — a design that makes it easy to expose new functionality but also makes the routing layer itself a high-value target. Security researcher Orange Tsai of DEVCORE found that Stapler's object-graph traversal could be walked through unintended paths, including the universally inherited getClass()/classloader chain, to reach resource-loading methods that were never meant to be reachable from the outside. By chaining these routing quirks together, an attacker could coerce the server into reading and returning the contents of arbitrary files on the Jenkins master's file system, entirely through crafted HTTP requests aimed at endpoints Jenkins already exposed. No authentication and no plugin misconfiguration were needed for the core issue to be exploitable.

This is worth calling out clearly because the vulnerability is sometimes mis-cited alongside other Jenkins arbitrary file read issues — most notably the unrelated, much later CVE-2024-23897, which involves the Jenkins CLI's handling of the @-file argument-expansion feature and is a genuinely CLI-driven bug. CVE-2018-1999002 predates that issue by more than five years and has a different root cause entirely: it is a request-routing flaw in Stapler, not a CLI parsing flaw. Jenkins administrators evaluating both CVEs should treat them as separate findings with separate remediation paths, even though both ultimately produce the same class of impact — unauthorized arbitrary file read and downstream information disclosure.

Affected Versions and Components

The vulnerable component is Jenkins core's bundled Stapler library, not a specific plugin, which is part of why the bug affected essentially every default Jenkins installation of the time. Per the Jenkins Security Advisory of 2018-07-18:

• Jenkins weekly releases up to and including 2.132 are affected.
• Jenkins LTS releases up to and including 2.121.1 are affected.
• The fix shipped in Jenkins weekly 2.133 and Jenkins LTS 2.121.2, both released alongside the same advisory.

Because Stapler underlies request handling for the web UI and the REST API that plugins build on top of, the practical exposure was broad: any internet-facing or internally reachable Jenkins master in that version range was a candidate for exploitation, regardless of which plugins were installed. Jenkins is deployed heavily as a CI/CD orchestrator, often with access to source code checkouts, deployment credentials, and secrets management integrations, so an arbitrary file read against the master is rarely a low-impact bug in practice — it's frequently a stepping stone to full pipeline and supply chain compromise.

Severity, CVSS, and EPSS Context

Jenkins' own advisory rated the issue High severity, and the score that has propagated through NVD and downstream vulnerability databases is CVSS 7.5 (High), reflecting a network-exploitable, unauthenticated flaw with no user interaction that impacts confidentiality but not integrity or availability. An older CVSS v2 vector puts the score lower, at 5.0 (Medium), which is a useful reminder that CVSS versions can disagree meaningfully on the same bug — CVSS v3's treatment of unauthenticated, network-reachable issues tends to weigh them more heavily.

More telling than the static CVSS score is the EPSS (Exploit Prediction Scoring System) data for CVE-2018-1999002, which sits above the 99th percentile of all scored CVEs, indicating a very high modeled probability of observed exploitation activity. That's consistent with the vulnerability's history: public exploit code has circulated since shortly after disclosure (including an Exploit-DB entry), Orange Tsai's DEVCORE research popularized the underlying Stapler routing technique in follow-up conference talks and blog posts, and security teams have continued to reference it as a canonical example of dynamic-routing risk in Java web frameworks. As of this writing, CVE-2018-1999002 does not appear in CISA's Known Exploited Vulnerabilities (KEV) catalog, but the EPSS percentile alone is a strong enough signal that any Jenkins master still running an affected version should be treated as a live risk, not a historical footnote.

Timeline

• July 18, 2018 — Jenkins publishes its security advisory disclosing CVE-2018-1999002 (tracked internally as SECURITY-914), alongside several other fixes in the same release cycle. Credit is given to Orange Tsai of DEVCORE.
• July 2018 — Jenkins weekly 2.133 and Jenkins LTS 2.121.2 ship with the fix, hardening Stapler's input validation and request-dispatch logic to close off the unintended routing paths.
• Following months — Public proof-of-concept exploit code appears, and researchers (including Tencent's security team) demonstrate chaining the arbitrary file read with other techniques to escalate impact beyond simple information disclosure.
• 2019 onward — Orange Tsai's "Hacking Jenkins" research series documents the Stapler dynamic-routing internals in depth, cementing CVE-2018-1999002 as a widely studied case study for Java web-framework routing vulnerabilities well beyond Jenkins itself.

Remediation Steps

The fix for CVE-2018-1999002 has been available for years, so remediation for most organizations is really about finding and eliminating lingering exposure:

1. Upgrade Jenkins immediately to LTS 2.121.2 or later (or the current LTS baseline) if you're still running anything in the 2.121.1-and-earlier or 2.132-and-earlier ranges. Given how much has shipped since 2018, target the latest supported LTS rather than the minimum fixed version.
2. Inventory every Jenkins master in your environment. Shadow instances spun up for a single project and forgotten are exactly the kind of asset that stays unpatched for years — arbitrary file read vulnerabilities thrive on exactly this kind of drift.
3. Restrict network exposure. Jenkins masters should not be reachable from the open internet without authentication in front of them (reverse proxy, VPN, or IP allowlisting), regardless of patch level — defense in depth matters for a component this central to your build pipeline.
4. Rotate credentials that may have been exposed if you have any reason to believe an affected instance was internet-facing during the vulnerability window — this includes SSH keys, API tokens, and any secrets stored in Jenkins credential stores or config files on the master.
5. Audit for related, but distinct, Jenkins file-read issues, including the CLI-specific CVE-2024-23897, since organizations that missed one historical Jenkins advisory often missed several. Don't assume patching this one CVE closes the whole class of risk.
6. Enable Jenkins' built-in security features — Overall/Read permission enforcement, agent-to-controller security, and script security for Groovy sandboxing — as compensating controls that reduce the blast radius of the next routing or parsing bug, whatever form it takes.

How Safeguard Helps

Vulnerabilities like CVE-2018-1999002 are exactly the kind of software supply chain risk that gets missed in practice, not because the fix is hard, but because visibility is hard. A Jenkins master that was stood up in 2018 and never touched again doesn't announce itself — it just sits there, reachable, until someone runs the right crafted request against it.

Safeguard continuously discovers and fingerprints the CI/CD infrastructure in your environment — Jenkins masters, controllers, and the plugins running on them — and maps each one against known CVEs like CVE-2018-1999002, flagging exact version exposure instead of relying on self-reported inventories that go stale the moment a team spins up a new instance. Because Safeguard treats your build and deployment tooling as first-class attack surface, not just an afterthought behind your application code, it catches the arbitrary file read and information disclosure risks that live in the plumbing of your pipeline, not just in the applications that pipeline ships.

Beyond detection, Safeguard prioritizes findings using real exploitation context — CVSS severity alongside EPSS likelihood and known exploited status — so security teams aren't stuck triaging a flat list of CVEs by age or arbitrary risk labels. For a bug like CVE-2018-1999002, with a high CVSS score and an EPSS percentile in the high 90s, that context is the difference between a ticket that sits in a backlog and one that gets fixed before it's the entry point for a supply chain compromise. Safeguard also tracks remediation status over time, so once your Jenkins fleet is upgraded past the vulnerable Stapler versions, you have continuous evidence — not a one-time attestation — that the exposure is closed.