CVE-2022-42889 (Text4Shell): Analysis, Detection & Prevention

What is CVE-2022-42889 Vulnerability?

CVE-2022-42889, widely known as "Text4Shell," is a critical remote code execution (RCE) vulnerability found in the popular Apache Commons Text library. If that sounds alarmingly familiar, it's because it shares a similar vibe with the infamous Log4Shell vulnerability. Apache Commons Text is a Java library used for, you guessed it, working with text. The vulnerability stems from how the library handles variable interpolation, which is a fancy way of saying it processes strings that can dynamically pull in and expand other values.

The problem is that some of the default "lookups" (the mechanisms that find and replace these variables) could be tricked into executing code or reaching out to remote servers. If an application uses this library to process any kind of user-supplied input without cleaning it first, an attacker could slip in a malicious payload and potentially take over the whole show. It’s like leaving a backdoor open that lets anyone with the right key run commands on your server.

When was it discovered?

The vulnerability was publicly disclosed on October 13, 2022. The news immediately set the security world on edge, with many fearing a Log4Shell-style meltdown. While Text4Shell is a serious flaw, its real-world impact turned out to be less widespread. Why? Because the vulnerable functions in Apache Commons Text aren't used quite as often as the ones in Log4j. Still, for any application that is using the vulnerable library components, the risk is severe.

Affected products & versions

The core issue resides in the Apache Commons Text library, but its impact extends to any software that bundles these vulnerable versions. This includes a wide range of Java-based applications and services.

Product / Library	Versions Affected	Fixed Versions / Patch Links
Apache Commons Text	1.5 through 1.9	Version 1.10.0 and later. Apache Commons Text Downloads
Various Java Applications	Any application using the affected library versions.	Update the bundled Apache Commons Text library to 1.10.0 or later.
Red Hat Products	Multiple products were affected.	Red Hat Security Advisory
NetApp Products	Certain NetApp services.	NetApp Security Advisory

CVE-2022-42889 technical description

Let’s get into the nitty-gritty. The vulnerability exists in the StringSubstitutor class of Apache Commons Text. This class is designed to find placeholders in a string, like ${prefix:name}, and replace them with a value. The prefix tells the StringSubstitutor which lookup method to use.

The trouble started with three specific default lookups available in versions 1.5 to 1.9:

script: This lookup could execute expressions using the JVM's script execution engine.
dns: This could resolve DNS records.
url: This could fetch content from URLs, including remote servers.

An attacker could craft a malicious string like ${script:javascript:java.lang.Runtime.getRuntime().exec('touch /tmp/pwned')}. If an application passes this string to the StringSubstitutor for processing, the library would dutifully execute the JavaScript code, which in turn runs a system command. Game over. The application just got owned because it trusted unsanitized input.

Tactics, Techniques & Procedures (TTPs)

Attackers looking to exploit Text4Shell typically follow a clear path. The primary technique is a form of Server-Side Template Injection (SSTI). An attacker identifies an input field in a web application that passes data to the vulnerable library.

Common TTPs include:

Payload Injection: Crafting a malicious string with the script, dns, or url prefixes and injecting it into HTTP headers, form fields, or URL parameters.
Remote Code Execution: Using the script prefix to run commands, which could establish a reverse shell, download malware, or start exfiltrating data.
Information Gathering: Leveraging the dns and url prefixes to force the server to make outbound requests to an attacker-controlled domain. This can confirm the vulnerability and leak internal environment details.

Indicators of Compromise

Detecting a Text4Shell attack involves looking for specific patterns and anomalous behavior. Watch out for these IoCs:

Suspicious strings like ${script:...}, ${dns:...}, or ${url:...} in application and web server logs.
Outbound DNS queries or HTTP requests from your application servers to unusual or unknown domains.
The execution of unexpected processes, especially shells (sh, bash, powershell) spawned by your Java application process.
Creation of strange files in temporary directories like /tmp/ or C:\Windows\Temp\.

Known Proof-of-Concepts & Exploits

Soon after its disclosure, several PoCs for CVE-2022-42889 emerged. Security researchers quickly demonstrated how a single malicious string sent to a vulnerable application could lead to RCE. For example, a simple curl command targeting a web app's search parameter could be enough:

curl http://vulnerable-app.com/search?query=$\{script:javascript:java.lang.Runtime.getRuntime().exec('id')}

If the server responds with the output of the id command, it's vulnerable. Public exploits and scanners were released, and while the exploit frenzy wasn't as chaotic as Log4Shell, attackers definitely added Text4Shell to their automated scanning toolkits.

How to detect CVE-2022-42889 vulnerability?

First, identify if your applications use the Apache Commons Text library and which version. You can use a software composition analysis (SCA) tool to scan your codebase and its dependencies.

If you don't have an SCA tool, you'll need to manually check your project's dependencies (e.g., pom.xml for Maven or build.gradle for Gradle) for org.apache.commons:commons-text and check its version. Any version from 1.5 to 1.9 is vulnerable. Vulnerability scanners can also help identify the flaw on running systems.

Impact & risk of CVE-2022-42889 vulnerability

With a CVSS score of 9.8 (Critical), the potential impact is severe. A successful exploit grants an attacker RCE, which is essentially a full system compromise. From there, they can do whatever the application's user permissions allow, including stealing sensitive data, deploying ransomware, or pivoting to other systems on your network.

The main saving grace is that exploiting Text4Shell isn't as trivial as Log4Shell. The application must be specifically using the vulnerable StringSubstitutor methods on untrusted input. But for those that are, the risk is as high as it gets. Don't sleep on this one. ✔️

Mitigation & remediation strategies

Protecting your systems from Text4Shell comes down to a few key actions. No excuses—get these done.

Upgrade Apache Commons Text: This is the most important step. Update the library to version 1.10.0 or later. This version disables the dangerous script, dns, and url lookups by default.
Sanitize All User Input: Never, ever trust user input. Implement strict input validation and sanitization on any data that might be processed by your application. This is a fundamental security practice that would have prevented this issue in the first place.
Use a WAF: A Web Application Firewall can be configured with rules to detect and block malicious payloads containing Text4Shell patterns before they ever reach your application.
Monitor Outbound Traffic: Restrict and monitor outbound network connections from your application servers. This can prevent payloads from calling home and can alert you to a potential compromise if an unexpected connection is attempted.

CVE-2022-42889 FAQs

CVE-2022-42889, or "Text4Shell," is a critical remote code execution vulnerability in the Apache Commons Text library (versions 1.5-1.9). It allows attackers to execute arbitrary code by sending a specially crafted string that the library processes through unsafe default "lookups."

Both are critical Java RCE vulnerabilities, but Text4Shell is generally considered less severe in practice. The vulnerable functions in Apache Commons Text are used less commonly than those in Log4j, making exploitation opportunities rarer. However, the impact of a successful exploit is just as devastating.

Your application is vulnerable if it uses Apache Commons Text versions 1.5 through 1.9 and processes untrusted user input with the StringSubstitutor.createInterpolator() method or other default interpolators. The best way to know for sure is to scan your dependencies.

The primary fix is to upgrade the Apache Commons Text library to version 1.10.0 or newer. In this version, the problematic lookups that enable code execution are disabled by default. You should also implement strong input validation and use a WAF as part of a defense-in-depth strategy.