What Happened
CVE-2022-33980 allowed attackers to execute arbitrary code through Apache Commons Configuration's string interpolation feature. The vulnerability affected versions 2.4 through 2.7 and stemmed from how the library processed configuration values containing special prefixes like script:, dns:, and url:.
When an application parsed a configuration file with a value like ${script:javascript:java.lang.Runtime.getRuntime().exec('malicious_command')}, the library would execute the embedded script instead of treating it as a string. No authentication required. No special privileges needed. Just control over a configuration file—something attackers often gain through directory traversal, file upload vulnerabilities, or compromised CI/CD pipelines.
The impact was straightforward: remote code execution with the privileges of the application process. For applications running as root or with database credentials, this meant full system compromise.
Timeline
The vulnerability existed in the codebase from version 2.4 onward. Apache Commons Configuration 2.8, released in response to CVE-2022-33980, disabled the script:, dns:, and url: prefixes by default. Organizations running Java 15 or later had partial protection because the Nashorn script engine—the component that actually executed the JavaScript payloads—was removed from the default JDK distribution.
Teams running Java 8 faced the worst exposure. Nashorn shipped by default in Java 8, meaning any application on that runtime could execute the payload without additional dependencies.
Which Controls Failed
Dependency Management
Most organizations don't inventory their transitive dependencies. Apache Commons Configuration rarely appears as a direct dependency in application manifests. Instead, it enters through frameworks like Apache Camel, Spring Boot starters, or custom internal libraries. Your pom.xml might show 30 direct dependencies, but your runtime classpath includes 200 libraries—and you're responsible for all of them.
The teams that discovered this vulnerability in production failed to maintain a software bill of materials (SBOM). They couldn't answer "are we running Commons Configuration 2.6?" without manually inspecting every application.
Input Validation at Configuration Boundaries
Configuration files occupy a dangerous middle ground in security thinking. They're not user input, so teams skip validation. They're not code, so they bypass code review. But they're parsed and interpreted at runtime, making them an execution vector.
The vulnerable applications treated configuration files as trusted data. No sanitization. No allowlisting of interpolation patterns. If the file contained ${script:...}, the library executed it.
Least Privilege
Applications running with elevated privileges amplified the impact. A compromised configuration file in an application running as www-data is bad. The same file in an application running as root or with AWS IAM credentials attached is catastrophic.
What the Standards Require
OWASP ASVS v4.0.3, Requirement 5.3.3 mandates that applications verify the integrity of configuration files and reject modifications from untrusted sources. The standard explicitly calls out configuration injection as a supply chain risk.
PCI DSS v4.0.1, Requirement 6.3.2 requires organizations to maintain an inventory of bespoke and custom software, including third-party components. You can't patch what you can't enumerate. This requirement exists specifically to prevent the "we didn't know we were running that library" scenario that CVE-2022-33980 exposed.
NIST 800-53 Rev 5, Control SI-10 (Information Input Validation) applies to configuration data just as strictly as it applies to user input. The control requires validation of format, data type, and allowed values. Configuration parsers that execute arbitrary code on specially crafted input fail this control completely.
ISO 27001:2022, Annex A.8.31 (Separation of Development, Test and Production Environments) addresses privilege boundaries. Production applications should run with the minimum privileges required for their function. This control limits the blast radius when vulnerabilities like CVE-2022-33980 are exploited.
Lessons and Action Items
Generate and Monitor Your SBOM
Run mvn dependency:tree or gradle dependencies for every application in your portfolio. Export the output to a structured format. Tools like Snyk, Dependabot, or OWASP Dependency-Check can automate this, but even a quarterly manual audit beats no visibility.
Your SBOM should answer: What version of Commons Configuration are we running? Which applications include it? How did it enter the dependency tree?
Upgrade to Apache Commons Configuration 2.8 or Later
Version 2.8 disables script:, dns:, and url: prefixes by default. If you need these features, you must explicitly enable them—which forces you to acknowledge the risk and implement compensating controls.
If you can't upgrade immediately, add explicit configuration to disable dangerous prefixes in version 2.7:
Parameters params = new Parameters();
FileBasedConfigurationBuilder<XMLConfiguration> builder =
new FileBasedConfigurationBuilder<>(XMLConfiguration.class)
.configure(params.xml()
.setInterpolatorConfigurationParams(
new InterpolatorConfigurationParams()
.setPrefixLookups(Collections.emptyMap())
)
);
Move Off Java 8
Java 8 reached end-of-life for public updates in January 2019. The Nashorn engine's presence in Java 8 makes every string interpolation vulnerability more dangerous. Upgrading to Java 17 (the current LTS release) removes Nashorn and provides five years of security updates.
Treat Configuration Files as Code
Store configuration in version control. Require pull request reviews for changes. Run static analysis on configuration files just as you would on application code. Tools like Checkov and kics can detect suspicious patterns in YAML, XML, and properties files.
Configuration changes should trigger the same deployment pipeline as code changes: review, test environment deployment, automated testing, then production.
Implement Runtime Application Self-Protection (RASP)
For applications you can't immediately patch, RASP tools can detect and block exploitation attempts. A RASP agent monitoring Runtime.exec() calls can alert when a configuration parsing operation triggers process execution—a pattern that should never occur in normal application behavior.
Audit Application Privileges
List every production application and the user account or service principal it runs under. For each one, ask: does this application need these privileges? Can we run it in a container with a read-only filesystem? Can we restrict its network access?
Reducing privileges doesn't prevent exploitation, but it limits what an attacker can do after successful exploitation. An RCE in an application that can't access the database or make outbound network connections is far less valuable than one running with full system access.
