Poor Man's Security Bulletin: CVE-2025-46392 and ESAPI's AccessControlRules

[kwwall]

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.

[mikehfauzy]

Everything that you said is accurate. I wrote one version of it. I heard there was somebody who worked on it after me, but I don't know where that went. I concur with your recommendation to deprecate the version that I wrote. You are correct that this implementation was never intended for production. It was a pathfinder/example to show how the pieces fit together, so that someone else could implement it for a production system. This implementation was abandoned when Spring Security made it redundant. Mike H Fauzy

…

On Tue, May 13, 2025 at 20:22 Kevin W. Wall ***@***.***> wrote: News flash - GitHub's Dependabot reports a GHAS Security Advisory for Apache Commons Configuration 1.x <https://github.com/advisories/GHSA-pvp8-3xj6-8c6x>. The CVE is also reported in NVD as CVE-2025-46392 <https://nvd.nist.gov/vuln/detail/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 <https://javadoc.io/static/org.owasp.esapi/esapi/2.6.0.0/org/owasp/esapi/AccessControlRule.html>. (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 <https://javadoc.io/static/org.owasp.esapi/esapi/2.6.0.0/org/owasp/esapi/AccessController.html> 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 <#870> and issue #868 <#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 <https://github.com/planetlevel> and @mikehfauzy <https://github.com/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. — Reply to this email directly, view it on GitHub <#877>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AELDJUBS6ROHS777WFXOBZD26KZIPAVCNFSM6AAAAAB5CFLO3CVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGMZDCNBTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>