News flash - GitHub's Dependabot reports a GHAS Security Advisory for Apache Commons Configuration 1.x. The CVE is also reported in NVD as CVE-2025-46392, but the details is pretty sketchy in terms of telling what specific classes and/or methods are affected.

However, the good news is that only these 4 ESAPI classes use classes from that library (package name starting with org.apache.commons.configuration):

• org.owasp.esapi.reference.accesscontrol.policyloader.ACRPolicyFileLoader
• org.owasp.esapi.reference.accesscontrol.policyloader.ACRParameterLoaderHelper
• org.owasp.esapi.reference.accesscontrol.policyloader.ACRParameterLoader
• org.owasp.esapi.reference.accesscontrol.policyloader.DynaBeanACRParameterLoader

And those classes are not really intended to be used directly. These generally only would be used through the ESAPI interface AccessControlRule. (That's what the 'ACR' stands for in the previous 4 listed classes.) And the only way that this AccessControlRule interface comes into play is if you are using ESAPI's AccessController interface, which would normally be done through a call to ESAPI.accessController().

Further good news is, in all my years of my involvement with ESAPI (since August 2009), I have never seen any production use of that code, so it is extremely unlikely that anyone is using it in production code. (That's because it is a "toy" reference model that really doesn't scale to enterprise levels and a second reason is the documentation for it is practically non-existant.) Even better news perhaps if you are using it, it is highly improbably your application uses it in such a manner to where it might allow a potential attacker could to manipulate your ACR policy file (see the sample ESAPI-AccessControlPolicy.xml file for further details and the default configuration file for this). If anyone is doing that...; well, no comment. Plus even if some unnamed intern has done something that questionable and you didn't catch it in a code review or SAST or DAST scan previous to this Dependabot announcement, the CVSSv3 base store for the CVE in question is a Low (2.7 to be specific).

Rather than treat this as a serious report, I think this is more what I see as a race to the bottom of for both SCA tools and the Apache Commons Configuration developers. The former because the SCA tool vendors think they win if they report more vulnerabilities than there competitors and the latter (the Apache devs) because one can't really determine if they are specifically affected without doing a deep dive of all the Commons Configuration source code because the CVE description is almost meaningless aside for their statement "Apache Commons Configuration 1.x is still safe to use in scenario's where you only load trusted configurations", which I believe is the case for ESAPI's AccessController if you in fact use it.

Well, what is the ESAPI team intending to do about this? My answer is nothing. At this point, the only thing that I am willing to do is to deprecate the AccessController and AccessControlRule interfaces, and all their implementing sub-classes as well as deprecating the ESAPI.accessController() method.

That's the only way to unload part of the technical debt. We've already wasted too much time on AccessController (see, for example, PR #870 and issue #868. I do not even intend write up a proper Security Bulletin has I have for a dozen or so other exploitable and non-exploitable vulnerabilities. If you object to the proposed deprecation, then volunteer to write a new GitHub issue and then submit a PR to address it and I'll keep it. But I doubt that will happen because I don't think anyone is really using it in their code.

I will give all of you a while to comment on this discussion, including @planetlevel and @mikehfauzy, because they were the two who implemented this and probably the only two who can give a reasonable defense of why I shouldn't deprecate this to get rid of some of the ESAPI technical debt.