Avoid a new exploit by upgrading to Apache Commons Text 1.10

Published on Nov 22, 2022

As a result of a vulnerability in Apache Commons Text, AKA Text4Shell, an attacker is able to execute arbitrary code on the host machine. CVE-2022-42889, first reported by Alvaro Munoz, is similar to Spring4Shell and Log4Shell, allowing remote code execution (RCE).

CVSSv3 scores the vulnerability as 9.8 with critical severity, as it can be exploited easily and could have a significant impact on the system’s availability and reliability. Since the vulnerability exists in the StringSubstitutor class, which is not a common method but restricted to a specific application, it will not have the same broad impact as Log4Shell, for example.

The Apache Commons Text library is a Java library that provides developers with additional algorithms for manipulating strings.

The StringSubstitutor class replaces and substitutes values within a String.

The above code contains the ${java.version} and ${os.name} that will be replaced by the Java system property. StringSubstitutor uses interpolation, allowing multiple expressions to substitute Strings. An attacker can use the default Interpolator to execute remote code, for example, using the StringSubstitutor.createInterpolator(). method.

Specifically, an attacker will be able to inject malicious code during lookups such as replace() and replaceIn(). The reason for this is that the “dns”, “script”, and “url” lookup keys are interpolated by default rather than conforming to the documentation for the StringLookupFactory class.

By composing the payload with $[prefix:name], a StringLookup is ensured, which allows the code to be executed remotely on the host computer.

It is recommended that developers upgrade to Apache Commons Text 1.10 or later in order to avoid being affected by CVE-2022-42889. In addition, developers can use the checklist below to ensure that their version is not older than 1.10.

The StringSubstitutor class and StringSubstitutor.createInterpolator() method can be found in the source code.

Make sure that the dependency is not included in a Maven or Gradle build and packaging system.

Ensure that deployment machines and containers do not contain this dependency JAR.

Check the container images. In most cases, this can be accomplished by running a container scan.

Check the automated builds. Developer code is often built and sanity-checked by external systems. You should ensure that the binary does not exist in the build system itself and that the output does not contain it.