Why is Apache Commons Collections associated with a well-known deserialization vulnerability?

In 2015, security researchers demonstrated that several of the library's reflective functor classes could be chained together to build a so-called "gadget chain" - a sequence of ordinary, individually harmless objects that, when deserialized in a specific combination, ends up executing arbitrary code.

// simplified concept: chaining transformers so deserializing
// a TransformedMap/LazyMap triggers a reflective method call
Transformer chain = ChainedTransformer(
    ConstantTransformer(Runtime.class),
    InvokerTransformer("getMethod", ...),
    InvokerTransformer("invoke", ...)
);

The core piece enabling this was InvokerTransformer, which reflectively invokes a named method on whatever object it's given; combined with ChainedTransformer to sequence several calls, and a TransformedMap or LazyMap whose transform runs automatically during deserialization, an attacker could trigger a chain ending in something like Runtime.exec() purely by having a vulnerable application deserialize a malicious object stream.

The underlying root cause was Java's own default object deserialization trusting the incoming object graph without restriction - Commons Collections wasn't uniquely broken, but its powerful reflective functor classes happened to provide one of the easiest, most widely available gadget chains for exploiting that broader Java weakness. In response, later releases made InvokerTransformer and similar classes non-serializable by default, requiring an explicit opt-in system property to restore the old (riskier) behavior.