On Thu, Nov 13, 2025 at 4:22 PM Vladimir Sitnikov < [email protected]> wrote:
> I could help with backporting the fix Thank you for offering to help (and putting together https://github.com/apache/commons-lang/compare/LANG_2_6...vlsi:commons-lang:lang-2.6-CVE-2025-48924?expand=1). Sadly part of this discussion is somewhat soured by companies coming with dramatic words and demands without offering help. > however I would need the help of PMC to release 2.6.1 > That's true. Seeing that the last 2.x release was in 2011, it might need some work to be released in today's world. > CVE-2025-48924 impacts commons-lang:2.6, however the clients have > no option to avoid the CVE in their apps. > > The upgrade from commons-lang 2 to 3 requires client code rewrite, and > asking clients to rewrite their code to avoid CVE does not seem right. > While I understand this is currently difficult for many organizations, I expect it will become increasingly important for such organizations to make sure they build the capabilities to perform such essential maintenance. > For instance, I have the following dependency chain: > > +--- io.codearte.gradle.nexus:gradle-nexus-staging-plugin:0.21.2 > \--- org.codehaus.groovy.modules.http-builder:http-builder:0.7.1 > +--- net.sf.json-lib:json-lib:2.3 > +--- commons-lang:commons-lang:2.4 <- CVE-2025-48924 > \--- net.sf.ezmorph:ezmorph:1.0.6 > \--- commons-lang:commons-lang:2.3 -> 2.4 <- > CVE-2025-48924 > > The software in question is somewhat outdated, and migrating to a > completely different stack would take enormous time. > Right: observing that there exists an advisory for this library, you have two options: 1) Analyze whether the problem actually affects your use of the library, and if not tell your tools about that 2) Make sure the dependency is updated In this case it's quite easy to see the problem doesn't affect you: since this is happening in the gradle-nexus-staging-plugin, there should not be any untrusted inputs in the first place, so no risk of DoS - and that's even without the observation by Emmanual that the affected code is never called in this stack. If you don't have the capability to analyze issues and tell your tools about the result, then you'll have to build the capability to update dependencies - and that might indeed include helping out upstream. In this particular case, as Gary mentioned, updating gradle-nexus-staging-plugin to 0.30.0 would be a good start. While I appreciate you 'going upstream' and fixing the issue there, I do have the feeling that it would be more effective to help ezmorph and json-lib move to lang3 than to sink effort in commons-lang 2.x > Would you please consider fixing the CVE and releasing it via 2.6.1? > As far as I understand, backporting the fix would be trivial, and it would > really help for those who still use commons-lang:2.6. AFAICT this would mainly help organizations that do not have the capability to do '1' but *also* don't have the capability to do '2'. Such organizations are in a bad place already, and I'm not sure it's really a net positive to keep enabling such a bad habit. If someone steps forward volunteering to do most of the work for completing a 2.x release I'd reluctantly support that, as I do see the short-term benefit, but I'm not entirely convinced it's the right long-term choice. Kind regards, -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
