Upgrade the version of commons-configuration

[smmsit]

Hi,

I'm getting code violation in mend report for my project that the version of commons-configuration being used is very old.
commons-configuration has been relocated to commons-configuration2
Upgrading the version of commons-configuration from 1.10 to 2.11.0 will fix this issue
Is there any plan to upgrade it?

[kwwall]

Our core team discussed this previously in a private email a while back. The bottom line is that continuing to use Apache Commons Configuration 1.10 posed no risk to those using ESAPI as (at the time) there was known unpatched vulnerabilities affecting that version of the library. Furthermore, upgrading to the latest 2.x version (which has a rockier vulnerability than the 1.x versions; e.g., see https://www.cvedetails.com/version-list/45/88810/1/Apache-Commons-Configuration.html) just to make some arbitrary SCA tools to stop squawking is not a compelling reason for us to upgrade. Moving from major release # to another is rarely easy. However, in this case, this is (only) used in complicated feature (AccessController) that is rarely by any ESAPI clients and that no one on the core team has much deep understanding of? Why is that a problem? Because, IIRC, the JUnit tests for that, especially with respect to the ESAPI-AccessControlPolicy.xml policy file, are only used by the classes:

• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/ACRPolicyFileLoader.java
• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/ACRParameterLoaderHelper.java
• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/ACRParameterLoader.java
• src/main/java/org/owasp/esapi/reference/accesscontrol/policyloader/DynaBeanACRParameterLoader.java

are all very minimal. Therefore we are are concerned that changing from Commons Configuration 1.10 to the latest 2.x release could very well break something that some client is using. (While we know that the number of ESAPI clients using AccessController is small, we do not know if it is zero. It might not be, especially in some customized contract work that was done using ESAPI in its early years.)

Neither do I see any official announcement by Apache that Commons Configuration 1.10 has been officially declared end-of-service. We likely would consider that as a compelling reason to move to the latest 2.x release. But, depending the anticipated effort of doing so, we instead might just decide to officially deprecate org.owasp.esapi.AccessController and make the issue disappear that way. (Although that approach would be a process that takes a year or more).

However, I think that you likely are putting too much faith in your SCA tool. I monitor vulnerable dependencies in ESAPI via GitHub Advanced Security Dependabot, Synk SCA, and the OG, OWASP Dependency-Check.

Note that by default, OWASP Dependency-Check does report 2 CVEs for Commons Configuration 1.10. Specifically, CVE-2024-29131 and CVE-2024-29133. However according to the Dependency Check GitHub Issue 6704, these are both false positives, as these both are only applicable to the 2.x releases of Commons Configuration. As a result, we have suppressed them. If Mend SCA flagged either of these 2 CVEs, it is likely making the same mistake.

At any rate, you have not made a compelling case for the ESAPI team to take any action. Perhaps instead, you should simple do a deep-dive examination on your end of your Mend SCA report results and ensure that there is an exploitable path. If there is, report it to us (ideally, via the official means of "reporting a vulnerability"). Alternately, you could simply set the value of your ESAPI.properties file for the property ESAPI.AccessControl to the name of some non-existent fully-qualified-classname (e.g., "com.yourcompany.NoSuchClass") and then if you were to accidentally call ESAPI.accessController() you would get an exception before there was any opportunity for anyone to exploit any vulnerability in Apache Commons Configuration 1.10 via ESAPI. Still another option is to have your build file (pom.xml, build.gradle, etc.) exclude the trahsitive dependency, commons-configuration:commons-configuration:1.10 and to instead use org.apache.commons:commons-configuration2:2.11.0. (That should work fine if aren't using ESAPI's AccessController interface.

Just so you know, contrary to popular opinion of SCA tool vendors, that absence of activity on a given branch does not necessarily mean that that branch is past end-of-life or no longer supported. SCA tools generally don't concern themselves with false positives either. I will give you an opportunity to reply and make a compelling case, but this is not something that we are likely to spend some time fixing. (If it weren't for scarce JUnit tests for this, I would just suggested to you to just make a PR for this, but given that that likely would be a substantial effort on your part I didn't wish to mislead you with regards to effort. I doubt you want to take that path; however, if that interests you, let's discuss it here.) But the core ESAPI team's opinion likely will be we see not reason to address this just to get a single SCA tool to stop squawking. To us, that would be setting a very poor precedent.

[picsouds]

@kwwall, i agree with you, however I pushed a pull request with org.apache.commons:commons-configuration2 which maintains compatibility especially for ACRParameterLoaderHelper.

[in-fke]

Maybe such a low-level lib should not depend on commons-configuration at all (neither commons-configuration nor commons-configuration2). Or it should contain optional depependencies to provide load mechanisms that can be chosen / externalized.

[jeremiahjstacey]

@in-fke Thanks for the input. The next time the project undergoes a major refactor we'll be sure to consider it. Until then, maven provides the ability to exclude transitive dependencies from projects. As long as you're not leveraging the classes in the ACR components that Kevin outlined above, there should be no harm in using maven to optionally exclude that transitive dependency in your project.
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

At that point where you know you're not using the ACR classes it would seem like an exercise simply to change a number in a report. Identifying content as a "non-executable path" has always been a good conversation in my experience, and often results in a better shared understanding of a baseline, with no additional modifications or effort required.

[Matt-Spence]

Howdy! On 5/9/2025 CVE-2025-46392 was published detailing uncontrolled resource consumptions vulnerabilities in commons-configuration 1.X for certain configurations. I note that the CVE says that 1.x is still safe when loading trusted configurations, so I doubt the answer has changed but thought I would inquire as to whether there are now any plans to upgrade the dependency?

[jeremiahjstacey]

@Matt-Spence, thank you for bringing up the newer CVE. I don't know that the team has discussed this yet.

Based on the context of the NVD link, I do not believe the ESAPI library is impacted by this item:

The Apache Commons Configuration team does not intend to fix these issues in 1.x. Apache Commons Configuration 1.x is still safe to use in scenario's where you only load trusted configurations

The only loading performed by the ESAPI Library is from the ACRPolicyFileLoader class. The targeted file is "ESAPI-AccessControlPolicy.xml", which must exist on the path of the client application as configured by application maintainers. I believe that this qualifies as "loading trusted configurations".

If the library exposed an API to allow external actors to arbitrarily load files into the running context I believe we would need to re-assess. To the best of my current understanding the library only loads trusted configurations and CVE-2025-46392 does not pose a concern to the security of the artifact or its use.

We all agree that maintaining the latest dependencies is good practice and should be a goal of any project. The problem that we're faced with is the deficit of tests to ensure we're maintaining capability as part of the upgrade. The most effective way for use to move forward would be to increase testing around the ACR classes so that when the update is applied we can increase confidence that there is no break in capability.

[kwwall]

@Matt-Spence,

Jeremiah wrote:

The only loading performed by the ESAPI Library is from the ACRPolicyFileLoader class. The targeted file is "ESAPI-AccessControlPolicy.xml", which must exist on the path of the client application as configured by application maintainers. I believe that this qualifies as "loading trusted configurations".

@jeremiahjstacey is absolutely right. In fact, I dismissed the GHAS Dependabot issue 17 yesterday for that very reason.

Also, there is GitHub Discussion #877 that goes into more detail about this general issue.

The way that we are intending to "fix" both of these CVEs is by deprecating ESAPI's default AccesController and then changing the default configuration of the ESAPI.properties file so that it not enabled by default. We do not see fix to keep patching an ESAPI component that is more of a PoC example of the AccessController interface than it is an enterprise-ready implementation. Is started working on ESAPI in August 2009 and since then I am not aware of a single person who has every used the org.owasp.esapi.reference.DefaultAccessController class in a production environment. (If may have been used in the old ESAPI Swingset demo, but that was hardly an enterprise scale application.) If someone comes up to me and said we absolutely need it and are willing to give money to OWASP for supporting it, then perhaps we might consider it. But there's only 3 of us and we don't time to chase down all vulnerabilities arising for dependencies especially when/if it involves rewriting code. And at this point, I don't want to entertain PRs for fixes for components that there is no evidence of anyone ever using. I'd prefer to take a torch and burn it to the ground. Because deleted code is not exploitable code and it no one uses it, why keep it around? (We plan to do several deprecations in the not too distant future, but until then, disable it yourself by making a change something like this in your ESAPI.properties file from:

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

to

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