In November 2015, a single advisory turned into an industry-wide fire drill. Security researchers Chris Frohoff and Gabriel Lawrence had already shown, in their "Marshalling Pickles" research and the accompanying ysoserial tool, that a handful of classes in the widely-used Apache Commons Collections library could be chained together to turn what looked like an ordinary Java deserialization vulnerability into remote code execution. When Steve Breen of FoxGlove Security published a follow-up post demonstrating working exploits against WebLogic, WebSphere, JBoss, and Jenkins, vendors across the Java ecosystem scrambled to figure out where else the same library was quietly sitting on their classpaths. Cisco was one of them: CVE-2015-6420 was the CVE it assigned to describe how several of its products — including Cisco Unified Computing System (UCS) Central Software and Cisco Unified Communications Domain Manager (Unified CDM) — bundled a vulnerable version of Apache Commons Collections and exposed serialized Java object interfaces to untrusted input. Cisco's own advisory described it as "a similar issue to CVE-2015-4852," the WebLogic deserialization flaw that had become the poster child for this entire vulnerability class.
The underlying weakness is a textbook case of CWE-502, Deserialization of Untrusted Data. Java's native serialization mechanism will happily reconstruct any object graph an attacker supplies, as long as the classes referenced are present on the receiving application's classpath. Commons Collections shipped a set of "functor" classes — most notoriously InvokerTransformer, used together with ChainedTransformer and LazyMap — that let arbitrary method invocations be triggered purely as a side effect of deserializing an object. An attacker who could reach any endpoint that deserialized raw Java objects, and who knew Commons Collections was on the classpath, could craft a payload that executed operating-system commands without ever needing valid credentials. This is the technique now broadly known as the commons-collections deserialization gadget chain, and ysoserial made generating a working payload for it a matter of running a single command line tool rather than months of exploit development.
Affected Versions and Components
The core library flaw sits in Apache Commons Collections 3.x prior to 3.2.2 and 4.x prior to 4.1. Any Java application that (a) had one of these vulnerable Commons Collections releases on its classpath and (b) deserialized Java objects from an untrusted or network-reachable source was potentially exploitable, regardless of whether the application's own code ever directly referenced the dangerous classes.
CVE-2015-6420 specifically tracks this exposure inside Cisco's product line. Per Cisco's advisory, the affected products included Cisco UCS Central Software and Cisco Unified Communications Domain Manager, tracked internally under bug IDs CSCuw06251, CSCuw76736, CSCux14766, and CSCux29901. Because these products embedded an older, vulnerable Commons Collections jar as a transitive dependency, the fix required Cisco to patch its own software rather than end customers being able to simply swap out a library. This is one of the clearest early examples of a software supply chain vulnerability in the modern sense: the flaw didn't originate in Cisco's code at all, it arrived bundled inside a third-party open-source component, and it stayed invisible until someone went looking specifically for that dependency.
The same underlying Commons Collections issue rippled out well beyond Cisco. Oracle WebLogic (CVE-2015-4852), IBM WebSphere (CVE-2015-7450), and numerous other Java middleware and application products were found to carry the same exploitable combination of a vulnerable Commons Collections version plus an unauthenticated deserialization entry point, which is why security teams at the time treated this less as "one CVE to patch" and more as "one dependency to hunt down everywhere it hides."
CVSS, EPSS, and KEV Context
NVD's record for CVE-2015-6420 carries a CVSS v2 base score of 7.5 (High), reflecting a network-exploitable, low-complexity, no-authentication-required vulnerability with impact to confidentiality, integrity, and availability — consistent with the scoring given to its sibling CVE-2015-4852. As is common for vulnerabilities from this era, no CVSS v3 vector was assigned at disclosure time.
EPSS scoring wasn't in general use back in 2015, but retroactive EPSS data for legacy deserialization CVEs like this one tends to sit well above the median for all CVEs, because the exploitation technique is public, automatable through ysoserial, and requires no novel research to reproduce — exactly the conditions EPSS weighs most heavily. We did not find CVE-2015-6420 specifically listed in CISA's Known Exploited Vulnerabilities (KEV) catalog at the time of writing; readers relying on KEV status for prioritization should not treat its absence there as evidence the underlying gadget-chain technique is low risk, since KEV tracks confirmed in-the-wild exploitation of a specific CVE ID, not of a broader vulnerability class that has since been exploited via many different CVEs and entry points.
Timeline
- January 2015 — Chris Frohoff and Gabriel Lawrence present "Marshalling Pickles" at AppSecCali, introducing the concept of Java deserialization gadget chains built from common libraries.
- November 6, 2015 — Steve Breen of FoxGlove Security publishes a widely-read post demonstrating remote code execution against WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS using Commons Collections gadget chains, dramatically raising public awareness.
- November 2015 — The Apache Commons project ships Commons Collections 3.2.2 and later 4.1, which disable the dangerous functor classes by default and require explicit opt-in to re-enable them.
- Late 2015 — Vendors across the Java ecosystem, including Oracle, IBM, RedHat, and Cisco, publish their own advisories and patches for products found to bundle vulnerable Commons Collections builds.
- December 2015 — Cisco publishes its advisory covering UCS Central Software, Unified CDM, and related products, and CVE-2015-6420 is published in the National Vulnerability Database.
Remediation Steps
- Upgrade the library. Move any application still using Apache Commons Collections 3.x below 3.2.2, or 4.x below 4.1, to a fixed release. The patched versions disable the unsafe
InvokerTransformer-based functor classes by default. - Apply vendor patches. For products affected under CVE-2015-6420 specifically — Cisco UCS Central Software, Unified CDM, and related platforms — apply the fixed software releases identified in Cisco's advisory rather than attempting to swap the bundled jar yourself.
- Eliminate native Java deserialization of untrusted input where possible. Prefer safer, schema-constrained formats such as JSON, and avoid exposing
ObjectInputStream-based endpoints to network-reachable or unauthenticated callers. - Add deserialization filtering. Where native serialization can't be removed, use Java's serialization filtering mechanism (available via JEP 290 in Java 9 and backported to 8u121+, 7u131+, and 6u141+) to allow-list acceptable classes and block known gadget-chain classes outright.
- Inventory transitive dependencies. Because this vulnerability lived inside a bundled third-party library rather than first-party code, teams need visibility into what's actually shipping inside every application and appliance they run — not just what's declared in a top-level manifest.
- Monitor for exploitation signatures. Network and endpoint monitoring for anomalous outbound connections or process spawning from Java application servers can help catch exploitation attempts even where patching has lagged.
How Safeguard Helps
CVE-2015-6420 is a decade-old illustration of a problem that has only gotten more urgent: vulnerabilities that live inside the software supply chain, hidden several layers deep in transitive dependencies, rather than in code your own engineers wrote. As a Java deserialization vulnerability bundled inside vendor firmware rather than first-party code, it's also a reminder that this bug class doesn't stay contained to the application you wrote — it rides along inside whatever appliances and third-party products you deploy. Safeguard is built precisely for this class of risk.
Safeguard continuously generates and monitors software bills of materials (SBOMs) across your applications, containers, and vendor-supplied appliances, so a vulnerable Apache Commons Collections version bundled three dependencies deep gets surfaced automatically rather than discovered after a researcher's blog post forces an emergency scramble. When a new CVE like this one is disclosed, or a new gadget chain against a familiar library is published, Safeguard maps it against your live dependency graph and tells you exactly which services, containers, and vendor products are actually affected — not just which ones nominally list the library.
Because this specific vulnerability shows how third-party and vendor software can carry inherited risk from open-source components, Safeguard also extends visibility into vendor and appliance risk: tracking the open-source components embedded in the software you procure, not just the software you build, so that a Cisco-style "we bundled an old library" scenario doesn't stay invisible until it's exploited. Combined with policy enforcement that can block builds or deployments containing known-vulnerable versions of libraries like Commons Collections, and prioritization that blends CVSS, EPSS, and exploit-availability signals like the public ysoserial tooling that made this bug so dangerous, Safeguard helps security and engineering teams find and remediate deserialization gadget risks before they become the next FoxGlove Security blog post.