Text4Shell RCE in Apache Commons Text CVE-2022-42889

In October 2022, security researchers disclosed a critical remote code execution vulnerability in Apache Commons Text, quickly nicknamed "Text4Shell" for its structural resemblance to the Log4Shell disaster from the year before. Tracked as CVE-2022-42889, the flaw lives in how Commons Text's StringSubstitutor class resolves variable interpolation — and under the wrong conditions, it lets an attacker turn a simple string-formatting utility into an arbitrary code execution primitive. The bug carries a CVSSv3 base score of 9.8 (Critical), and while it never triggered the internet-wide exploitation wave that Log4Shell did, it remains a live risk in any Java codebase that hasn't verified its Commons Text version and usage patterns.

What Text4Shell actually is

Apache Commons Text is a widely used utility library for string manipulation in the Java ecosystem — it ships inside countless enterprise applications, either directly or as a transitive dependency pulled in by other libraries. One of its features, StringSubstitutor, performs variable interpolation: it scans a string for patterns like ${prefix:name} and replaces them with a resolved value.

The default configuration registers a set of "lookups" that back those prefixes — things like ${sys:...} for system properties, ${env:...} for environment variables, and ${date:...} for date formatting. The problem is that several of the default lookups are far more dangerous than they look:

• ${script:...} — evaluates the interpolated content as a script using the JVM's javax.script engine (typically Nashorn/JavaScript), enabling arbitrary code execution.
• ${dns:...} — triggers DNS lookups, enabling SSRF and out-of-band interaction.
• ${url:...} — fetches remote content, also enabling SSRF.

If an application takes attacker-controlled input and passes it into StringSubstitutor.replace() (or builds its interpolator via StringSubstitutor.createInterpolator()) using the library's default lookup set, an attacker can supply a payload such as ${script:javascript:java.lang.Runtime.getRuntime().exec('...')} and achieve remote code execution on the host running the application.

This is the core reason the "next Log4Shell" framing, while attention-grabbing, overstated the real-world blast radius: Log4j's vulnerable sink (log message formatting) is reachable from almost any code path that logs user input, whereas Commons Text's vulnerable sink (StringSubstitutor with default lookups fed untrusted data) is a much narrower and less common pattern. Exploitability here is fundamentally a reachability question — the library being present in a dependency tree tells you almost nothing about whether the vulnerable code path is actually invokable with attacker-controlled input.

Affected versions and components

• Vulnerable: Apache Commons Text versions 1.5 through 1.9.
• Fixed in: Apache Commons Text 1.10.0, released in October 2022.

The fix didn't just patch a check — it changed the security posture of the default configuration entirely. Commons Text 1.10.0 reduced the default set of lookups to a much safer subset (excluding script, dns, and url), so applications that upgrade and rely on default behavior are no longer exposed even if they never explicitly reasoned about which lookups they needed. Applications that explicitly re-added the dangerous lookups after upgrading would still need remediation at the usage-pattern level, not just the version-pin level.

Because Commons Text is frequently a transitive dependency — pulled in by frameworks, ORMs, templating libraries, and internal shared libraries — many organizations discovered during triage that they had no direct import of the affected class anywhere in their own code, yet still had the vulnerable JAR sitting several layers deep in their dependency graph.

CVSS, EPSS, and KEV context

• CVSS v3.1: 9.8 (Critical) — reflecting network-exploitable, no-privileges-required, high-impact-to-confidentiality/integrity/availability characteristics if the vulnerable sink is reachable.
• EPSS: Exploit prediction scores spiked in the days immediately following disclosure as researchers published proof-of-concept payloads and scanning activity increased, then settled to a lower steady state as it became clear that mass, unauthenticated exploitation was far less common than initially feared — a pattern typical of vulnerabilities with narrow, application-specific reachability rather than a universal sink.
• CISA KEV: As of this writing, CVE-2022-42889 has not been added to CISA's Known Exploited Vulnerabilities catalog, in contrast to Log4Shell (CVE-2021-44228), which was added almost immediately. That distinction is itself informative: it corroborates that in-the-wild exploitation has been limited relative to the initial hype, largely because triggering the flaw requires an application to funnel untrusted input into a specific, non-default-in-practice code path.

None of this means the CVE should be deprioritized outright — a 9.8 severity finding with a public PoC and active scanning activity still warrants investigation in any environment carrying the affected versions. It means the severity score alone is a poor prioritization signal, and reachability context should drive the actual remediation order.

Timeline

• Mid-October 2022: Alvaro Muñoz of the GitHub Security Lab reports the interpolation issue to the Apache Commons project.
• October 13–17, 2022: Apache Commons Text 1.10.0 is prepared and released, removing the dangerous lookups from the default configuration.
• October 18, 2022: CVE-2022-42889 is publicly disclosed; security media coins the "Text4Shell" name, drawing direct comparisons to Log4Shell.
• Late October 2022: Public proof-of-concept exploits appear; multiple security vendors report internet-wide scanning for vulnerable Commons Text instances, though confirmed successful exploitation in production environments remains comparatively rare.
• November 2022 onward: Enterprise vendors and SaaS providers publish advisories confirming exposure or non-exposure across their product lines, and the broader industry shifts toward emphasizing reachability analysis over blanket "found in SBOM" alerts for this CVE specifically.

Remediation steps

1. Upgrade Apache Commons Text to 1.10.0 or later. This is the definitive fix and should be the target state for every affected artifact, direct or transitive.
2. Inventory transitive exposure. Generate or refresh a Software Bill of Materials (SBOM) across your services to identify every location — direct dependency, transitive dependency, or vendored copy — where Commons Text 1.5–1.9 is present. Don't rely on manual dependency file review; multi-module builds and shaded/uber JARs routinely hide vulnerable copies.
3. Confirm actual usage of the vulnerable sink. Search your codebase and dependency call graphs for calls to StringSubstitutor.replace(), StringSubstitutor.createInterpolator(), and any wrapper libraries that expose interpolation on user-controlled strings. If the class is present but never invoked with untrusted input reaching a default-configured StringSubstitutor, your practical exploitability is materially lower, though you should still upgrade.
4. Restrict lookups explicitly, even after upgrading. If your application has a legitimate need for StringSubstitutor on user-influenced data, construct it with an explicit, minimal StringLookupFactory allowlist rather than relying on defaults — don't re-enable script, dns, or url lookups unless you have a specific, sandboxed reason to.
5. Check your JVM runtime for script engine availability. The script lookup depends on javax.script and typically the Nashorn engine. Nashorn was removed as a standard component starting with JDK 15, so applications running on newer JVMs without an explicit script-engine dependency may have reduced exploitability for that specific vector — verify rather than assume.
6. Deploy detection rules as a stopgap. While patching rolls out, WAF/IDS signatures matching patterns like ${script:, ${dns:, and ${url: on inbound request fields (headers, form fields, JSON bodies) can catch exploitation attempts, though they should not be treated as a substitute for patching.
7. Re-scan and verify. After remediation, re-run dependency and SBOM scans to confirm no vulnerable copies remain anywhere in the build output, including cached artifacts and container base images that may have baked in an old version.

How Safeguard Helps

Text4Shell is a textbook case for why "the vulnerable library is in my SBOM" and "I am actually exploitable" are two different questions — and Safeguard is built to answer the second one, not just the first. Our SBOM generation and ingestion pipeline automatically surfaces every direct and transitive instance of Apache Commons Text across your services, including copies buried in shaded JARs and container layers that manual audits typically miss. From there, our reachability analysis engine traces whether attacker-controlled input can actually reach a vulnerable StringSubstitutor call with default lookups enabled, so your team can immediately separate "patch this quarter" from "patch today" instead of triaging every CVSS-9.8 hit as an emergency. Griffin AI, our security research assistant, can explain the specific call path and interpolation risk in plain language for engineers who aren't steeped in Commons Text internals, cutting investigation time from hours to minutes. When remediation is confirmed necessary, Safeguard can open an auto-fix pull request that bumps the dependency to 1.10.0+ and flags any code that explicitly re-enables dangerous lookups, so the fix ships with the same speed the vulnerability demands.