Per this blog article from Nov 2015 there is a rather large security issue with apache commons-collections library v3.2.1 in which its presence on the classpath more or less turns the entire JVM into a remotely exploitable exec() function (metaphorically speaking).
While people are busy swapping out 3.2.1 for 3.2.2 and/or the newer collections 4.1, the way dependency graphs work in automated dependency management systems like maven, ivy, gradle, etc, is that you might be obtaining 3.2.1 from a transitive dependency. That's bad bad bad. So, apart from updating deps, it's important to guard against a recurrence, and you can do that, at least in maven, via the maven-enforcer-plugin.
I threw together this github gist with an example configuration that can ban this dep from your deps graph, including (most importantly) inclusions via transitive dependencies that you didn't even know you had. Here is the gist's content (I'll try to keep both updated if I change them).
<project> <!-- ... --> <build> <plugins> <plugin> <artifactId>maven-enforcer-plugin</artifactId> <executions> <execution> <goals><goal>enforce</goal></goals> <configuration> <rules> <bannedDependencies> <excludes> <exclude>commons-collections:commons-collections:[3.2.1]</exclude> </excludes> </bannedDependencies> </rules> </configuration> </execution> </executions> </plugin> </plugins> </build> </project>
So... fix your projects... but also make them better. Throw this into your project's parent pom, and then it will give you a build-breaking knowledge of whether you're vulnerable, and you can update your deps or use dependency exclusions to prune out any found occurrences you get from your upstream.