Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Commons Collections wird oft transitiv eingebunden, sodass es möglicherweise in Ihrem Build enthalten ist, auch wenn es niemand hinzugefügt hat.
- Das „Functors“-Paket lieferte die Bausteine für die bekanntesten Deserialisierungs-Gadget-Ketten in Java.
- Der Umstieg von 3.x auf 4.x bringt neue Koordinaten, einen neuen Paket-Namespace und gezielte API-Änderungen mit sich.
- ELS für Apache Commons Collections patcht EOL-Versionen und deren Abhängigkeitsketten, während Sie die Umstellung planen.
Wenn „Apache Commons Collections“ irgendwo in Ihrem Java-Abhängigkeitsgraphen vorkommt – was im Enterprise-Java-Bereich häufig der Fall ist –, sollten Sie die Frage nach dem Ende des Lebenszyklus klären, bevor ein Scanner oder ein Prüfer Sie darauf anspricht.
Dies ist die Bibliothek, die hinter einigen der bekanntesten Deserialisierungs-Gadget-Ketten in Java steckt. Nicht, weil Apache eine Hintertür eingebaut hätte, sondern weil eine Handvoll Klassen im „functors“-Paket serialisierbar sind und Reflection nutzen – und irgendwann jemandem aufgefallen ist, was man daraus alles bauen könnte. Die Enthüllungen von 2015 machten aus einer gewöhnlichen Utility-JAR-Datei ein Abhängigkeitsproblem, dem Sicherheitsteams über Anwendungsserver nachgehen mussten, die sie nicht kontrollierten. Dieser Beitrag beleuchtet diese Geschichte, was sie für Teams bedeutet, die noch die ältere Artefakt-Reihe einsetzen, und welche Rolle der erweiterte Support spielt, wenn die Migration nicht in diesem Quartal erfolgt.
Zwei Artefakt-Reihen und warum das wichtig ist
Commons Collections gibt es seit 2001. Es erweitert das Java Collections Framework um Datenstrukturen, Iteratoren, Komparatoren und Transformationsfunktionen, die im JDK nie enthalten waren – und genau deshalb hat es sich überall durchgesetzt. Seine Allgegenwärtigkeit ist auch der Grund dafür, dass seine Sicherheitsgeschichte so schmerzhaft war.
Es gibt zwei Arten von Artefakten, und deren Verwechslung ist die häufigste Ursache für falsche Empfehlungen zur Behebung von Problemen.
Die alte Produktreihe lautet commons-collections:commons-collections, das die gesamte 3.x-Reihe abdeckt und unter der org.apache.commons.collections Paket-Namespace. Apache beschreibt die Versionen 3.2 und 3.2.1 als Java 1.2-kompatibel; 3.2.1 wurde am 15. April 2008 veröffentlicht. Die finale Version, 3.2.2, erschien im November 2015 als Sicherheits- und Bugfix-Release und wurde auf Java 1.3 umgestellt. Die wichtigste Änderung bestand darin, die Deserialisierung der unsicheren Funktorklassen standardmäßig zu deaktivieren, sodass ein Versuch dazu eine UnsupportedOperationException es sei denn, jemand legt ausdrücklich den org.apache.commons.collections.enableUnsafeSerialization Systemeigenschaft auf „true“ setzen. Seitdem wurde in der 3.x-Reihe nichts mehr veröffentlicht.
Die aktuelle Zeile lautet org.apache.commons:commons-collections4, und der Paket-Namespace wurde verschoben nach org.apache.commons.collections4 zusammen damit. Es erhielt eine neue `groupId` und `artifactId`, gerade weil 4.0 nie rückwärtskompatibel sein sollte, und diese Änderung des Namensraums ist der Grund, warum eine 3.x- und eine 4.x-JAR-Datei im selben Klassenpfad liegen können, ohne dass es zu Konflikten kommt. 4.0 wurde am 27. November 2013 veröffentlicht, mit Generics in allen Bereichen und einer Mindestanforderung von Java 5. 4.1 folgte am 28. November 2015 und vollendete die von 3.2.2 begonnene Arbeit, indem „Serializable“ vollständig aus den unsicheren Funktorklassen entfernt wurde, anstatt sie nur einzuschränken. Danach folgten 4.2 am 11. Juli 2018, 4.3 am 21. Dezember 2018, 4.4 am 5. Juli 2019, 4.5.0 am 19. April 2025 und die aktuelle Version, 4.6.0, am 6. August 2026. Die Java-Mindestversion stieg parallel dazu an, von Java 5 bei 4,0 über Java 6 bei 4,1 und Java 7 bei 4,2 bis hin zu Java 8 ab 4,3, einschließlich 4,6.0.
Apache veröffentlicht keine offizielle EOL-Mitteilung für 3.x, daher wird Ihnen niemand eine datierte Ankündigung zur Verfügung stellen, die Sie in ein Ticket einfügen können. Was Sie jedoch klar und deutlich angeben können, ist Folgendes: Seit November 2015 gab es keine 3.x-Veröffentlichung mehr, die gesamte Entwicklung findet bei 4.x statt, und da 3.2.2 die letzte Version dieser Reihe war, sollte niemand mit einem Backport aus dem Upstream für 3.x für ein neu entdecktes Problem rechnen.
Was „Lebensende“ hier eigentlich bedeutet
Keine Korrekturen mehr auf der Quellseite
Für alles, was auf commons-collections:commons-collections, in der Praxis ist die Lage jedoch einfach. Seit Version 3.2.2 gab es keine neue 3.x-Version mehr, und Apache konzentriert sich seit mehr als einem Jahrzehnt auf die 4.x-Reihe.
Ältere 4.x-Versionen befinden sich in einer abgeschwächten Form derselben Situation. Die von Apache veröffentlichten Korrekturen fließen in neuere 4.x-Versionen ein; bei einem Problem, das eine ältere 4.x-Version betrifft, besteht der übliche Behebungsweg daher darin, auf die aktuelle Version umzusteigen.
Die CVE-Geschichte, die viele Leute ein wenig falsch verstehen
An dieser Stelle sollte man genau sein, denn die Scanner-Ausgabe und die CVE-Bezeichnungen stimmen nicht überein, und diese Diskrepanz hat bereits zu vielen unnötigen Besprechungen geführt.
Apache gibt auf seiner eigenen Sicherheitsseite an, dass für das Deserialisierungsproblem aus dem Jahr 2015 keine CVE-ID für die Commons Collections-Bibliothek vergeben wurde. Die von allen zitierten Kennungen beziehen sich auf nachgelagerte Produkte. CVE-2015-7501 wurde für Red Hat JBoss-Produkte gemeldet und CVE-2015-6420 für eine lange Liste von Cisco-Produkten; beide wurden nach CVSS v3 mit 9,8 als „kritisch“ eingestuft und beide werden als mit der Apache Commons Collections-Bibliothek in Zusammenhang stehend beschrieben und nicht als Fehler in dieser Bibliothek. Apaches eigene Seite verweist auf eine dritte, CVE-2015-4852, für den Oracle WebLogic Server.
Der Mechanismus, der ihnen allen zugrunde liegt, ist derselbe. Mehrere Klassen im Paket „functors“ sind serialisierbar und rufen Methoden reflektiv auf, wobei InvokerTransformer Dies ist für einen Angreifer besonders nützlich, da dadurch eine bestimmte Methode mittels Reflection aufgerufen wird. Verbindet man die erforderlichen Gadgets miteinander und übergibt das resultierende Objekt an eine Anwendung, die nicht vertrauenswürdige Eingaben ohne Validierung deserialisiert, während sich diese Klassen im Classpath befinden, kann dies zur Ausführung beliebiger Befehle mit den Berechtigungen des JVM-Prozesses führen. Apache gibt den betroffenen Versionsbereich mit 3.0 bis 4.0 an; das Problem wurde in den Versionen 3.2.2 und 4.1 behoben.
Die Zeitleiste verdeutlicht, warum die Auswirkungen so gravierend waren. Gabriel Lawrence und Chris Frohoff stellten die Technik am 28. Januar 2015 auf der AppSecCali vor. Stephen Breen veröffentlichte am 6. November 2015 funktionierende Angriffsszenarien gegen WebSphere, JBoss, Jenkins, WebLogic und OpenNMS. Apache gibt an, dass sein Sicherheitsteam vor der Veröffentlichung nicht informiert wurde, sodass die Korrekturen erst wenige Wochen nach der vollständigen Veröffentlichung des Exploits bereitgestellt wurden und die Teams feststellten, dass sich die Bibliothek mehrere Ebenen tief in Abhängigkeitsbäumen befand, die sie nicht direkt ändern konnten.
Wenn Ihr Scanner also eine 3.2.1-JAR-Datei unter einer CVE meldet, deren Titel „Cisco“ enthält, handelt es sich nicht um einen Fehlalarm. Diese Sicherheitshinweise verknüpfen anfällige Versionen von Commons Collections mit den nachgelagerten Produkten, in denen sie ausgeliefert wurden, und die GitHub Advisory Database führt dasselbe Problem für das Maven-Artefakt unter der Kennung GHSA-6hgm-866r-3cjv. Der Befund ist echt, auch wenn die CVE den Produktnamen eines anderen Anbieters enthält.
Compliance- und Prüfungsrisiken
Die Anforderung 6.3.3 des PCI DSS v4.0.1 schreibt vor, dass Patches für Schwachstellen, die Ihre Organisation als kritisch einstuft, innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen, während für alle anderen Schwachstellen ein Zeitrahmen gilt, den Sie im Rahmen desselben Risikoeinstufungsprozesses gemäß Anforderung 6.3.1 festlegen. Da der PCI DSS nicht automatisch jeden CVSS 7.0-Befund als kritisch einstuft, hängt die Schwere eines „Commons Collections“-Befunds von Ihrer dokumentierten Einstufung und Ihrem tatsächlichen Risiko ab. Die HIPAA-Sicherheitsvorschrift funktioniert anders: Sie verpflichtet betroffene Einrichtungen und Geschäftspartner dazu, elektronisch gespeicherte geschützte Gesundheitsdaten vor vernünftigerweise zu erwartenden Bedrohungen zu schützen – genau diese Art von offen gefasster Verpflichtung lässt sich im Falle einer ungepatchten, nicht mehr unterstützten Komponente nur schwer erfüllen.
Nicht unterstützte Komponenten können im Rahmen eines SOC-2-Typ-II-Audits zudem Fragen hinsichtlich der Kontrollen im Bereich des Schwachstellenmanagements aufwerfen, und die FedRAMP-Zulassung bringt eigene Erwartungen hinsichtlich der kontinuierlichen Überwachung und Behebung von Schwachstellen mit sich. Ein erweiterter Support allein sorgt zwar nicht dafür, dass ein Unternehmen die Anforderungen erfüllt, gewährleistet jedoch einen kontinuierlichen Patch-Fluss, sodass die Verpflichtungen im Bereich des Schwachstellenmanagements auch während der Planungsphase einer Migration weiterhin erfüllt werden können.
Das Problem des Abhängigkeitsbaums
Commons Collections selbst ist nicht das Tangle. Das Artefakt 4.6.0 hat einen winzigen Speicherbedarf, mit commons-codec 1.22.1 als einzige optionale Kompilierungsabhängigkeit und alles andere auf Tests beschränkt, sodass sein eigener Beitrag zum Laufzeit-Abhängigkeitsgraphen eines Nutzers minimal ist.
Das Problem liegt auf der Verbraucherseite. Anwendungsserver bündeln es, Build-Tools liefern es aus, und ältere Frameworks erfordern es. Ausführen mvn dependency:tree bei einer ausgereiften Java-Unternehmensanwendung, und es kann durchaus sein, dass Sie in der Ausgabe eine alte 3.x-Commons-Collections-JAR-Datei finden, die von einem Projekt eingebunden wurde, dessen Betreuer ihre Abhängigkeitsdeklarationen schon vor sehr langer Zeit zuletzt aktualisiert haben. Jede anfällige Kopie in diesem Graphen kann zu einem Fund werden, da die Scanner den gesamten Graphen durchlaufen, anstatt bei den von Ihnen deklarierten Abhängigkeiten Halt zu machen. Ob eine bestimmte Kopie zählt, hängt von der Version ab, da die Versionen 3.0 bis 3.2.1 im betroffenen Bereich liegen, während 3.2.2 bereits die von Apache bereitgestellte Abhilfemaßnahme enthält.
Genau das macht das EOL von Apache Commons Collections zu einer heiklen Angelegenheit. Es handelt sich weniger um ein Problem mit der Bibliotheksversion als vielmehr um ein Problem der Reichweite und Sichtbarkeit. Und wenn das Projekt, das die alte JAR-Datei einbindet, selbst nicht mehr gepflegt wird, lässt sich das Kompatibilitätsrisiko vermeiden, das entsteht, wenn man eine neuere transitive Version in eine Abhängigkeitskette zwingt, die niemand mehr pflegt, indem man die Bibliothek dort patcht, wo sie tatsächlich eingesetzt wird.
Welche (realistischen) Möglichkeiten haben Sie?
Umstellung auf commons-collections4 4.6.0
Die saubere, langfristige Lösung besteht darin, von commons-collections:commons-collections zu org.apache.commons:commons-collections4 Version 4.6.0, womit Sie auf der aktiv gepflegten Zweiglinie sind.
Es handelt sich jedoch nicht um eine Versionserhöhung. Es ist ein Austausch von Abhängigkeiten mit API-Änderungen, die eine Überprüfung jeder Klasse erfordern, die mit der Bibliothek in Berührung kommt. Generics wurden durchgängig eingeführt, veraltete 3.x-Klassen wurden entfernt, die Buffer Die Schnittstelle wurde ersetzt durch java.util.Queue, und die Utility-Signaturen wurden verschoben. Jeder Import muss in den Namespace „collections4“ verschoben werden, und alles, was auf dem Verhalten von 3.x basiert – insbesondere im Paket „functors“ –, erfordert tatsächliche Codeänderungen, bevor es kompiliert werden kann.
Für Teams, die bereits auf Version 4.x arbeiten, ist der Aufwand geringer, erfordert jedoch nach wie vor, dass sie die Changelogs jeder Zwischenversion lesen und den Upgrade-Pfad testen, anstatt blindlings ein Upgrade durchzuführen.
Wenn „Commons Collections“ nicht direkt, sondern transitiv eingebunden wird, verläuft der Migrationspfad über die Komponente, die es einbindet. Sind diese Bibliotheken selbst nicht mehr gepflegt, müssen Sie die transitiven Versionen überschreiben und die Kompatibilität selbst überprüfen – was zwar machbar, aber weder kostenlos noch immer sicher ist.
Commons-Sammlungen vollständig ersetzen
Manche Teams nutzen die Feststellung, dass eine Bibliothek das Ende ihrer Lebensdauer (EOL) erreicht hat, als guten Vorwand, um zu hinterfragen, ob sie diese Bibliothek überhaupt noch benötigen. Die Alternativen sind mittlerweile wirklich gut, darunter Eclipse Collections, die Collection-Hilfsfunktionen von Guava und eine Standardbibliothek, die einen Großteil dessen übernommen hat, was die Entwickler ursprünglich zu Commons Collections geführt hat.
Eine vollständige Erneuerung ist aufwändiger als eine Aktualisierung. Für jeden Einsatzort muss ein Äquivalent gefunden werden, Verhaltensunterschiede müssen getestet werden, und alles, was auf Funktoren oder Transformationspipelines basiert, erfordert eine individuelle Betrachtung. Bei einer Codebasis, die seit Jahren im Einsatz ist, handelt es sich dabei um ein Projekt, das mehrere Sprints in Anspruch nimmt – und nicht um eine Antwort auf einen Befund, der erst letzten Dienstag festgestellt wurde.
Unbegrenzter Lebenszyklus-Support von TuxCare
ELS für Apache Commons Collections sorgt dafür, dass Sie weiterhin Sicherheitspatches für unterstützte EOL-Versionen erhalten, ohne dass Sie eine Migration durchführen müssen, die Ihr Team noch nicht geplant hat. Derzeit werden die Versionen 3.2 und 3.2.1 abgedeckt – bei anderen Versionen lohnt es sich, nachzufragen. Wenn Sie eine unterstützte Version verwenden, bleibt alles beim Alten, Ihre bestehenden Arbeitsabläufe bleiben unberührt, und Sie erhalten weiterhin Patches, sobald neue Probleme auftreten.
Genau diese Lücke soll das Produkt schließen – den Zeitraum zwischen dem Moment, in dem eine EOL-Version in einem Bericht als Belastung ausgewiesen wird, und dem Moment, in dem eine geplante, getestete Migration tatsächlich abgeschlossen ist.
Warum sich eine überstürzte Aktualisierung rächt
Der Druck ist real. Scanner decken Probleme auf, Prüfer fragen nach dem Plan, und die Fristen für die Einhaltung der Vorschriften verschieben sich nicht. Die Teams, die damit gut umgehen, sind diejenigen, die die Reaktion auf Risiken davon trennen, neue Risiken zu schaffen.
Was die Migration konkret beinhaltet
Der Umstieg von 3.x bedeutet, dass die Artefaktkoordinaten überall dort aktualisiert werden müssen, wo die Abhängigkeit deklariert oder zentral verwaltet wird, dass Importe für den neuen Paket-Namespace umgeschrieben werden müssen und dass anschließend die Verwendungen in den Sammlungen im Hinblick auf die Typsicherheit und die API-Änderungen überprüft werden müssen, die mit der generifizierten 4.x-API einhergingen. Entfernte Klassen müssen ersetzt oder neu geschrieben werden. Code, der das 3.x-Funktoren-Paket verwendet, muss von Fall zu Fall geprüft werden, da sich ein Teil davon nahtlos auf funktionale Schnittstellen von Java 8 abbilden lässt, während ein anderer Teil eine designspezifische Neuprogrammierung erfordert.
Bei allen Anwendungen, die serialisierte Java-Daten verarbeiten, muss der Unterschied zwischen dem Modell 3.2.2 – bei dem die unsichere Deserialisierung von Funktoren standardmäßig deaktiviert ist, sofern sie nicht über eine Systemeigenschaft aktiviert wird – und dem Modell 4.1 – bei dem diese Klassen überhaupt nicht serialisierbar sind – verstanden und getestet werden, bevor die Anwendung in den Produktivbetrieb geht.
Was läuft schief, wenn es komprimiert wird?
Kompilierungsfehler sind der einfache Teil, denn umbenannte oder entfernte APIs machen sich sofort bemerkbar. Die interessanten Fehler sind unauffälliger. Probleme mit der Binärkompatibilität können sich zeigen als NoSuchMethodError zur Laufzeit, während fehlgeschlagene reflektive Suchvorgänge dazu führen können, dass NoSuchMethodException stattdessen, und bei keinem der beiden ist gewährleistet, dass der Fehler allein durch die Kompilierung erkannt wird.
Verhaltensänderungen sind schlimmer. MultiValueMap wurde in Version 4.1 zugunsten der neueren Version MultiValuedMap Schnittstelle, BeanMap wurde in Version 4.0 eingeführt, wobei die entsprechende Funktion in Commons BeanUtils verlagert wurde, und in Version 4.6.0 wurde das Ganze als veraltet markiert Bag Familie zugunsten von MultiSet. Code, der auf der alten Semantik basiert, kann eine Testsuite bestehen und dann in der Produktion bei einer bestimmten Datenstruktur fehlschlagen.
Dann ist da noch der Ballast. Kompatibilitäts-Shims, die nur geschrieben wurden, um einen Termin einzuhalten, werden dauerhaft, und aus „Das räumen wir später auf“ wird das Ticket eines anderen. Rechnet man noch die Zeit für Notfall-Entwicklungsarbeiten, verzögerte Roadmap-Arbeiten und leitende Ingenieure hinzu, die in der Produktion Fehler beheben, anstatt neue Versionen auszuliefern, kann eine überstürzte Migration leicht mehr kosten als die Frist, die sie eigentlich einhalten sollte. Das Problem wird auf diese Weise nicht gelöst. Es wird lediglich zu einem höheren Preis aufgeschoben.
So funktioniert TuxCare ELS für Apache Commons Collections
TuxCare blickt auf fünfzehn Jahre Erfahrung im Bereich Open-Source-Patches zurück und hat mehr als 420.000 Patches für Betriebssysteme, Laufzeitumgebungen, Frameworks und Bibliotheken bereitgestellt. ELS für Apache Commons Collections folgt demselben Ansatz.
Abdeckung der Abhängigkeitskette enthalten
Die Abdeckung erstreckt sich ohne zusätzliche Kosten sowohl auf direkte als auch auf transitive Abhängigkeiten. Die Scanner machen nicht beim Artefakt der obersten Ebene Halt, daher gilt dies auch für die Patches.
Wie die Aufnäher hergestellt werden
Die CVE-Erfassung erfolgt kontinuierlich anhand von NVD, Herstellerhinweisen, GitHub-Sicherheitshinweisen und anderen Quellen. Sobald etwas eintrifft, unterstützen algorithmische Tools und KI-gestützte Automatisierung die Entwickler beim Backport; Sicherheitsingenieure validieren das Ergebnis, und jeder Build durchläuft Integritäts-, Funktions- und Regressionstests, bevor er in ein Repository gelangt. Patches werden signiert aus von TuxCare gehosteten Repositories ausgeliefert, und das Whitepaper „Open Source Patching Process“ enthält alle Details, falls Sie sich die Pipeline ansehen möchten.
In Ihren Aufbau integrieren
Unabhängig davon, ob Sie Commons Collections über Maven oder Gradle beziehen, besteht die wichtigste Änderung darin, Ihren Build auf das Repository von TuxCare zu verweisen und sicherzustellen, dass bei der Abhängigkeitsauflösung das gepatchte Artefakt berücksichtigt wird. Ihre Pipeline, Ihr CI/CD-Prozess und die Arbeitsweise Ihres Teams bleiben dabei unverändert.
Wie schnell Patches eintreffen
Sicherheitslücken mit hohem und kritischem Risiko, die unterstützte EOL-Versionen betreffen – d. h. mit einem CVSS-Wert von 7,0 oder höher –, müssen innerhalb von 14 Tagen nach ihrer öffentlichen Bekanntgabe behoben werden; bei mittlerem Risiko beträgt die Frist 60 Tage und bei geringem Risiko 90 Tage. Die Einstufung von Sicherheitslücken und die Unterstützung bei der Fehlerbehebung erfolgen rund um die Uhr an 365 Tagen im Jahr.
Transparenz für Wirtschaftsprüfer
Der CVE-Tracker von TuxCare zeigt, welche Sicherheitslücken in den unterstützten Produkten und deren Abhängigkeitsketten identifiziert und behoben wurden. Damit erhalten Sicherheits- und Compliance-Teams einen klareren Überblick darüber, was tatsächlich behoben wurde, als dies allein anhand eines zu einem bestimmten Zeitpunkt ermittelten Scanner-Ergebnisses möglich wäre.
Lassen Sie nicht zu, dass eine EOL-Feststellung zu einem Vorfall wird
Eine EOL-Version aus den „Commons Collections“ verursacht an sich keine Probleme. Sie führt jedoch dazu, dass Ihnen keine gepflegte Upstream-Version 3.x mehr als Ausweichmöglichkeit zur Verfügung steht, wenn die nächste Sicherheitslücke in dieser Version bekannt wird oder wenn Klassen, die sich noch in Ihrem Klassenpfad befinden, in einer neu aufgedeckten Deserialisierungs-Kette ausgenutzt werden können.
Wenn Sie vor der Herausforderung stehen, eine ältere Version von Commons Collections sicher zu betreiben, während Sie die Umstellung planen, sollten Sie sich einmal ansehen, was der „Endless Lifecycle Support for Open Source Software“ von TuxCare für den Rest Ihres Stacks abdeckt.
