Secure EOL Versions of Apache Commons Collections with ELS

Go straight to an AI summary of this blog post instead

Key Takeaways

Commons Collections often arrives transitively, so it may be in your build even if nobody added it.
Its functors package supplied the building blocks for Java’s best-known deserialization gadget chains.
Moving from 3.x to 4.x means new coordinates, a new package namespace, and deliberate API breakage.
ELS for Apache Commons Collections patches EOL versions and their dependency chains while you plan the move.

If Apache Commons Collections is somewhere in your Java dependency graph, and in enterprise Java it often is, the end-of-life question is worth sorting out before a scanner or an auditor raises it for you.

This is the library behind some of Java’s most famous deserialization gadget chains. Not because Apache shipped a backdoor, but because a handful of classes in the functors package are serializable and use reflection, and somebody eventually noticed what you could build out of that. The 2015 disclosures turned a routine utility JAR into a dependency problem that security teams had to chase through application servers they did not control. This post covers that history, what it means for teams still running the older artifact line, and where extended support fits when migration is not happening this quarter.

Two Artifact Lines and Why That Matters

Commons Collections has been around since 2001. It extends the Java Collections Framework with the data structures, iterators, comparators, and transformation utilities the JDK never shipped, which is exactly why it ended up everywhere. Its ubiquity is also what made its security history so painful.

There are two artifact lines, and confusing them is the single most common source of bad remediation advice.

The legacy line is commons-collections:commons-collections, which covers the whole 3.x series and lives under the org.apache.commons.collections package namespace. Apache describes 3.2 and 3.2.1 as Java 1.2 compatible, with 3.2.1 released on April 15, 2008. The final release, 3.2.2, arrived in November 2015 as a security and bugfix release and moved to Java 1.3. Its headline change was disabling deserialization of the unsafe functor classes by default, so attempting it throws an UnsupportedOperationException unless somebody explicitly sets the org.apache.commons.collections.enableUnsafeSerialization system property to true. Nothing has shipped on the 3.x line since.

The current line is org.apache.commons:commons-collections4, and the package namespace moved to org.apache.commons.collections4 along with it. It got a new groupId and artifactId precisely because 4.0 was never meant to be backward compatible, and that namespace change is why a 3.x and a 4.x JAR can sit on the same classpath without colliding. 4.0 landed on November 27, 2013, with generics throughout and a Java 5 floor. 4.1 followed on November 28, 2015, and finished the job 3.2.2 had started, removing Serializable from the unsafe functor classes entirely rather than just gating them. After that came 4.2 on July 11, 2018, 4.3 on December 21, 2018, 4.4 on July 5, 2019, 4.5.0 on April 19, 2025, and the current release, 4.6.0, on August 6, 2026. The Java floor climbed alongside, from Java 5 at 4.0 to Java 6 at 4.1 and Java 7 at 4.2, then Java 8 from 4.3 onward, 4.6.0 included.

Apache does not publish a formal EOL notice for 3.x, so nobody is going to hand you a dated announcement to paste into a ticket. What you can state plainly is this: there has been no 3.x release since November 2015, all development happens on 4.x, and because 3.2.2 was the last of that line, nobody should plan on an upstream 3.x backport for a newly discovered issue.

What End of Life Actually Means Here

No More Upstream Fixes

For anything running on commons-collections:commons-collections, the practical position is simple. There has been no new 3.x release since 3.2.2, and Apache’s attention has been on the 4.x line for more than a decade.

Older 4.x releases sit in a milder version of the same spot. Apache’s published fixes arrive in newer 4.x releases, so for an issue affecting an older 4.x version, the normal upstream remediation path is moving to the current release.

The CVE Story That Plenty of People Get Slightly Wrong

It is worth being precise here, because scanner output and CVE titles do not agree, and that mismatch has caused a lot of wasted meetings.

Apache states on its own security page that no CVE ID was assigned to the Commons Collections library for the 2015 deserialization problem. The identifiers everybody quotes belong to downstream products. CVE-2015-7501 was filed against Red Hat JBoss products and CVE-2015-6420 against a long list of Cisco products, both rated 9.8 critical under CVSS v3, and both described as related to the Apache Commons Collections library rather than as flaws in it. Apache’s own page points at a third, CVE-2015-4852, for Oracle WebLogic Server.

The mechanism behind all of them is the same. Several classes in the functors package are serializable and invoke methods reflectively, with InvokerTransformer particularly useful to an attacker because it will invoke a specified method through reflection. Chain the necessary gadgets together, pass the resulting object to an application that deserializes untrusted input without validating it while those classes sit on the classpath, and the result can be arbitrary command execution with the privileges of the JVM process. Apache lists the affected range as 3.0 through 4.0, fixed in 3.2.2 and 4.1.

The timeline explains why it hit so hard. Gabriel Lawrence and Chris Frohoff presented the technique at AppSecCali on January 28, 2015. Stephen Breen published working attack scenarios against WebSphere, JBoss, Jenkins, WebLogic, and OpenNMS on November 6, 2015. Apache states that its security team was not informed before publication, so the fixes landed within weeks of a fully public exploit, and teams found the library sitting several levels deep in dependency trees they could not directly change.

So when your scanner flags a 3.2.1 JAR under a CVE whose title mentions Cisco, the scanner is not misfiring. Those advisory records tie vulnerable Commons Collections versions to the downstream products that shipped them, and the GitHub Advisory Database carries the same issue against the Maven artifact as GHSA-6hgm-866r-3cjv. The finding is real even though the CVE has somebody else’s product name on it.

Compliance and Audit Exposure

PCI DSS v4.0.1 Requirement 6.3.3 requires patches for vulnerabilities your organization ranks as critical to be installed within one month of release, with everything else on a timeframe you set through the same risk-ranking process in Requirement 6.3.1. PCI DSS does not automatically treat every CVSS 7.0 finding as critical, so how hard a Commons Collections finding lands depends on your documented ranking and your actual exposure. The HIPAA Security Rule works differently, obliging covered entities and business associates to protect electronic protected health information against reasonably anticipated threats, which is exactly the kind of open-ended duty an unpatched EOL component makes awkward to defend.

Unsupported components can also raise questions about vulnerability-management controls during a SOC 2 Type II audit, and FedRAMP authorization brings continuous monitoring and flaw remediation expectations of its own. Extended support does not make an organization compliant on its own, but it does keep a patch stream flowing so vulnerability-management commitments stay meetable while a migration is still being planned.

The Dependency Tree Problem

Commons Collections itself is not the tangle. The 4.6.0 artifact has a tiny footprint, with commons-codec 1.22.1 as its only optional compile dependency and everything else scoped to tests, so its own contribution to a consumer’s runtime dependency graph is minimal.

The mess is on the consumer side. Application servers bundle it, build tools ship it, and legacy frameworks require it. Run mvn dependency:tree against a mature enterprise Java application and you may well find an old 3.x commons-collections JAR in the output, pulled in by something whose maintainers last touched their dependency declarations a very long time ago. Every vulnerable copy on that graph can turn into a finding, because scanners walk the whole thing rather than stopping at what you declared. Whether a given copy counts depends on the version, since 3.0 through 3.2.1 sit in the affected range while 3.2.2 already carries Apache’s mitigation.

That is what makes Apache Commons Collections EOL awkward. It is less a library version problem than a reach and visibility problem, and when the thing pulling in the old JAR is itself unmaintained, patching the library where it actually sits avoids the compatibility risk of forcing a newer transitive version into a dependency chain nobody is maintaining.

What Are Your (Realistic) Options?

Migrating to commons-collections4 4.6.0

The clean long-term answer is moving from commons-collections:commons-collections to org.apache.commons:commons-collections4 at 4.6.0, which puts you on the actively maintained line.

It is not a version bump, though. It is a dependency swap with API changes that require reviewing every class that touches the library. Generics went in throughout, deprecated 3.x classes came out, the Buffer interface was replaced with java.util.Queue, and utility signatures moved. Every import has to move to the collections4 namespace, and anything leaning on 3.x behavior, especially in the functors package, needs real code changes before it will compile.

Teams already on 4.x have a smaller job, though still one that calls for reading the changelogs for each intermediate release and testing the upgrade path rather than bumping blind.

Where Commons Collections arrives transitively rather than directly, the migration path runs through whatever is pulling it in. If those libraries are themselves unmaintained, you are left overriding transitive versions and validating compatibility yourself, which is doable but neither free nor always safe.

Replacing Commons Collections Outright

Some teams treat an EOL finding as a good excuse to ask whether they still need the library at all. The alternatives are genuinely good now, including Eclipse Collections, Guava’s collection utilities, and a standard library that has absorbed much of what sent people to Commons Collections in the first place.

Replacing it wholesale is a bigger job than upgrading it. Every usage site needs an equivalent, behavioral differences need testing, and anything built on functors or transformation pipelines needs individual attention. For a codebase with years of accumulated usage, that is a multi-sprint project, not an answer to a finding that landed last Tuesday.

Endless Lifecycle Support From TuxCare

ELS for Apache Commons Collections keeps security patches flowing for supported EOL versions without asking you to execute a migration your team has not scoped. Coverage currently includes 3.2 and 3.2.1 – other versions are worth asking about. If you are on a supported version, it stays where it is, your existing workflows are untouched, and patches keep arriving as new issues surface.

That is the gap the product exists to cover, the stretch between the moment an EOL version becomes a liability on a report and the moment a planned, tested migration is actually finished.

Why Rushing the Upgrade Backfires

The pressure is real. Scanners surface it, auditors ask about the plan, and compliance windows do not move. The teams that handle this well are the ones that separate responding to risk from manufacturing a new one.

What the Migration Actually Involves

Moving off 3.x means updating the artifact coordinates wherever the dependency is declared or centrally managed, rewriting imports for the new package namespace, then reviewing collection usages for the type-safety and API changes that came with the generified 4.x API. Removed classes need replacements or rewrites. Code using the 3.x functors package has to be evaluated case by case, since some of it maps cleanly onto Java 8 functional interfaces and some of it needs a design-specific rewrite.

For anything that processes serialized Java data, the difference between the 3.2.2 model, where unsafe functor deserialization is off unless a system property switches it on, and the 4.1 model, where those classes are not serializable at all, needs to be understood and tested before it reaches production.

What Goes Wrong When It Gets Compressed

Compile failures are the easy part, because APIs that were renamed or removed announce themselves immediately. The interesting failures are quieter. Binary compatibility problems can surface as NoSuchMethodError at runtime, while failed reflective lookups can produce NoSuchMethodException instead, and neither is guaranteed to be caught by compilation alone.

Behavior changes are worse. MultiValueMap was deprecated in 4.1 in favor of the newer MultiValuedMap interface, BeanMap came out in 4.0 with the equivalent moved to Commons BeanUtils, and 4.6.0 deprecated the whole Bag family in favor of MultiSet. Code that depends on the old semantics can pass a test suite and then fail under one specific data shape in production.

Then there is the debris. Compatibility shims written to hit a date become permanent, and “we will clean this up later” turns into somebody else’s ticket. Add emergency engineering time, delayed roadmap work, and senior engineers debugging production instead of shipping, and a rushed migration can easily cost more than the deadline it was meant to satisfy. The problem does not get solved that way. It gets deferred at a markup.

How TuxCare ELS for Apache Commons Collections Works

TuxCare has fifteen years of open source patching behind it and has delivered more than 420,000 patches across operating systems, runtimes, frameworks, and libraries. ELS for Apache Commons Collections runs on that same process.

Dependency Chain Coverage Included

Coverage extends to both direct and transitive dependencies at no extra cost. Scanners do not stop at the top-level artifact, so neither does the patching.

How the Patches Get Made

CVE tracking runs continuously against NVD, vendor advisories, GitHub Security Advisories, and other sources. When something lands, algorithmic tooling and AI-assisted automation help engineers with the backport, security engineers validate the result, and every build goes through integrity, functionality, and regression testing before it reaches a repository. Patches ship signed from TuxCare-hosted repositories, and the Open Source Patching Process whitepaper has the full detail if you want to see the pipeline.

Fitting Into Your Build

Whether you pull Commons Collections through Maven or Gradle, the main change is pointing your build at TuxCare’s repository and confirming that dependency resolution picks up the patched artifact. Your pipeline, your CI/CD, and the way your team works all stay as they are.

How Fast Patches Arrive

High- and critical-risk vulnerabilities affecting supported EOL versions, meaning CVSS 7.0 and above, carry a target of 14 days from public disclosure, with 60 days for medium risk and 90 for low. Vulnerability triage and troubleshooting support runs 24/7/365.

Visibility for Auditors

TuxCare’s CVE tracker shows which vulnerabilities have been identified and addressed across supported products and their dependency chains. That gives security and compliance teams clearer evidence of what has actually been remediated than a point-in-time scanner result on its own.

Do Not Let an EOL Finding Turn Into an Incident

An EOL Commons Collections version does not break anything on its own. What it does is leave you without a maintained upstream 3.x release to fall back on when the next vulnerability affecting that release turns up, or when classes still sitting on your classpath become useful in a newly disclosed deserialization chain.

If keeping an older Commons Collections release secure while you plan the move is the problem in front of you, take a look at what TuxCare’s Endless Lifecycle Support for Open Source Software covers across the rest of your stack.

Summary