October 18, 20220 mins read
First things first, let’s be clear that this is NOT a new Log4Shell or Spring4Shell vulnerability. Although it is a remote code execution issue, the impact is neither as severe nor as easily exploitable as the issue in Log4j from December 2021.
Similar to the Log4j issue, the essence of the problem is that you can perform a lookup that can then be misused. However, the Log4shell vulnerability was very easy to exploit — which is not necessarily the case this time. In reality, this issue is very similar to CVE-2022-33980, which we wrote an article about earlier this year.
Explaining the Apache commons-text security issues
In the Apache Commons Text library, you can perform the variable interpolation. This allows you to load properties that can be dynamically evaluated.
The issue is in
StringLookup, which performs the lookups. These lookups are expressions that can resolve dns records, load values from urls, and execute scripts using a JVM script execution engine. These urls and scripts can originate from remote sources triggering remote code executions if untrusted values are used. This is reported as a high severity vulnerability in CVE-2022-42889, and occurs in versions 1.5.x through 1.9.x.
interpolatorStringLookup directly, or via the
StringSubstitutor (which is probably more common), will give the same result.
Remediation for CVE-2022-42889
Let me again emphasize that this is not Log4Shell all over again. You probably don’t use
StringLookup yourself, but you do not know if any of your transitive libraries are. The easiest way to resolve this issue is upgrading to commons-text version 1.10 (or later), which disables the prefixes URL, DNS, and script by default — and making arbitrary code execution impossible via this route.
Scanning with Snyk can help determine if this vulnerability is present in your stack. If detected, update to version 1.10 and run
snyk monitor in the CLI to continue monitoring in production.