A remote code execution vulnerability in Apache Commons Text surfaced in October 2022, affecting versions 1.5.x through 1.9.x. While not as widespread as Log4Shell, CVE-2022-42889 highlights how transitive dependencies and outdated runtime environments can create security blind spots.
What Happened
Apache Commons Text, a widely-used Java library for string manipulation, contained a vulnerability in its StringSubstitutor component. When applications passed untrusted input to this component, attackers could execute arbitrary code through crafted interpolation strings. The vulnerability allowed three attack vectors: URL-based lookups, DNS queries, and script execution via the Nashorn JavaScript engine.
This issue arose because StringSubstitutor enabled these interpolators by default. Any application using this component to process user-supplied strings became a potential target.
Timeline
Pre-October 2022: Apache Commons Text versions 1.5.x through 1.9.x shipped with URL, DNS, and script interpolators enabled by default.
October 2022: CVE-2022-42889 was disclosed. The Apache team released version 1.10, which disables these interpolators by default.
Post-disclosure: Security teams scrambled to identify whether they used Commons Text directly or as a transitive dependency. Many discovered they lacked visibility into this library's presence in their stack.
Which Controls Failed or Were Missing
Dependency Inventory
Most teams lacked a complete inventory of their transitive dependencies. Commons Text often appeared several layers deep in the dependency tree. Without automated scanning, you wouldn't know it existed in your runtime environment.
Input Validation
Applications that passed untrusted input directly to StringSubstitutor created the attack surface. The control failure was treating a string manipulation library as safe for untrusted data without understanding its interpolation capabilities.
Runtime Hardening
Teams running Java 14 or earlier faced additional risk. The Nashorn scripting engine, available by default in these versions, provided attackers with a straightforward code execution path. Upgrading to Java 15 or later removes Nashorn from the default runtime, eliminating this attack vector.
Vulnerability Monitoring
The gap between disclosure and detection depended on whether your team had continuous dependency scanning in place. Without it, you relied on manual review or waited for a penetration test to surface the issue.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of bespoke and custom software and third-party software components, including transitive dependencies.
Requirement 6.3.3 requires identifying security vulnerabilities using reputable outside sources and assigning a risk ranking to newly discovered vulnerabilities. Continuous monitoring is necessary to meet this requirement.
OWASP Top 10 2021: A06:2021 – Vulnerable and Outdated Components states you're vulnerable if you don't know the versions of all components you use, both client-side and server-side, including nested dependencies.
NIST 800-53 Rev 5 Control SA-15 requires establishing security requirements for software development tools, including dependency management tools and policies for acceptable library versions.
ISO/IEC 27001:2022 Control 8.31 relates indirectly—your testing environment should catch these issues before production deployment, but only if your test environment mirrors production dependencies accurately.
Lessons and Action Items
Implement Automated Dependency Scanning
Deploy a software composition analysis tool that runs on every build. Tools like Snyk and OWASP Dependency-Check can identify both direct and transitive dependencies. Configure them to fail builds when high-severity vulnerabilities appear.
Run periodic scans against your production runtime to catch drift between what you deployed and what's actually running.
Map Your Transitive Dependencies
Generate a complete dependency tree for each application. Most build tools support this:
- Maven:
mvn dependency:tree - Gradle:
gradle dependencies - npm:
npm ls
Review this tree quarterly. Understand why each dependency exists and whether you can eliminate unnecessary ones.
Establish Java Version Standards
If you're still running Java 14 or earlier in production, build a migration plan. The Nashorn removal in Java 15 eliminated an entire class of script injection attacks. Modern Java versions also receive security patches; older versions don't.
Document which Java versions are approved for production use. Make this a deployment gate.
Create an Input Validation Matrix
For every library that processes external input, document what it considers safe. Commons Text assumed you'd only pass trusted strings to StringSubstitutor. That assumption proved wrong.
Build a matrix: library name, input types it accepts, whether it's safe for untrusted data, and what validation you apply before calling it.
Set Up Vulnerability Alerting
Configure your dependency scanner to alert your security team immediately when new CVEs affect your stack. Define SLAs for each severity level:
- Critical: patch within 24 hours
- High: patch within 7 days
- Medium: patch within 30 days
Test Your Rollback Procedures
When Commons Text 1.10 was released, teams needed to upgrade quickly. Some discovered their deployment pipelines couldn't handle emergency patches. Others found that version 1.10 broke existing functionality because they relied on the default interpolators.
Test your ability to deploy emergency dependency updates. Verify that your test suite catches breaking changes from library upgrades.
Document Your Java Runtime
Maintain a configuration management database that tracks which Java version runs in each environment. When vulnerabilities like this emerge, you need to answer "Are we affected?" within minutes.
Include the Java version in your deployment manifests. Make it visible in your monitoring dashboards.
CVE-2022-42889 didn't create the chaos of Log4Shell, but it exposed a fundamental problem: most teams don't know what's running in their production environment. Upgrading to Commons Text version 1.10 fixed this specific vulnerability. Building the controls to detect the next one requires ongoing investment in dependency management and runtime visibility.
