Upgrade to use Commons-Lang3

[Zokal84]

Is your feature request related to a problem? Please describe.

It looks like the commons-lang:commons-lang dependency has been deprecated / abandoned in favor of commons-lang:commons-lang3.

The main reason why I'm bringing this is up because I'm seeing vulnerability reports with commons-lang, https://security.snyk.io/vuln/SNYK-JAVA-COMMONSLANG-10734077. Since it's no longer supported by the people that own it, it's a most likely a good idea (and hopefully an easy enough transition) to upgrade to using commons-lang3.

Describe the solution you'd like

I'm just looking to see if there's any chance that ESAPI can upgrade to commons-lang3 to avoid the vulnerability and to be up to date on the library itself.

If you would like for me to create a branch / Merge Request for approval, more than happy to do so.

[dmitry-weirdo]

Strongly recommended. I cannot use the esapi 2.x anymore since the high priority CVEs are reported from its transitive dependencies.
Also the CVEs found are:

• CVE-2025-48734 in commons-beanutils:1.9.4
• CVE-2025-48976 in commons-fileupload:1.5.
• CVE-2025-48924 in commons-lang:1.6.

Please fix this in the next version.

It's pretty ironic that the security assessment library has its own non-safe dependencies that aren't updated for ages.

[sabbott1877]

@dmitry-weirdo it looks like the other two dependencies have already been updated to resolve those CVES.

CVE-2025-48734 in commons-beanutils:1.9.4 is now 1.11.0
CVE-2025-48976 in commons-fileupload:1.5 is now 1.6.0

[sabbott1877]

I probably should have had the initial conversation with myself here, instead of in my PR #895.
But, with further inspection it seems unlikely this is something the team will accept/update due to weighing the risk of breaking user's configurations vs the risk of them hitting the CVEs unless they're running untrusted configurations.

[dmitry-weirdo]

@sabbott1877 Sounds nice, what is the Esapi version for common-beanutils and commons-fileupload updates. I think they're still with the CVEs in esapi:2.7.0.0?

Sorry, you're correct, they are updated in 2.7.0.0, I missed it:

+- org.owasp.esapi:esapi:jar:2.7.0.0:compile
|  +- xom:xom:jar:1.3.9:compile
|  +- commons-beanutils:commons-beanutils:jar:1.11.0:compile
|  |  \- commons-collections:commons-collections:jar:3.2.2:compile
|  +- commons-configuration:commons-configuration:jar:1.10:compile
|  +- commons-lang:commons-lang:jar:2.6:compile
|  +- commons-fileupload:commons-fileupload:jar:1.6.0:compile
|  +- org.apache-extras.beanshell:bsh:jar:2.0b6:compile
|  +- org.owasp.antisamy:antisamy:jar:1.7.8:compile

commons-lang is still 2.6.

[kwwall]

ALL: First, if you haven't already done so, first please read Discussions #748 and #877. If after reading those, you think that you may be affected by this because you are using the toy ESAPI AccessController implementation, just edit your ESAPI.properties file to change:

    ESAPI.AccessControl=org.owasp.esapi.reference.DefaultAccessController

to something like:

    ESAPI.AccessControl=DO_NOT_USE_WITHOUT_INFOSEC_APPROVAL_org.owasp.esapi.reference.DefaultAccessController

If you're not using ESAPI's AccessController interface, you should just be able to exclude current common-lang dependency and include the one one instead as nothing outside of DefaultAccessController (or specifically, the ACR classes updated in PR #895 use that jar).

That's because we still haven't figured out how to change things to deal with GitHub issue #891. (If you really want to help, that's where I think we can use a hand. We're not sure what we changes we need in our pom.xml or in our ~/.m2/settings.xml file. We've had a lot of private email discussions between the core ESAPI team, but haven't really figured it out.

However, as can be seen from the files updated in PR #895, if you have an access control file that can be changed or specified by an external attacker, you have much bigger problems than CVE-2025-48924 and a runaway recursion that may cause a stack overflow resulting in a DoS.

I will try to make more comments on this sometime later, but I have recently been in intense pain from a medical condition that has flared up, so at this point, my health is my top concern.