I think it's important for users and security teams to have context into how commons-text version 1.10 was updated in order to address CVE-2022-42889. I'll pull heavily from Apache's blog describing this issue.
https://blogs.apache.org/security/entry/cve-2022-42889
Key take aways (emphasis mine):
- If you rely on software that uses a version of commons-text prior to 1.10.0, you are likely still not vulnerable: you are only affected when this software uses the StringSubstitutor API without properly sanitizing any untrusted input.
- If your own software uses commons-text, double-check whether it uses the StringSubstitutor API without properly sanitizing any untrusted input. If so, an update to 1.10.0 could be a quick workaround, but the recommended solution is to also properly validate and sanitize any untrusted input.
More:
"Apache Commons Text is a low-level library for performing various text operations, such as escaping, calculating string differences, and substituting placeholders in the text with values looked up through interpolators. When using the string substitution feature, some of the available interpolators can trigger network access or code execution. This is intended, but it also means an application that includes user input in the string passed to the substitution without properly sanitizing it would allow an attacker to trigger those interpolators."
"For that reason the Apache Commons Text team have decided to update the configuration to be more "secure by default", so that the impact of a failure to validate inputs is mitigated and will not give an attacker access to these interpolators. However, it is still recommended that users treat untrusted input with care."
"We're not currently aware of any applications that pass untrusted input to the substitutor and thus would have been impacted by this problem prior to Apache Commons Text 1.10.0."
What does this mean?
It means that in commons-text 1.10 (the "patched version" of this component, the vulnerable feature is disabled by default. But...what happens if a vendor actually USES that feature (hint: everyone using commons-text uses this feature)? The vendor still MUST sanitize the input in the first place - and that's always been heavily emphasized in the Apache commons documentation - nothing changes there.
We are in the process of finalizing our evaluation of Esri software and will post the results of this analysis. Like all of our security advisories and notifications, you'll find it soon on the front page of the ArcGIS Trust Center.