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: ***@***.***>

[kodstark]

"My answer is nothing" The reality is that esapi is the only dependency which makes app listed on XRAY scan for security violations in spring-boot setup. That's irony as esapi is supposed to solve security issues. And this with the fact of using of library not being updated for 12 years! That's creates a lot of effort to explain to people looking at those reports that using this old library is not really an issue. Isn't worth to rethink of approach of using such old library. (PS esapi 2.6.2.0:jakarta comes with second CVE-2025-48734 in commons-beanutils but this one can be upgraded)

[kodstark]

I should mention that XRAY scans run on binary artifact and thus it would be great if it was explained / documented when commons-configuration can be excluded from the final artifact.

[kwwall]

I should mention that XRAY scans run on binary artifact and thus it would be great if it was explained / documented when commons-configuration can be excluded from the final artifact.

I thought that could be impled from my original Discussion post above. ESAPI only uses Commons Configuration in the 4 classes mentioned above and that those 4 classes are only used with ESAPI's AccessController interface (see the "ESAPI.AccessControl" property in your ESAPI.properties file) so unless you are actually using that reference implementation class, org.owasp.esapi.reference.DefaultAccessController (very highly unlikely), then "yes, it is safe to exclude the commons-configuration jar and replace it with a newer version of your choosing". I thought that could be inferred. If you are going to do that, I would also recommend either commenting out that specific property, or better, set it to something like this:

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

That's just because we haven't verified whether DefaultAccessController all works if that jar is updated. (In case you hadn't heard, we were busy dealing with CVE-2025-5878 in the 2.7.0.0 release.) We could easily test it against our unit tests, but the unit tests for those 4 specific classes I mentioned in this post are a bit on the skimpy side. Anyhow, hope that helps. Obviously, its a more difficult call if we're talking about places where ESAPI is used as a transitive rather than direct dependency, but try it and see. Like I said, since I've started working with ESAPI in 2009, I don't think I've ever seen the AccessController interface anywhere perhaps than the defunct demo, ESAPI Swingset.