On July 6, 2022, NVD published CVE-2022-33980, a CVSS 9.8 critical flaw affecting Apache Commons Configuration versions 2.4 through 2.7. The root cause is unusually specific: the library's variable interpolation engine ships with default Lookup instances registered out of the box, and three of them — "script", "dns", and "url" — do far more than substitute a string. The "script" lookup evaluates expressions through the JVM's script-engine API, meaning a config value like ${script:javascript:...} can execute arbitrary code the moment it's interpolated. The "dns" and "url" lookups perform live DNS resolution and outbound HTTP fetches respectively, turning ordinary config parsing into a network side channel an attacker can trigger and observe. Apache Software Foundation is the vendor of record, and downstream advisories were also issued by NetApp (for SnapCenter) and Debian, both of which shipped the affected library transitively. The fix landed in Commons Configuration 2.8.0, which disables these dangerous lookups by default. The vulnerability class is functionally the same pattern that made Log4Shell (CVE-2021-44228) catastrophic a few months earlier — a lookup syntax that treats configuration data as executable instructions — though Commons Configuration is a distinct library with a distinct fix. This post walks through how the flaw works, why it's dangerous even without a public exploit chain, and how to remediate it.
What exactly does Commons Configuration's interpolation feature do?
Interpolation is Commons Configuration's mechanism for resolving placeholder syntax like ${key} inside config values, similar to variable substitution in a shell script or Log4j's pattern layout. The library registers a set of named Lookup implementations — "sys" for system properties, "env" for environment variables, "const" for Java constants, and so on — and when it encounters ${prefix:name}, it dispatches to the matching lookup to resolve name. This is a legitimate and common feature: letting an ops team write db.host=${env:DB_HOST} in a properties file instead of hardcoding values. The defect NVD documents in CVE-2022-33980 isn't that interpolation exists — it's that three of the default lookups go beyond passive substitution into active code execution and network I/O, and they were enabled by default with no opt-in required. Any application that lets an untrusted party influence a config string that later gets interpolated — a user-supplied properties file, a value pulled from a database, an uploaded YAML file — inherits that risk automatically.
How does the "script" lookup lead to remote code execution?
The "script" lookup, per NVD's description of the flaw, resolves its argument by invoking the Java Scripting API (javax.script), which can execute JavaScript (via Nashorn on older JVMs) or any other registered script engine. In a defensive testing context, this means a string such as ${script:javascript:1+1} doesn't just fail to substitute cleanly — it runs as code and returns the evaluated result. Extend that pattern to a script engine call that shells out or manipulates the file system, and an attacker who controls even one interpolated config value has a path to full remote code execution on the host process, no different in effect from deserialization or template-injection RCE classes. This is precisely why NVD assigned CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H): the vector requires no authentication, no user interaction, and no special access — only that untrusted input reaches an interpolated field. Applications that treat configuration as purely a startup-time, operator-controlled concern often don't realize the same code path is reachable at runtime from request data.
Why do the "dns" and "url" lookups matter if they don't execute code?
The "dns" and "url" lookups are lower severity individually — NVD's CVSS v2.0 score for the overall CVE is 7.5 (partial confidentiality/integrity/availability impact) — but they're still dangerous because they give an attacker a blind, attacker-triggered network primitive from inside your infrastructure. A ${dns:...} interpolation forces the host to perform a DNS lookup against an attacker-chosen domain, and ${url:...} fetches a remote resource — both classic building blocks of SSRF and out-of-band data exfiltration, the same mechanism that made blind XXE and Log4Shell's JNDI lookups useful for exfiltrating environment secrets via DNS even when direct RCE was blocked by a WAF or sandboxed JVM. An attacker who can't get script execution can still use these lookups to confirm a target is vulnerable, map internal network reachability, or leak data byte-by-byte through subdomain encoding — reconnaissance and exfiltration that costs nothing to attempt and leaves minimal signal in application logs.
How is this related to Log4Shell, and is it as widely exploited?
Commons Configuration's interpolation-lookup design is structurally similar to the ${jndi:...} lookup mechanism that made Log4Shell (CVE-2021-44228) one of the most severe vulnerabilities disclosed in the last decade, but the two are unrelated codebases with independent fixes — Commons Configuration is maintained separately from Log4j under the broader Apache Commons umbrella. There is no public evidence of CVE-2022-33980 being exploited at Log4Shell's scale; it did not receive comparable mass internet-scanning campaigns, and it isn't listed in CISA's Known Exploited Vulnerabilities catalog as of this writing. That doesn't make it low priority: Commons Configuration is a widely-used transitive dependency across the Java ecosystem (pulled in by frameworks in the Hadoop, Spring, and Apache ecosystem stacks), meaning many teams carry the vulnerable versions without having chosen the library directly — the same "invisible dependency" pattern that made Log4Shell remediation take organizations months to fully map.
What's the concrete remediation path?
The fix is to upgrade to Apache Commons Configuration 2.8.0 or later, which disables the "script", "dns", and "url" default lookups so interpolation no longer executes code or performs network I/O unless an application explicitly re-registers them. If an immediate upgrade isn't possible, the interim mitigation is to programmatically remove those lookups from your ConfigurationInterpolator instance before parsing any configuration that could contain untrusted input — the same "disable the dangerous default" playbook that Log4j 2.15+ applied to JNDI lookups. Teams should also audit every place a config value can originate from outside the deploy pipeline: uploaded files, database-stored settings, and API-supplied overrides are the realistic injection points, not the properties files an ops engineer hand-writes. Because Commons Configuration frequently arrives as a transitive dependency rather than a direct one, confirming you're actually running 2.4–2.7 requires walking the full dependency tree, not just checking your own pom.xml or build.gradle.
How Safeguard helps
Safeguard's SCA engine matches every resolved Maven and Gradle component — direct or transitive — against CVE and GHSA advisories, so a Commons Configuration 2.4–2.7 pin gets flagged by version the moment it's introduced, without waiting for a manual dependency audit. Because Commons Configuration is exactly the kind of library that arrives nested several levels deep behind a larger framework, Safeguard's deep dependency scanning resolves transitive chains far past where most SCA tools stop, so the finding surfaces with the full path from your project root down to the vulnerable jar rather than as an anonymous line in a flat CVE list. Reachability-aware triage then helps separate "present in the dependency tree" from "your code actually interpolates untrusted strings through it" — a CVE in a library your application never routes attacker-influenced data through is de-prioritized rather than paged as critical, letting teams spend remediation effort on the deployments where CVE-2022-33980 is genuinely reachable.