Ah, I just saw this comment in #872, which tells me that this is unlikely to get approved as-is if there are concerns about commons-configuration2. I'll leave it for now, but I'm happy to try and resolve this in a different way if this is un-mergable as-is.

For what it's worth, I recognize that CVE-2025-48924 is related to ClassUtils.getClass, which isn't used directly in ESAPI. So, this may all be completely unnecessary.
My concern was only increased when I saw that commons-lang was also a dependency of commons-configuration which I wasn't as confident in determining the lack of use in.

Seeing now the reluctance to change commons-configuration, this PR might just be a non-starter.

I'm going to further evaluate commons-configuration and see if ClassUtils.getClass is used at all and if it is not then it seems save to suppress the related CVE if ESAPI is the only source for those transitive dependencies in a project.

It appears that commons-configuration does use ClassUtils.getClass, and it seems possible that someone could run into it if their configuration was set up a certain way. I think this would fall under the same logic as the discussion in #872 about it only being a problem if you're using untrusted configurations.

@sabbott1877 - See the related comment I left in #894 (comment).

I am curious to know when will there be a release for that? We are eagerly awaiting this fix.

@in-fke - If you had bothered to actually READ the comment I suggested (#894 (comment)), then you would be able to surmise "I DON'T KNOW"!

@in-fke - If you had bothered to actually READ the comment I suggested (#894 (comment)), then you would be able to surmise "I DON'T KNOW"!

Sorry If I can't read every comment in both issues. No need for shouting.
I hadn't fully read that comment since I thought it was only about the ability to exclude commons-configuration as discussed earlier, not also commons-lang.

@in-fke - If you had bothered to actually READ the comment I suggested (#894 (comment)), then you would be able to surmise "I DON'T KNOW"!

Sorry If I can't read every comment in both issues. No need for shouting. I hadn't fully read that comment since I thought it was only about the ability to exclude commons-configuration as discussed earlier, not also commons-lang.

We average two releases a year, typically summer and another release before thanksgiving.

CVE-2025-48924

We really need this get off commons-lang 2.6 to commons-lang3, its still compatible on jdk8.

GHSA-j288-q9x7-2f5v (OSSINDEX) suppress

Uncontrolled Recursion vulnerability in Apache Commons Lang.

This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.

The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a
StackOverflowError could cause an application to stop.

Users are recommended to upgrade to version 3.18.0, which fixes the issue.

Sonatype's research suggests that this CVE's details differ from those defined at NVD. See https://ossindex.sonatype.org/vulnerability/CVE-2025-48924 for details
CWE-674 Uncontrolled Recursion

CVSSv2:
Base Score: MEDIUM (6.900000095367432)
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References:
OSSINDEX - [CVE-2025-48924] CWE-674: Uncontrolled Recursion
OSSIndex - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-48924
OSSIndex - GHSA-j288-q9x7-2f5v
Vulnerable Software & Versions (OSSINDEX):

cpe:2.3:a:commons-lang:commons-lang:2.6:::::::*

CVE-2025-48924

We really need this get off commons-lang 2.6 to commons-lang3, its still compatible on jdk8.

ESAPI is BSD licensed. Anything you urgently need can be handled by compiling your own copy! Even if we wanted to cut an emergency release today, we couldn't. We are just now preparing for the migration from OSSRH to Sonatype's Central Repository and the old path of publishing was dead as of July 1. We will be the first OWASP project to make that transition (to our knowledge) but it isn't trivial, in fact the process is barely documented, we (@jeremiahjstacey) has been creating that on our own. Once that migration is complete we can cut releases more frequently if needed but our hands are tied at the moment.