Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Commons Lang taucht überall in Java-Stacks von Unternehmen auf, sodass eine einzige nicht gepatchte Instanz zu einem flächendeckenden Problem wird.
- Apache stellt Korrekturen in späteren Versionen bereit, anstatt Backport-Zweige zu erstellen, sodass ältere 3.x-Versionen diese nicht mehr erhalten.
- Überstürzte Upgrades gehen schief, weil
commons-lang3tritt in der Regel transitiv auf, und Überraschungen bei der Vermittlung treten zur Laufzeit auf. - Das ELS von TuxCare veröffentlicht gepatchte Versionen älterer Commons Lang-Versionen, sodass Sie während Ihrer Planungsphase weiterhin abgesichert sind.
Commons Lang ist die Abhängigkeit, für die niemand ein Meeting ansetzt. Es stellt dir die Hilfsfunktionen zur Verfügung, die im JDK nie enthalten waren, StringUtils und ClassUtils und NumberUtils und die Builder-Klassen – und tritt dann bei jedem Ihrer Dienste in den Hintergrund. Es lädt zur Laufzeit nichts nach, es kommt so gut wie nie zu Fehlern, und das tut es bereits seit der Veröffentlichung von Commons Lang 1.0 im Jahr 2002, ohne dass es groß auffällt. MvnRepository listet es derzeit an der Spitze der Kategorie „Core Utilities“ auf, mit rund 50.000 Artefakten, die es nutzen – was eine höfliche Art ist, zu sagen, dass es mit ziemlicher Sicherheit irgendwo in Ihrer Build-Datei enthalten ist.
Genau das macht eine veraltete Kopie so ärgerlich. Eine CVE in einer Bibliothek, auf die nur Ihr Abrechnungsdienst zugreift, betrifft lediglich diesen einen Dienst. Eine CVE in commons-lang3 Es taucht überall dort auf, wo Ihr Code darauf zugreift, und in vielen Java-Umgebungen in Unternehmen ist das eine lange Liste von Stellen, für die niemand einen übersichtlichen Überblick hat.
Hier liegt der Haken, der viele Teams überrascht. Apache gibt kein End-of-Life-Datum für einzelne Commons Lang-Versionen bekannt. Es gibt weder eine Auslaufmitteilung noch einen Hinweis darauf, dass die von Ihnen verwendete Version nicht mehr weiterentwickelt wird. Außerdem erhalten Sie keinen gepflegten Zweig für Ihre ältere Version. Sobald also ein Fix in einer neueren Version implementiert wird, gibt es in der Regel keinen Wartungszweig, über den dieser Fix in Ihre Version zurückfließt.
Wie Apache Commons Lang tatsächlich mit Releases umgeht
Das sollte man wissen, bevor man sich deswegen mit einem Scanner in die Haare gerät.
Beginnen wir mit der Aufspaltung. Apache hat Commons Lang 3.0 im Jahr 2011 mit einer bewussten Änderung des Paket-Namespace veröffentlicht. Die 2.x-Reihe befindet sich unter org.apache.commons.lang und 3.x ist zu finden unter org.apache.commons.lang3. Das geschah absichtlich, damit beide Versionen ohne Konflikte im selben Classpath vorhanden sein konnten – was auch der Grund dafür ist, dass viele große Codebasen nach wie vor beide Versionen enthalten. Was den Lebenszyklus betrifft, ist 2.x in jeder wesentlichen Hinsicht abgeschlossen. Die letzte Version war 2.6 im Jahr 2011, die Entwicklung wurde auf die 3.x-Reihe verlagert, und seitdem wurde nichts mehr veröffentlicht. Wer noch mit 2.x arbeitet, nutzt die Software seit 2011 ohne Korrekturen aus dem Upstream.
Die 3.x-Reihe funktioniert anders, als die meisten Leute annehmen. Apache unterhält keine parallelen Long-Term-Support-Zweige, wie es beim JDK der Fall ist. Fehlerbehebungen fließen in die nächste Version ein, und die veröffentlichte Versionshistorie enthält weder einen 3.12.x-Wartungszweig noch einen 3.17.x-Backport-Zweig. Auch wenn Apache also nie offiziell das Ende des Lebenszyklus einer 3.x-Version erklärt hat, ist das praktische Ergebnis dasselbe. Wenn ein Fix in einer neueren Version implementiert wird, wird er nicht in Ihre Version übernommen.
Diese Unterscheidung sollte man richtig treffen, wenn man einen Bericht für einen Wirtschaftsprüfer verfasst. „Für diese Version gibt es keine Upstream-Backport-Version“ ist korrekt und vertretbar. „Offiziell EOL ab einem bestimmten Datum“ ist es nicht, da Apache nie ein solches Datum veröffentlicht hat.
Stand September 2026 ist die neueste Version 3.20.0, die am 12. November 2025 veröffentlicht wurde. Auch die Java-Mindestanforderungen sind wissenswert. Ab Version 3.9 benötigt die Bibliothek Java 8, sodass jede Version ab 3.9 Java 8 oder höher erfordert. Die CI des Projekts läuft derzeit auf den unterstützten LTS-Versionen, also 8, 11, 17, 21 und 25.
| Versionszeile | Paket-Namensraum | Der aktuelle Stand | Neueste Veröffentlichung |
|---|---|---|---|
| Commons Lang 2.x | org.apache.commons.lang |
Die Entwicklung wurde eingestellt, seit 2011 wurden keine Fehlerbehebungen mehr vorgenommen | 2.6 (2011) |
| Commons Lang 3.x, ältere Versionen | org.apache.commons.lang3 |
Wird weiterhin in der Produktion ausgeliefert, aber es gibt keinen Backport-Zweig | k. A., ersetzt |
| Commons Lang 3.x, aktuell | org.apache.commons.lang3 |
Wo die Korrekturen tatsächlich ankommen | 3.20.0 (Nov. 2025) |
Was „EOL“ bei Commons Lang in der Praxis bedeutet
Die Korrekturen erreichen Sie nicht mehr
CVE-2025-48924, das im Juli 2025 bekannt wurde, ist gerade deshalb ein gutes Beispiel, weil es so unscheinbar ist. ClassUtils.getClass() verschachtelte Klassennamen rekursiv aufgelöst, sodass eine ausreichend lange Eingabe den Stack überlasten und einen StackOverflowError. Da es sich hierbei eher um einen Fehler als um eine Ausnahme handelt, wird er von Anwendungen in der Regel nicht behandelt, und der Fehler kann zum Absturz der Anwendung führen. Apache stufte ihn als geringfügig ein, die ADP-Bewertung der CISA lag bei 5,3, und OSS-Fuzz hat ihn entdeckt. Er hätte niemals Schlagzeilen gemacht.
Das Interessante daran ist die Form. Die Empfehlung gilt für „commons-lang“ 2.0 bis 2.6 und jede commons-lang3 Versionen von 3.0 bis einschließlich 3.17.0, die den Upstream-Fix enthalten. Es gibt keine mit dem Upstream-Patch versehene Version 3.17.0. Wenn ein Framework Sie daran bindet, ein Änderungsstopp dies verhindert oder niemand das Budget hat, um eine Hilfsbibliothek über vierzig Dienste hinweg einem Regressionstest zu unterziehen, bleibt dieser Befund auf unbestimmte Zeit in der Ausgabe Ihres Scanners stehen.
Bei der Triage sollte man unbedingt beachten, dass eine neu bekannt gegebene Commons Lang-CVE nicht automatisch Auswirkungen auf die von Ihnen verwendete Version hat. Bei vielen ist dies nicht der Fall. Durch das EOL entfällt lediglich die Möglichkeit, die betroffenen Probleme zu beheben, ohne gleichzeitig die Version zu wechseln.
Wenn es bei der Compliance heikel wird
Die Anforderung 6.3.3 des PCI DSS v4.0.1 schreibt vor, dass Patches für kritische Sicherheitslücken, die im Rahmen Ihres eigenen Prozesses gemäß Anforderung 6.3.1 eingestuft wurden, innerhalb eines Monats nach Veröffentlichung des Patches installiert werden müssen. Für alle anderen Fälle gilt ein Zeitrahmen, den Sie anhand Ihrer eigenen Einschätzung der Kritikalität des Risikos für Ihre Umgebung festlegen. PCI DSS v4.0 hatte dieses einmonatige Zeitfenster auch auf kritische oder hochsicherheitsrelevante Patches angewendet, während v4.0.1 es wieder auf kritische Sicherheitslücken beschränkt hat.
Andere Rahmenwerke sind weniger präskriptiv, und wenn man sie überbewertet, verliert man mit Sicherheit die Aufmerksamkeit eines fachkundigen Lesers. FedRAMP legt Abhilfemaßnahmenfristen je nach Schweregrad fest. Die HIPAA-Sicherheitsvorschrift verlangt von Ihnen, eine Risikoanalyse durchzuführen und bekannte Schwachstellen zu beheben, ohne dabei eine bestimmte Anzahl von Tagen zu nennen. SOC 2 ist kriterienbasiert, daher interessiert es Ihren Prüfer, ob der von Ihnen dokumentierte Patch-Prozess auch tatsächlich der ist, den Sie befolgen. Keines dieser Rahmenwerke macht es einfach, eine Komponente ohne Abhilfemaßnahmen zu verteidigen.
Das besondere Problem bei einer Utility-Bibliothek ist die Geltungsbereichsbestimmung. Ein anfälliger Anwendungsserver befindet sich an einem Ort und führt zu einem Befund. Ein anfälliger commons-lang3 taucht einmal pro Artefakt auf, das diese Schwachstelle enthält, was eine einzelne, noch nicht gepatchte Version zu einer Behebungsmaßnahme macht, an der Teams beteiligt sind, die noch nie miteinander gesprochen haben. Ausgleichsmaßnahmen können Zeit gewinnen und sind oft die richtige Entscheidung, aber ob sie ausreichen, ist eine Frage, die Sie mit Ihrem Prüfer besprechen müssen – und nicht einfach ein Kästchen, das Sie ankreuzen können.
Ihre Optionen nach dem Ende des Supports für Apache Commons Lang
Auf die aktuelle Version aktualisieren
Für Teams, die dazu in der Lage sind, ist der Umstieg auf die aktuelle Version langfristig die richtige Lösung. Apache sorgt für eine relativ hohe Kompatibilität innerhalb der 3.x-Reihe, der „lang3“-Namespace ist über die gesamte Reihe hinweg stabil geblieben, und das Projekt veröffentlicht Berichte zur Binärkompatibilität für seine Releases. In einzelnen Releases werden jedoch weiterhin Funktionen als veraltet markiert und das Verhalten angepasst; betrachten Sie den Umstieg daher eher als Upgrade und nicht als reine Formalität.
Der Haken daran ist, dass es sich selten um eine Änderung von nur einer Zeile handelt. commons-lang3 befindet sich in der Regel in Ihrem Verzeichnisbaum, weil es von einer anderen Komponente dort abgelegt wurde – etwa einer Persistenzschicht, einem Framework oder einer anderen Apache-Commons-Komponente –, und die Version, die Sie letztendlich erhalten, ist diejenige, die von der Maven-Vermittlung ausgewählt wurde. Eine direkte Deklaration mit eigener Versionsangabe in Ihrer pom.xml gewinnt diesen Wettbewerb. Lässt man die Version weg und überlässt es einem übergeordneten POM oder einer importierten Stückliste, diese bereitzustellen, entscheidet stattdessen die verwaltete Version. Eine geschattete Kopie, die in einem fremden Artefakt gebündelt ist, befindet sich vollständig außerhalb der Vermittlung und wird von dieser in keiner Weise berührt. Deshalb mvn dependency:tree -Dverbose ist der erste Befehl, der ausgeführt wird, und nicht der letzte.
Eine andere Utility-Bibliothek einbinden
Manche Teams nutzen diesen Anlass, um die Abhängigkeit insgesamt zu überdenken. Guava deckt einen Großteil desselben Bereichs ab, Spring liefert eigene Hilfsklassen mit, und die Kern-APIs von Java 8+ haben einen beträchtlichen Teil dessen übernommen, wofür Commons Lang ursprünglich gedacht war.
Das ist zwar eine legitime architektonische Entscheidung, aber man sollte sich über die Vor- und Nachteile im Klaren sein. Guava ist ebenfalls eine Abhängigkeit eines Drittanbieters mit einer eigenen CVE-Historie und verfolgt in Bezug auf die Fluktuation einen lockeren Ansatz als Apache Commons, da alles, was als @Beta können sich in jeder Version ändern oder verschwinden. Sie tauschen eine Supply-Chain-Oberfläche gegen eine andere aus, anstatt sie zu entfernen. Die Migration bedeutet außerdem, jeden Aufrufort zu prüfen, ihn umzuschreiben und das Verhalten unter der neuen Lösung zu validieren. Das ist ein Migrationsprojekt, kein Sprint, weshalb es keine geeignete Lösung für eine Abhilfemaßnahme ist, deren Frist bereits im nächsten Monat abläuft.
Behalten Sie Ihre Version bei und patchen Sie sie trotzdem
Die dritte Möglichkeit besteht darin, die Version unverändert zu lassen und Sicherheitsupdates dafür von einer anderen Quelle als dem Upstream-Projekt zu beziehen. Genau das bietet der „Endless Lifecycle Support“ von TuxCare, und es ist die einzige der drei Optionen, bei der Ihr Patch-Status unabhängig von Ihrem Upgrade-Zeitplan ist.
Warum sich eine überstürzte Aktualisierung von Commons Lang als Bumerang erweist
Wenn der Druck kommt – und das geschieht meist eher in Form einer Fehlermeldung des Scanners als einer bewussten Entscheidung –, ist der erste Impuls, die Version zu aktualisieren und sie zu veröffentlichen. Dabei gehen jedoch oft einige Dinge schief.
An erster Stelle steht die Versionsvermittlung. Sobald mehrere Abhängigkeiten unterschiedliche commons-lang3 Versionen: Maven greift auf die nächstgelegene Deklaration im Graphen zurück und nicht auf diejenige, mit der Ihr Code getestet wurde, wobei bei gleicher Tiefe die Reihenfolge der Deklarationen den Ausschlag gibt. Der Build kann weiterhin „grün“ bleiben, während ein NoSuchMethodError, ein NoClassDefFoundError oder es tritt später ein anderer Kompatibilitätsfehler auf, und zwar in einem Codepfad, der bei den Tests übersehen wurde.
Die übliche Reaktion kann die Situation noch verschlimmern. Teams greifen zu <exclusions> in Maven oder durch Abhängigkeitsbeschränkungen in Gradle, um die gewünschte Version zu erzwingen. Dadurch wird zwar der unmittelbare Fehler behoben, aber es entsteht ein Abhängigkeitsgraph, den bei der nächsten Aktualisierung niemand mehr anfassen möchte. Wenn man das unter Zeitdruck bei einer Handvoll Dienste durchführt, hat man ein vorübergehendes Problem gegen ein Wartungsproblem eingetauscht.
Verhaltensabweichungen stellen das versteckte Risiko dar. Die String-, Reflection- und numerischen Hilfsfunktionen von Commons Lang wurden im Laufe zahlreicher Releases verfeinert, und Code, der auf einem Randfall basiert – beispielsweise der Null-Behandlung in einem bestimmten StringUtils Eine Methode kann beispielsweise das Verhalten ändern, ohne die Signatur zu ändern. Bei der Kompilierung treten keine Fehler auf. In der Produktion wird lediglich ein leicht abweichender Wert zurückgegeben.
Nichts davon ist unvermeidlich. Es ist das Ergebnis, wenn die Arbeit in einen Zeitrahmen gezwängt wird, der sich nach einem Compliance-Kalender richtet und nicht nach dem Abhängigkeitsgraphen. Teams, die diese Übergänge reibungslos meistern, tun jedes Mal dieselben drei Dinge: Sie prüfen den Code ordnungsgemäß, sie testen das Verhalten, auf das sich ihr Code tatsächlich stützt, und sie gewährleisten währenddessen eine konstante Sicherheitslage.
Was Ihnen ELS für Apache Commons Lang bietet
TuxCare veröffentlicht seit fünfzehn Jahren Patches für Open-Source-Software und hat im Rahmen seines Portfolios mehr als 420.000 Patches bereitgestellt. Der Commons Lang-Dienst verweist dabei auf die Versionen, bei denen die Nutzer tatsächlich noch feststecken. In der Dokumentation sind derzeit Commons Lang 2.4 und 2.6 im alten Namensraum aufgeführt, außerdem commons-lang3 3.4, 3.8.1, 3.10, 3.11, 3.12.0, 3.14.0, 3.15.0 und 3.17.0.
Technisch gesehen ist es nichts Besonderes, und genau darum geht es ja. Ihre Anmeldedaten werden in Mavens settings.xml, das TuxCare-Repository kommt in Ihr pom.xml, oder die entsprechenden Gradle-Entsprechungen beider Versionen, und Sie verweisen die Abhängigkeit auf die gepflegte Version, sodass aus 2.6 2.6-tuxcare.1. Ihre Aufrufstellen ändern sich nicht, Ihre Build-Tools ändern sich nicht, und die CI löst Artefakte weiterhin so auf wie bisher. Wenn Sie es vorziehen, dass Ihre Builds nicht direkt auf einen Anbieter zugreifen, können Sie den gesamten Vorgang über Ihren eigenen Repository-Manager leiten.
Was den Zeitrahmen betrifft, strebt TuxCare bei hohen und kritischen Schwachstellen mit einem CVSS-Wert von 7,0 oder höher eine Frist von 14 Tagen ab der öffentlichen Bekanntgabe an, bei mittleren Schwachstellen 60 Tage und bei geringen Schwachstellen 90 Tage. Diese Fristen beginnen mit der Bekanntgabe. Bei PCI DSS beginnt die Frist erst mit der Veröffentlichung des Patches; daher ist das 14-Tage-Ziel so ausgelegt, dass Ihnen innerhalb des einmonatigen Zeitfensters noch Spielraum bleibt. Die Anforderung 6.3.3 gilt für kritische Schwachstellen.
Ein Hinweis zur Abhängigkeitsabdeckung, da man hier leicht zu weit gehen kann. commons-lang3 Es hat von Grund auf keinerlei Laufzeitabhängigkeiten, daher gibt es darunter keinen versteckten Baum. Es funktioniert genau umgekehrt. commons-lang3 ist in der Regel die transitive Abhängigkeit, die sich im Baum eines anderen befindet, und genau deshalb bleibt sie unbemerkt. ELS for Libraries deckt direkte und transitive Abhängigkeiten der unterstützten Komponenten ohne zusätzliche Kosten ab, und das ist für Komponenten wie Struts oder Tomcat von enormer Bedeutung. Speziell für Commons Lang liegt der Vorteil darin, dass die Bibliothek, von der alles andere abhängt, endlich über einen gepflegten Build verfügt.
Der Rest ist genau das, was man sich wünscht. Die Pakete enthalten separate OpenPGP-Signaturen und stammen aus einer von TuxCare verwalteten Registry, sodass Authentizität und Integrität nachprüfbar sind und nicht nur vorausgesetzt werden. Es gibt einen CycloneDX-VEX-Feed für die Java-Bibliotheken, einschließlich Commons Lang, der Ihren Scannern und Prüfern mitteilt, welche CVEs tatsächlich auf einen bestimmten Build zutreffen und welche lediglich das Paket erwähnen. SBOMs werden im SPDX- und CycloneDX-Format bereitgestellt, wobei der Java-Feed zusammen mit den Paketen in Nexus veröffentlicht wird. Der Support ist rund um die Uhr an 365 Tagen im Jahr über das TuxCare-Support-Portal für die Triage, Patch-Anfragen und gelegentliche Probleme mit einem Build-System verfügbar.
Eine aktuelle Liste der unterstützten Apache Commons Lang-Versionen finden Sie in der Dokumentation von TuxCare. Um zu überprüfen, welche CVEs in Apache Commons Lang bereits behoben wurden, werfen Sie einen Blick auf den Live-CVE-Tracker.
Lassen Sie nicht zu, dass das Ende der Lebensdauer von Commons Lang Ihre Anwendungen gefährdet
Der Verlust der Upstream-Wartung führt an sich noch zu keinen Problemen. Genau das ist das Problem, und deshalb bleibt es auch so lange von der Roadmap ausgeschlossen, bis ein Scanner oder ein Prüfer es dort einträgt. Ihre Anwendungen laufen weiter, Ihre Tests werden weiterhin bestanden, und das Einzige, was sich geändert hat, ist, dass keine Upstream-Korrekturen für Ihre Version mehr eintreffen.
Ein Upgrade auf die aktuelle Version ist nach wie vor das richtige Ziel. Um dies ordnungsgemäß zu erreichen, muss man den Umfang der Abhängigkeitsprüfung festlegen, das Verhalten testen, auf das sich Ihr Code tatsächlich stützt, und die Arbeiten in einen Release-Kalender einpassen, auf den auch andere Anspruch erheben. Das ist ein Plan, und Pläne brauchen Zeit, die Sie nicht haben, wenn die Frist von jemand anderem vorgegeben wird.
Der erweiterte Support verschafft Ihnen diese Zeit. Er ersetzt das Upgrade nicht, und niemand sollte so tun, als wäre es anders. Er sorgt dafür, dass die von ihm unterstützten Commons Lang-Versionen auf dem neuesten Stand bleiben, bietet Ihnen eine stichhaltige Begründung gegenüber einem Prüfer und ermöglicht es Ihren Entwicklern, ihr Quartal mit der Roadmap zu verbringen, anstatt eine Notfall-Migration der Bibliothek durchführen zu müssen.
Falls Sie sich derzeit mit dem Ende des Supports für Apache Commons Lang beschäftigen, sollten Sie sich den ELS für Apache Commons Lang von TuxCare ansehen, der erweiterten Support für ausgewählte, nicht mehr unterstützte Versionen von Commons Lang und commons-lang3 bietet.
