While working on this issue I realized that commons-beanutils depends on commons-collections (i.e. 3.x) and that there is no new version of commons-beanutils that depends on commons-collections4. According to BEANUTILS-532 [1] it looks like we'll have to wait for commons-beanutils2 which is a complete rewrite. This rewrite appears to have started a while back and may be functionally abandoned. Thankfully I checked the commons-beanutils code-base and it doesn't use org.apache.commons.collections.list.SetUniqueList either so this warning from your security scanner is essentially a false positive.
Justin [1] https://issues.apache.org/jira/browse/BEANUTILS-532 On Wed, Aug 21, 2024 at 10:18 AM Justin Bertram <jbert...@apache.org> wrote: > The ActiveMQ Artemis code-base doesn't use > org.apache.commons.collections.list.SetUniqueList so this problem doesn't > apply. > > That said, moving to commons-collections4 is a good idea. I've opened > ARTEMIS-5006 [1] for this. > > > Justin > > [1] https://issues.apache.org/jira/browse/ARTEMIS-5006 > > On Wed, Aug 21, 2024 at 9:17 AM <apa...@materne.de> wrote: > >> Hello, >> >> >> >> the security scanner in my company raised an issue with >> commons-collections, >> which is a transative dependency from Artemis: >> >> >> >> Part of our „mvn dependeny:tree“ >> >> +- org.apache.activemq:artemis-junit-5:jar:2.36.0:test >> >> +- org.apache.activemq:artemis-server:jar:2.31.2:test >> >> \- commons-collections:commons-collections:jar:3.2.2:compile >> >> >> >> AFAIK the 3.x of commons-collections is EOL in favor to collections4 – >> also >> with new GAV coordinates >> >> <groupId>org.apache.commons</groupId> >> >> <artifactId>commons-collections4</artifactId> >> >> >> >> >> >> Some details about that security issue: >> >> >> >> Score >> >> vulnerability sonatype-2024-3350 with severity >= 7 (severity = 8.7) >> >> >> >> Explanation >> >> The Apache commons-collections packages are vulnerable to a Denial of >> Service (DoS) attack. The add() method of the SetUniqueList class >> mishandles >> the order of operations when invoking its parent List implementation. >> Consequently, adding an instance of itself results in infinite recursion >> and >> deviates from the behavior defined by the standard JRE List contract. A >> remote attacker who can cause an application to add SetUniqueList >> instances >> to themselves can exploit this vulnerability to crash the affected >> application with a StackOverflowError exception. >> >> >> >> Version Affected >> >> [3.2,3.2.2] >> >> >> >> Root Cause >> >> >> >> >> >> commons-collections-3.2.2.redhat-2.jarorg/apache/commons/collections/list/Se >> tUniqueList.class[3.0, ) >> >> >> >> Advisories >> >> >> >> Project >> >> https://issues.apache.org/jira/browse/COLLECTIONS-701 >> >> >> >> CVSS Details >> >> >> >> Sonatype CVSS 4 >> >> 8.7 >> >> CVSS Vector >> >> CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N >> >> >> >> >> >> That issue is fixed for 4.3. >> >> >> >> >> >> Do you plan to update to collections4? >> >> >> >> >> >> >> >> cheers >> >> Jan Matèrne >> >>
