Jenkins CLI Deserialization RCE via Commons-Collections G...

Jenkins, the most widely deployed open-source automation server in software supply chains, disclosed a critical remote code execution vulnerability in November 2015 that let unauthenticated attackers take over build servers with a single crafted network request. Tracked as CVE-2015-8103, the flaw lived in the Jenkins CLI (command-line interface) subsystem, which deserialized Java objects sent over the wire without validating their contents. By chaining together classes from the popular Apache Commons-Collections library, an attacker could turn ordinary deserialization into arbitrary code execution — no login required. Because Jenkins masters typically hold credentials, source code access, and deployment keys for an organization's entire CI/CD pipeline, CVE-2015-8103 wasn't just a server bug; it was a direct path to full software supply chain compromise.

This post breaks down what CVE-2015-8103 actually is, which Jenkins versions and components are affected, what we know about its severity and exploitation likelihood, how the disclosure timeline unfolded, and what remediation looks like today — nearly a decade later — for teams that may still be carrying legacy Jenkins infrastructure.

What Is CVE-2015-8103?

CVE-2015-8103 is a Java deserialization vulnerability in the Jenkins CLI remoting protocol. Jenkins' CLI client communicated with the Jenkins master over a channel that accepted serialized Java objects and deserialized them using a plain ObjectInputStream, with no restriction on which classes could be instantiated during that process. This is the classic "insecure deserialization" anti-pattern: if an attacker can influence the byte stream being deserialized, and any class reachable on the application's classpath has a readObject() or similar method with dangerous side effects, that logic executes automatically the moment the object is reconstructed — before any application-level authentication or authorization check ever runs.

Jenkins shipped with Apache Commons-Collections on its classpath, a library that (in the vulnerable versions widely deployed at the time) contains a chain of classes — most notoriously InvokerTransformer — that can be composed into a "gadget chain." A gadget chain doesn't exploit a bug in Commons-Collections itself; it abuses functionality the library was designed to provide (dynamically invoking methods via reflection) to turn a deserialized object graph into a generic remote code execution primitive. This technique was popularized by security researchers Chris Frohoff and Gabriel Lawrence with their ysoserial tool, and it turned what had been a theoretical class of bugs into a practical, repeatable exploit against any Java application that deserialized untrusted data and had commons-collections on its classpath — Jenkins among them.

The result: an attacker with network access to a Jenkins master's CLI port could send a malicious serialized payload and execute arbitrary commands on the underlying host with the privileges of the Jenkins process — frequently a highly privileged service account with access to source repositories, artifact registries, and deployment credentials.

Affected Versions and Components

The vulnerability affected the Jenkins CLI subsystem across both the weekly and Long-Term Support (LTS) release lines prior to the November 2015 security fix. The core issue was not a Jenkins-specific coding mistake but rather Jenkins' use of unauthenticated, unrestricted Java object deserialization for its CLI remoting channel combined with a vulnerable version of commons-collections present on the classpath. This made the Jenkins CLI protocol itself the attack surface: any Jenkins installation exposing its CLI/TCP or HTTP CLI endpoint to a network an attacker could reach was potentially exploitable, regardless of whether the instance required login for the web UI, since the CLI deserialization occurred prior to authentication.

Jenkins addressed the issue in its official security advisory published on November 11, 2015, shipping fixes in the corresponding weekly and LTS releases that followed. The fix introduced an object-input-stream filtering mechanism — a blacklist of known-dangerous classes (including the commons-collections gadget classes) that the CLI deserialization path would refuse to instantiate, closing off the specific exploitation technique that had just been published. Organizations running Jenkins masters that predate that advisory, or that never applied it, remain exposed to this exact exploit chain today.

CVSS, EPSS, and KEV Context

NVD's scoring for CVE-2015-8103 reflects the severity of unauthenticated remote code execution: the vulnerability is rated in the high range under CVSSv2, consistent with a network-exploitable, low-complexity attack requiring no authentication. As with many deserialization CVEs from this era (including the parallel WebLogic, WebSphere, and JBoss issues disclosed around the same time), the base metrics were derived from CVSSv2's more constrained impact model, which understated how catastrophic real-world exploitation of unauthenticated RCE against a CI/CD control-plane server actually is.

From an exploitation-likelihood standpoint, CVE-2015-8103 sits in a category security teams should treat with urgency independent of any specific EPSS percentile: the exploitation technique is public, weaponized, and trivially repeatable via ysoserial, and Jenkins CLI endpoints are a common target in internet-wide scanning. We are not aware of CVE-2015-8103 currently carrying its own dedicated listing on CISA's Known Exploited Vulnerabilities (KEV) catalog, but the broader class of commons-collections deserialization gadgets it belongs to has a long, well-documented history of active exploitation across multiple platforms since 2015. Any exposed, unpatched Jenkins CLI endpoint should be assumed to be a live target, not a theoretical risk.

Timeline

• January 2015 — Researchers Chris Frohoff and Gabriel Lawrence present "Marshalling Pickles" at AppSecCali, introducing generic Java deserialization gadget chains and releasing the ysoserial proof-of-concept tool, including gadgets built on Apache Commons-Collections.
• November 6, 2015 — Security researcher Stephen Breen (of FoxGlove Security) publishes a widely circulated blog post demonstrating concrete, weaponized exploitation of the commons-collections gadget chain against several major Java platforms — including WebLogic, WebSphere, JBoss, OpenNMS, and Jenkins — turning the January research into immediate, real-world risk.
• November 11, 2015 — Jenkins publishes a security advisory addressing the CLI deserialization issue, assigning what became known as CVE-2015-8103, and shipping patched weekly and LTS releases that introduce deserialization class filtering on the CLI channel.
• Following months — Jenkins continues hardening the remoting protocol, and the broader ecosystem (Apache Commons-Collections maintainers, other affected vendors) ships follow-on patches addressing the underlying gadget classes and related bypasses discovered by researchers probing the initial blacklist-based fixes.
• Later Jenkins releases — Jenkins subsequently deprecates and eventually removes the legacy Java-serialization-based remoting CLI protocol entirely in favor of safer, non-serialization transport, reflecting the broader industry lesson that blacklisting dangerous classes is a stopgap, not a durable fix, for deserialization of untrusted data.

Remediation Steps

1. Upgrade Jenkins. If you are running a Jenkins master predating the November 2015 security advisory, upgrade immediately to a current LTS release. Modern Jenkins versions have removed the legacy serialization-based CLI protocol entirely, eliminating this exploitation vector at its root rather than merely filtering it.
2. Audit exposure of the CLI endpoint. Do not expose Jenkins CLI ports directly to untrusted networks. Restrict access via firewall rules, VPN, or a reverse proxy that enforces authentication before traffic reaches Jenkins.
3. Disable the legacy CLI protocol if upgrading isn't immediately possible. Jenkins added configuration options to disable the deprecated remoting-based CLI channel; disabling it removes the deserialization attack surface even before a full upgrade.
4. Track and patch Commons-Collections everywhere it appears. CVE-2015-8103 is a reminder that the vulnerable component (commons-collections) can be a transitive dependency pulled in by many applications beyond Jenkins itself. Inventory every service with commons-collections on its classpath and confirm it's running a version where the dangerous transformer functionality is disabled by default.
5. Never deserialize untrusted input with a bare ObjectInputStream. Wherever custom Java code performs deserialization, use look-ahead validation, allowlisting of expected classes, or move away from native Java serialization entirely in favor of safer formats like JSON or Protocol Buffers.
6. Harden Jenkins generally. Enable a security realm and matrix-based authorization, enforce CSRF protection, keep plugins updated (many Jenkins plugin CVEs follow similar patterns), and monitor for unexpected process spawning from the Jenkins service account.
7. Monitor and alert. Treat any unauthenticated connection attempt to a Jenkins CLI port, or any anomalous child process spawned by the Jenkins service user, as a high-priority security event.

How Safeguard Helps

CVE-2015-8103 is a textbook case for why software supply chain security requires visibility that goes deeper than "is this app patched" — it requires knowing exactly which components, transitively, sit on every application's classpath, and how they're wired together. Safeguard continuously inventories the software composition of your build and deployment infrastructure, including CI/CD systems like Jenkins, so that a vulnerable commons-collections version or an outdated Jenkins core doesn't sit unnoticed for years the way legacy, unpatched Jenkins masters often do.

Concretely, Safeguard helps teams avoid a repeat of CVE-2015-8103 by:

• Continuously scanning CI/CD infrastructure — including Jenkins masters, agents, and plugins — for known-vulnerable versions and flagging exposed CLI or management interfaces before an attacker finds them.
• Mapping transitive dependencies, such as commons-collections pulled in indirectly, so security teams aren't relying on manual audits to discover deserialization-capable gadget classes hiding deep in a dependency tree.
• Enforcing policy gates in the pipeline that block builds or deployments relying on components with known critical RCE vulnerabilities, closing the gap between disclosure and remediation.
• Correlating vulnerability intelligence — CVE data, exploit availability, and exploitation-in-the-wild signals — so teams can prioritize fixes like CVE-2015-8103 based on real risk rather than raw CVSS numbers alone.
• Monitoring build infrastructure behavior to catch anomalous activity consistent with post-exploitation, such as unexpected outbound connections or process execution from CI service accounts.

Software supply chain attacks increasingly target the infrastructure that builds and ships your code, not just the code itself. CVE-2015-8103 proved a decade ago that a single unauthenticated deserialization flaw in a CI/CD tool can hand an attacker the keys to everything downstream. Safeguard is built to make sure that class of blind spot doesn't exist in your environment — today or years from now, when the next legacy component quietly becomes tomorrow's headline CVE.