Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Commons Collections est souvent intégrée de manière transitif ; il se peut donc qu'elle figure dans votre version même si personne ne l'a ajoutée.
- Son package « functors » a fourni les éléments de base des chaînes de gadgets de désérialisation les plus connues de Java.
- Le passage de la version 3.x à la version 4.x implique de nouvelles coordonnées, un nouvel espace de noms pour les paquets et une rupture délibérée de l'API.
- ELS pour Apache Commons Collections corrige les versions en fin de vie (EOL) et leurs chaînes de dépendances pendant que vous planifiez la migration.
Si Apache Commons Collections figure quelque part dans votre graphe de dépendances Java — ce qui est souvent le cas dans le domaine du Java d'entreprise —, il vaut mieux régler la question de la fin de vie avant qu'un scanner ou un auditeur ne vous la pose.
Il s'agit de la bibliothèque à l'origine de certaines des chaînes d'exploits de désérialisation les plus célèbres de Java. Non pas parce qu'Apache aurait intégré une porte dérobée, mais parce qu'une poignée de classes du package `functors` sont sérialisables et utilisent la réflexion, et que quelqu'un a fini par remarquer ce qu'il était possible de construire à partir de cela. Les révélations de 2015 ont transformé un fichier JAR utilitaire banal en un problème de dépendance que les équipes de sécurité ont dû traquer à travers des serveurs d’applications qu’elles ne contrôlaient pas. Cet article revient sur cette histoire, explique ce que cela implique pour les équipes qui utilisent encore l’ancienne version de l’artifact, et précise le rôle du support étendu lorsque la migration n’est pas prévue pour ce trimestre.
Deux gammes d'artefacts et pourquoi c'est important
Commons Collections existe depuis 2001. Il étend le Java Collections Framework avec des structures de données, des itérateurs, des comparateurs et des utilitaires de transformation qui n’ont jamais été fournis avec le JDK, ce qui explique précisément pourquoi il s’est imposé partout. C’est d’ailleurs cette omniprésence qui a rendu son histoire en matière de sécurité si douloureuse.
Il existe deux types d'artefacts, et les confondre est la cause la plus fréquente de mauvais conseils en matière de remédiation.
La gamme classique est commons-collections:commons-collections, qui couvre l'ensemble de la série 3.x et se trouve sous le répertoire org.apache.commons.collections espace de noms de paquets. Apache décrit les versions 3.2 et 3.2.1 comme étant compatibles avec Java 1.2 ; la version 3.2.1 a été publiée le 15 avril 2008. La version finale, la 3.2.2, est parue en novembre 2015 sous la forme d’une mise à jour de sécurité et de correction de bogues, et est passée à Java 1.3. Son principal changement consistait à désactiver par défaut la désérialisation des classes de foncteurs non sécurisées ; toute tentative en ce sens provoque donc une exception UnsupportedOperationException à moins que quelqu'un ne définisse explicitement le org.apache.commons.collections.enableUnsafeSerialization régler la propriété système sur « true ». Aucune version n'a été publiée depuis dans la série 3.x.
La ligne actuelle est : org.apache.commons:commons-collections4, et l'espace de noms du paquet a été déplacé vers org.apache.commons.collections4 en même temps. Elle a reçu un nouveau `groupId` et un nouvel `artifactId` précisément parce que la version 4.0 n’a jamais été conçue pour être rétrocompatible, et c’est grâce à ce changement d’espace de noms qu’un fichier JAR 3.x et un fichier JAR 4.x peuvent coexister dans le même classpath sans entrer en conflit. La version 4.0 a été publiée le 27 novembre 2013, avec l’intégration complète des génériques et une compatibilité minimale avec Java 5. La version 4.1 a suivi le 28 novembre 2015 et a achevé le travail commencé par la version 3.2.2, en supprimant complètement l’interface `Serializable` des classes de foncteurs non sécurisées, plutôt que de simplement les restreindre. Vint ensuite la version 4.2 le 11 juillet 2018, puis la 4.3 le 21 décembre 2018, la 4.4 le 5 juillet 2019, la 4.5.0 le 19 avril 2025 et la version actuelle, la 4.6.0, le 6 août 2026. Le seuil Java a évolué en parallèle, passant de Java 5 à 4,0 à Java 6 à 4,1, puis à Java 7 à 4,2, avant d’atteindre Java 8 à partir de la version 4,3, y compris la version 4.6.0.
Apache ne publie pas d’avis officiel de fin de vie (EOL) pour la version 3.x ; personne ne vous fournira donc d’annonce datée à copier-coller dans un ticket. Ce que vous pouvez clairement indiquer, c’est ceci : aucune version 3.x n’a été publiée depuis novembre 2015, tout le développement se fait désormais sur la version 4.x, et comme la version 3.2.2 était la dernière de cette branche, personne ne devrait compter sur un backport en amont de la version 3.x pour un problème récemment découvert.
Ce que signifie réellement « fin de vie » ici
Finies les corrections en amont
Pour tout ce qui fonctionne sur commons-collections:commons-collections, dans la pratique, la situation est simple. Il n'y a pas eu de nouvelle version 3.x depuis la 3.2.2, et Apache se concentre sur la branche 4.x depuis plus d'une décennie.
Les anciennes versions 4.x se trouvent dans une situation similaire, mais moins grave. Les correctifs publiés par Apache sont intégrés dans les versions 4.x plus récentes ; ainsi, pour un problème affectant une ancienne version 4.x, la procédure normale de correction en amont consiste à passer à la version actuelle.
L'histoire du CVE que beaucoup de gens interprètent un peu à tort
Il convient d'être précis sur ce point, car les résultats du scanner et les intitulés des CVE ne correspondent pas, et cette divergence a entraîné de nombreuses réunions inutiles.
Apache précise sur sa propre page dédiée à la sécurité qu’aucun identifiant CVE n’a été attribué à la bibliothèque Commons Collections pour le problème de désérialisation de 2015. Les identifiants que tout le monde cite concernent des produits en aval. Le CVE-2015-7501 a été enregistré pour les produits Red Hat JBoss et le CVE-2015-6420 pour une longue liste de produits Cisco ; tous deux ont reçu la note « critique » (9,8) selon le CVSS v3, et sont décrits comme liés à la bibliothèque Apache Commons Collections plutôt que comme des failles de celle-ci. La page d’Apache elle-même mentionne un troisième identifiant, CVE-2015-4852, concernant Oracle WebLogic Server.
Le mécanisme à la base de toutes ces classes est le même. Plusieurs classes du package « functors » sont sérialisables et invoquent des méthodes de manière réflexive, avec InvokerTransformer particulièrement utile pour un attaquant, car elle permet d'appeler une méthode spécifiée via la réflexion. En enchaînant les gadgets nécessaires, puis en transmettant l'objet ainsi obtenu à une application qui désérialise des données non fiables sans les valider, alors que ces classes se trouvent dans le classpath, il est possible d'aboutir à l'exécution de commandes arbitraires avec les privilèges du processus JVM. Apache indique que les versions concernées vont de la 3.0 à la 4.0 ; ce problème a été corrigé dans les versions 3.2.2 et 4.1.
La chronologie explique pourquoi cette faille a eu un tel impact. Gabriel Lawrence et Chris Frohoff ont présenté cette technique lors de la conférence AppSecCali, le 28 janvier 2015. Stephen Breen a publié, le 6 novembre 2015, des scénarios d'attaque fonctionnels visant WebSphere, JBoss, Jenkins, WebLogic et OpenNMS. Apache indique que son équipe de sécurité n'avait pas été informée avant cette publication ; les correctifs ont donc été déployés quelques semaines seulement après la divulgation publique de l'exploit, et les équipes ont découvert que la bibliothèque se trouvait à plusieurs niveaux de profondeur dans des arborescences de dépendances qu'elles ne pouvaient pas modifier directement.
Ainsi, lorsque votre scanner signale un fichier JAR 3.2.1 associé à un CVE dont le titre mentionne Cisco, il ne s'agit pas d'une fausse alerte. Ces fiches d’alerte associent les versions vulnérables de Commons Collections aux produits en aval qui les ont intégrées, et la base de données d’alertes GitHub (GitHub Advisory Database) répertorie le même problème concernant l’artefact Maven sous la référence GHSA-6hgm-866r-3cjv. La vulnérabilité est bien réelle, même si le CVE mentionne le nom d’un autre produit.
Risques liés à la conformité et à l'audit
L'exigence 6.3.3 de la norme PCI DSS v4.0.1 impose l'installation des correctifs relatifs aux vulnérabilités que votre organisation classe comme critiques dans un délai d'un mois à compter de leur publication, les autres vulnérabilités devant être traitées selon un calendrier que vous définissez via le même processus de classification des risques décrit à l'exigence 6.3.1. La norme PCI DSS ne considère pas automatiquement chaque résultat CVSS 7.0 comme critique ; par conséquent, l'importance accordée à un résultat de Commons Collections dépend de votre classification documentée et de votre exposition réelle. La règle de sécurité HIPAA fonctionne différemment : elle oblige les entités concernées et leurs partenaires commerciaux à protéger les informations de santé électroniques protégées contre les menaces raisonnablement prévisibles, ce qui correspond exactement au type d’obligation ouverte qu’un composant en fin de vie (EOL) non corrigé rend difficile à respecter.
Les composants non pris en charge peuvent également soulever des questions concernant les contrôles de gestion des vulnérabilités lors d'un audit SOC 2 de type II, et l'autorisation FedRAMP s'accompagne de ses propres exigences en matière de surveillance continue et de correction des failles. La prolongation du support ne garantit pas à elle seule la conformité d'une organisation, mais elle assure un flux continu de correctifs, ce qui permet de respecter les engagements en matière de gestion des vulnérabilités pendant que la migration est encore en cours de planification.
Le problème de l'arborescence des dépendances
Commons Collections en soi n'est pas le Tangle. L'artefact 4.6.0 occupe très peu d'espace, avec commons-codec 1.22.1 comme seule dépendance de compilation facultative, et tout le reste étant limité aux tests ; sa contribution au graphe des dépendances d'exécution d'un utilisateur est donc minime.
Le problème vient du côté des utilisateurs. Les serveurs d'applications l'intègrent, les outils de développement le fournissent, et les frameworks hérités l'exigent. Exécuter mvn dependency:tree si vous l'utilisez sur une application Java d'entreprise bien établie, vous pourriez bien trouver dans les résultats un ancien fichier JAR « commons-collections » de version 3.x, importé par un composant dont les responsables n'ont plus mis à jour les déclarations de dépendances depuis très longtemps. Chaque copie vulnérable présente dans ce graphe peut devenir un résultat, car les scanners parcourent l’ensemble du graphe plutôt que de s’arrêter à ce que vous avez déclaré. Le fait qu’une copie donnée soit prise en compte dépend de la version, puisque les versions 3.0 à 3.2.1 se situent dans la plage concernée, tandis que la version 3.2.2 intègre déjà la mesure corrective d’Apache.
C'est ce qui rend la fin de vie (EOL) d'Apache Commons Collections délicate. Il s'agit moins d'un problème lié à la version de la bibliothèque que d'un problème de portée et de visibilité ; et lorsque le composant qui utilise l'ancien fichier JAR n'est lui-même plus maintenu, l'application d'un correctif à la bibliothèque là où elle se trouve réellement permet d'éviter le risque de compatibilité lié à l'imposition d'une version transitive plus récente dans une chaîne de dépendances que personne ne maintient.
Quelles sont vos options (réalistes) ?
Migration vers commons-collections4 4.6.0
La solution durable et écologique consiste à passer de commons-collections:commons-collections à org.apache.commons:commons-collections4 à la version 4.6.0, ce qui vous place sur la branche activement maintenue.
Il ne s'agit toutefois pas d'une simple mise à jour de version. Il s'agit d'un changement de dépendance accompagné de modifications de l'API qui nécessitent de passer en revue toutes les classes qui utilisent cette bibliothèque. Les génériques ont été intégrés partout, les classes obsolètes de la version 3.x ont été supprimées, le Buffer l'interface a été remplacée par java.util.Queue, et les signatures d'utilitaires ont été déplacées. Toutes les importations doivent être déplacées vers l'espace de noms `collections4`, et tout ce qui repose sur le comportement de la version 3.x, en particulier dans le paquet `functors`, nécessite de véritables modifications du code avant de pouvoir être compilé.
Les équipes qui utilisent déjà la version 4.x ont un peu moins de travail, même si cela implique tout de même de consulter les journaux de modifications de chaque version intermédiaire et de tester le processus de mise à niveau, plutôt que de passer à la version suivante à l'aveuglette.
Lorsque Commons Collections est intégré de manière transitive plutôt que directement, le chemin de migration passe par tout ce qui l'intègre. Si ces bibliothèques ne sont elles-mêmes plus maintenues, vous devez alors remplacer les versions transitives et valider vous-même la compatibilité, ce qui est faisable mais ni gratuit ni toujours sans risque.
Remplacer purement et simplement les collections de Commons
Certaines équipes considèrent l'annonce de la fin de vie d'une bibliothèque comme un bon prétexte pour se demander si elles en ont encore réellement besoin. Les alternatives sont désormais vraiment de bonne qualité, notamment Eclipse Collections, les utilitaires de collections de Guava et une bibliothèque standard qui a intégré une grande partie de ce qui avait initialement poussé les développeurs à se tourner vers Commons Collections.
Le remplacer en bloc représente un travail plus important que de le mettre à niveau. Chaque site d'utilisation nécessite un équivalent, les différences de comportement doivent être testées, et tout ce qui repose sur des foncteurs ou des pipelines de transformation nécessite une attention particulière. Pour une base de code qui a accumulé des années d'utilisation, il s'agit d'un projet s'étalant sur plusieurs sprints, et non d'une réponse à un problème identifié mardi dernier.
Assistance illimitée tout au long du cycle de vie par TuxCare
Le programme ELS pour Apache Commons Collections garantit la fourniture continue de correctifs de sécurité pour les versions en fin de vie (EOL) prises en charge, sans vous obliger à effectuer une migration dont votre équipe n’a pas encore défini le périmètre. La couverture inclut actuellement les versions 3.2 et 3.2.1 ; n’hésitez pas à vous renseigner sur les autres versions. Si vous utilisez une version prise en charge, celle-ci reste inchangée, vos workflows existants ne sont pas modifiés et les correctifs continuent d’être fournis à mesure que de nouveaux problèmes apparaissent.
C'est précisément cette lacune que ce produit vise à combler : le délai qui s'écoule entre le moment où une version en fin de vie (EOL) devient un risque dans un rapport et celui où une migration planifiée et testée est effectivement achevée.
Pourquoi précipiter la mise à niveau peut se retourner contre soi
La pression est bien réelle. Les scanners la mettent en évidence, les auditeurs posent des questions sur le plan d'action et les délais de mise en conformité ne sont pas repoussés. Les équipes qui gèrent bien cette situation sont celles qui parviennent à faire la distinction entre la gestion d'un risque et la création d'un nouveau risque.
En quoi consiste réellement la migration ?
Passer de la version 3.x implique de mettre à jour les coordonnées des artefacts partout où la dépendance est déclarée ou gérée de manière centralisée, de réécrire les importations pour le nouvel espace de noms du package, puis de passer en revue les utilisations des collections afin de garantir la sécurité des types et de prendre en compte les modifications de l’API introduites par l’API générifiée de la version 4.x. Les classes supprimées doivent être remplacées ou réécrites. Le code utilisant le paquet de foncteurs de la version 3.x doit être évalué au cas par cas, car une partie de celui-ci se transpose sans problème vers les interfaces fonctionnelles de Java 8, tandis qu’une autre partie nécessite une réécriture spécifique à la conception.
Pour tout ce qui traite des données Java sérialisées, il est indispensable de bien comprendre et de tester, avant la mise en production, la différence entre le modèle 3.2.2 — dans lequel la désérialisation par functor non sécurisée est désactivée par défaut, sauf si une propriété système l'active — et le modèle 4.1, dans lequel ces classes ne sont tout simplement pas sérialisables.
Quels sont les problèmes qui surviennent lors de la compression ?
Les erreurs de compilation, c'est la partie la plus simple, car les API qui ont été renommées ou supprimées se font remarquer immédiatement. Les erreurs intéressantes sont plus discrètes. Les problèmes de compatibilité binaire peuvent se manifester sous la forme de NoSuchMethodError lors de l'exécution, tandis que les recherches réflexives ayant échoué peuvent produire NoSuchMethodException au contraire, et aucune des deux n’est assurée d’être détectée par la seule compilation.
Les changements de comportement sont encore pires. MultiValueMap a été déprécié dans la version 4.1 au profit de la nouvelle version MultiValuedMap interface, BeanMap a été introduit dans la version 4.0, son équivalent ayant été déplacé vers Commons BeanUtils, puis la version 4.6.0 a déclaré l'ensemble obsolète Bag famille au profit de MultiSet. Un code qui repose sur l'ancienne sémantique peut réussir une suite de tests, puis échouer en production face à un cas particulier de données.
Et puis il y a les séquelles. Les correctifs de compatibilité écrits pour respecter une échéance deviennent permanents, et la promesse « on s’en occupera plus tard » se transforme en ticket à la charge de quelqu’un d’autre. Ajoutez à cela le temps d’ingénierie d’urgence, le retard pris sur la feuille de route et les ingénieurs seniors qui déboguent en production au lieu de livrer, et une migration précipitée peut facilement coûter plus cher que l’échéance qu’elle était censée respecter. Le problème n’est pas résolu de cette manière. Il est simplement reporté, à un coût supplémentaire.
Fonctionnement de TuxCare ELS pour Apache Commons Collections
TuxCare compte quinze ans d'expérience dans le domaine des correctifs open source et a fourni plus de 420 000 correctifs pour divers systèmes d'exploitation, environnements d'exécution, frameworks et bibliothèques. ELS pour Apache Commons Collections s'inscrit dans cette même démarche.
Couverture de la chaîne de dépendances incluse
La couverture s'étend à la fois aux dépendances directes et transitives, sans frais supplémentaires. Les analyseurs ne s'arrêtent pas à l'artefact de niveau supérieur ; il en va de même pour l'application des correctifs.
Comment sont fabriqués les écussons ?
Le suivi des CVE s'effectue en continu à partir du NVD, des avis des éditeurs, des avis de sécurité GitHub et d'autres sources. Lorsqu’un élément est détecté, des outils algorithmiques et une automatisation assistée par l’IA aident les ingénieurs à effectuer le backport ; les ingénieurs en sécurité valident ensuite le résultat, et chaque version est soumise à des tests d’intégrité, de fonctionnalité et de régression avant d’être intégrée à un dépôt. Les correctifs sont distribués sous forme signée à partir de dépôts hébergés par TuxCare. Le livre blanc « Open Source Patching Process » fournit tous les détails si vous souhaitez en savoir plus sur le pipeline.
Intégration à votre configuration
Que vous récupériez Commons Collections via Maven ou Gradle, le principal changement consiste à pointer votre build vers le référentiel de TuxCare et à vous assurer que la résolution des dépendances sélectionne bien l'artefact corrigé. Votre pipeline, votre CI/CD et les méthodes de travail de votre équipe restent inchangés.
À quelle vitesse les correctifs sont-ils mis à disposition ?
Les vulnérabilités à risque élevé et critique affectant les versions prises en charge arrivées en fin de vie (EOL), c'est-à-dire celles dont le score CVSS 7.0 est égal ou supérieur à 7,0, doivent être corrigées dans un délai de 14 jours à compter de leur divulgation publique ; ce délai est de 60 jours pour les vulnérabilités à risque moyen et de 90 jours pour celles à faible risque. Le triage des vulnérabilités et l'assistance au dépannage sont assurés 24 heures sur 24, 7 jours sur 7, 365 jours par an.
Visibilité pour les auditeurs
Le outil de suivi des CVE de TuxCare indique quelles vulnérabilités ont été identifiées et corrigées dans l'ensemble des produits pris en charge et de leurs chaînes de dépendances. Cela fournit aux équipes chargées de la sécurité et de la conformité des preuves plus claires des mesures correctives effectivement mises en œuvre qu'un simple résultat de scan à un moment donné.
Ne laissez pas un constat de fin de vie (EOL) se transformer en incident
Une version EOL de Commons Collections ne provoque en soi aucun dysfonctionnement. En revanche, elle vous prive d'une version 3.x en amont maintenue sur laquelle vous pourriez vous rabattre lorsque la prochaine vulnérabilité affectant cette version apparaîtra, ou lorsque des classes toujours présentes dans votre classpath deviendront exploitables dans une chaîne de désérialisation récemment révélée.
Si votre défi consiste à assurer la sécurité d’une ancienne version de Commons Collections pendant que vous préparez la migration, découvrez ce que couvre le service « Endless Lifecycle Support for Open Source Software » de TuxCare pour le reste de votre infrastructure.
