Apache Commons Collections deserialization gadget RCE (CVE-2015-7501)

In November 2015, researchers Chris Frohoff and Gabriel Lawrence detonated a quiet time bomb that had been sitting in millions of Java applications for years: a deserialization gadget chain built entirely out of legitimate, widely-used Apache Commons Collections classes. Tracked as CVE-2015-7501, the issue allows an attacker who can deliver a crafted serialized Java object to an application to achieve remote code execution (RCE) — no memory corruption, no exotic exploit primitive, just Java doing exactly what its readObject() contract allows it to do. Because Commons Collections was bundled, transitively, into an enormous swath of enterprise middleware — WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and countless internal applications — CVE-2015-7501 didn't just break one product. It exposed a systemic weakness in how the entire Java ecosystem handled untrusted deserialization, and it spawned a wave of downstream, product-specific CVEs that security teams are still patching today.

This post breaks down what CVE-2015-7501 is, why it was so consequential, and what concrete steps your team should take if Apache Commons Collections is anywhere in your dependency tree — plus how Safeguard helps you find and prioritize this exact class of risk before attackers do.

What Is CVE-2015-7501?

Apache Commons Collections is a foundational utility library used by an enormous percentage of the Java ecosystem to extend the standard Collections framework with additional data structures and functional-style helpers. Among those helpers is a class called InvokerTransformer, which — by design — invokes an arbitrary method on an arbitrary object using reflection. That's a legitimate and useful capability inside trusted code. The problem is that InvokerTransformer, along with several other Transformer implementations (ChainedTransformer, ConstantTransformer, InstantiateTransformer), is Serializable. When an application deserializes untrusted data — via ObjectInputStream.readObject() — and Commons Collections is present on the classpath, an attacker can construct a serialized payload that chains these transformers together into an arbitrary method-invocation chain. Point that chain at Runtime.exec() and you have unauthenticated remote code execution, triggered the instant the malicious object is deserialized.

Frohoff and Lawrence's "Marshalling Pickles" research and the accompanying ysoserial tool turned this from an academic curiosity into a weaponized, push-button exploit generator. Within days, FoxGlove Security published proof-of-concept RCE chains against Oracle WebLogic, IBM WebSphere, JBoss, Jenkins, and OpenNMS — all built on the same underlying Commons Collections gadget chain, just delivered through each product's own deserialization entry point (RMI listeners, JMX endpoints, HTTP session handling, and more).

CVE-2015-7501 is the identifier most commonly used to track the underlying library-level issue and the class of downstream RCEs it enabled. Because the vulnerable code lived in a library, not a single application, the blast radius was determined not by one vendor's patch cycle but by every downstream consumer's willingness to update a transitive dependency — which, nearly a decade later, is still an open problem in a nontrivial number of environments.

Affected Versions and Components

• Apache Commons Collections 3.x prior to 3.2.2 — vulnerable. The InvokerTransformer and related transformer classes are unconditionally serializable and exploitable.
• Apache Commons Collections 4.x prior to 4.1 — vulnerable via the equivalent org.apache.commons.collections4 package.
• Commons Collections 3.2.2 and 4.1 — the Apache Commons project's fix does not remove the dangerous classes; it disables deserialization of them by default, requiring an explicit opt-in system property (org.apache.commons.collections.enableUnsafeSerialization) to restore the old behavior. This is a critical nuance: upgrading the library version alone doesn't guarantee protection if that flag is set somewhere in your configuration.
• Any application or platform that deserializes untrusted Java objects while a vulnerable Commons Collections version is reachable on the classpath. This is the part that made CVE-2015-7501 so far-reaching. It's not enough to ask "do we use Commons Collections directly?" — the library is pulled in transitively by an enormous number of frameworks and application servers, meaning teams that had never heard of the library were nonetheless exposed.
• Notable downstream products confirmed exploitable at the time of disclosure included Oracle WebLogic Server, IBM WebSphere Application Server, JBoss/Red Hat middleware, Jenkins, OpenNMS, and Apache Sling-based platforms — several of which received their own dedicated CVE identifiers (e.g., CVE-2015-4852 for WebLogic, CVE-2015-8103 for Jenkins) because the deserialization entry point differed by product even though the gadget chain was identical.

CVSS, EPSS, and KEV Context

CVE-2015-7501 is rated in NVD under CVSS v2 with a base score of 7.5 (High) (AV:N/AC:L/Au:N/C:P/I:P/A:P) — reflecting network-exploitability with low attack complexity and no authentication required, though the original scoring predates CVSS v3's clearer distinction between confidentiality, integrity, and availability impact for full RCE. In practice, the real-world severity is closer to critical: successful exploitation grants full remote code execution in the context of the vulnerable process, which on most affected middleware means complete host or application compromise.

EPSS (Exploit Prediction Scoring System) data for CVE-2015-7501 has consistently placed it in the upper percentile of scored CVEs, reflecting the fact that working, public exploit tooling (ysoserial) has existed since disclosure and continues to be used in the wild — this is not a theoretical bug with a hard-to-build exploit chain, it's a "download the tool, generate the payload, send it" scenario.

CVE-2015-7501 itself is not separately listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, but several of its downstream, product-specific siblings and later Java deserialization CVEs that reuse the same Commons Collections gadget chains have appeared in KEV over the years, and active exploitation of unpatched Commons Collections deserialization continues to show up in incident response and threat intel reporting well after the original 2015 disclosure — a pattern consistent with how deeply the vulnerable library versions became embedded in legacy Java deployments.

Timeline

• 2008–2015 — InvokerTransformer and related classes ship as ordinary, serializable utility classes in Commons Collections 3.x and 4.x, with no indication they represent a security risk in isolation.
• January 28, 2015 — Chris Frohoff and Gabriel Lawrence present "Marshalling Pickles: How Deserializing Objects Can Ruin Your Day" at AppSecCali, introducing Java deserialization gadget chains as a practical attack class and releasing the ysoserial proof-of-concept tool.
• November 6, 2015 — FoxGlove Security publishes "What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability," demonstrating unauthenticated RCE against multiple major Java platforms using the Commons Collections gadget chain.
• October–November 2015 — The Apache Commons project releases Commons Collections 3.2.2 and 4.1, mitigating unsafe deserialization of the transformer classes by default.
• Late 2015–2016 — Oracle, IBM, Red Hat, Jenkins, and other affected vendors issue emergency patches and their own CVE identifiers for the product-specific exploitation paths.
• 2016–present — CVE-2015-7501 and its associated gadget chain remain a staple of penetration tests, red team engagements, and real-world intrusions against organizations running legacy Java middleware that has never updated its Commons Collections dependency or has re-enabled unsafe deserialization for compatibility reasons.

Remediation Steps

1. Inventory your Java dependency tree for Commons Collections. Don't stop at direct dependencies — use your build tool's dependency tree command (mvn dependency:tree, gradle dependencies) or an SCA/SBOM tool to surface transitive inclusions, since most exposure comes from indirect pulls through application servers and frameworks.
2. Upgrade to Commons Collections 3.2.2 / 4.1 or later. These versions disable unsafe deserialization of the dangerous transformer classes by default.
3. Explicitly verify the enableUnsafeSerialization flag is not set in any configuration, JVM system property, or legacy compatibility shim — some organizations re-enabled it during the 2015–2016 patch cycle to avoid breaking functionality, and that flag has a way of surviving migrations for years.
4. Patch or upgrade downstream platforms (application servers, CI/CD tools, monitoring platforms) to versions that both bundle a fixed Commons Collections version and close their own deserialization entry points.
5. Eliminate or restrict native Java deserialization of untrusted input wherever possible. Prefer safer serialization formats (JSON, Protocol Buffers) for any data crossing a trust boundary; where ObjectInputStream cannot be removed, implement class allowlisting (e.g., ObjectInputFilter in modern JDKs) so only expected classes can be instantiated during deserialization.
6. Restrict network exposure of deserialization endpoints — RMI registries, JMX endpoints, and similar interfaces should never be reachable from untrusted networks, and should sit behind authentication even internally.
7. Monitor for exploitation indicators, including unexpected outbound connections or process spawning (cmd.exe, /bin/sh) originating from application server or middleware processes, which is the classic signature of a successful gadget-chain RCE.

How Safeguard Helps

CVE-2015-7501 is a decade-old reminder that transitive dependency risk doesn't expire on its own — it lingers in build artifacts, container base images, and legacy JARs until someone with the right tooling finds it, and attackers keep looking long after defenders stop. Safeguard's SBOM generation and ingestion pipeline automatically surfaces every instance of Commons Collections in your software inventory, including deeply nested transitive copies that manual dependency reviews routinely miss. From there, our reachability analysis determines whether the vulnerable InvokerTransformer gadget classes and any deserialization call path are actually exercised in your running code — cutting through alert fatigue by distinguishing exploitable exposure from dormant, unreachable library code. Griffin AI correlates that reachability signal with exploit intelligence and your runtime deployment context to prioritize CVE-2015-7501-class findings against your real attack surface, not just its theoretical CVSS score. Where a fix path exists, Safeguard can generate an auto-fix pull request that bumps the vulnerable dependency and flags any configuration (like a lingering unsafe-serialization property) that would otherwise silently reintroduce the risk. The result is that gadget-chain vulnerabilities like this one get found, prioritized, and remediated on your timeline — not the attacker's.