Skip to content

Conversation

@ppkarwasz
Copy link
Contributor

This update documents that CVE-2025-48924 is not exploitable in Apache Solr, based on detailed dependency analysis and code path evaluation.

Summary

Although Solr includes the vulnerable Commons Lang library and transitive dependencies such as Commons Text and Commons Configuration, the conditions required for exploitation are not met in any Solr execution paths.

Detailed Analysis

  • The vulnerable Commons Lang functionality is only exercised via Commons Text.

  • According to the Apache Commons Text VEX document, exploitation is limited to the use of StringSubstitutor and StringLookup.

  • These classes are not used directly in Solr’s codebase.

  • Commons Text is only included in two Solr modules:

    • solr-sql
    • solr-hadoop-auth
  • Neither module makes any indirect use of the vulnerable classes, with one exception.

  • The only dependency that uses these classes is Commons Configuration, which is pulled in transitively via Hadoop.

    • Specifically, it is used by the MetricsConfig class in the hadoop-common library.
    • This code path parses only the hadoop-metrics2.properties file, which is considered a trusted configuration file, typically provided by the system administrator.

As a result, the vulnerable expression interpolation logic is never invoked with untrusted input, and Solr does not meet the conditions for exploitability outlined in the Apache Commons Configuration VEX document.

References

This update documents that CVE-2025-48924 is **not exploitable** in Apache Solr, based on detailed dependency analysis and code path evaluation.

### Summary

Although Solr includes the vulnerable **Commons Lang** library and transitive dependencies such as **Commons Text** and **Commons Configuration**, the conditions required for exploitation are **not met** in any Solr execution paths.

### Detailed Analysis

* The vulnerable Commons Lang functionality is only exercised via **Commons Text**.
* According to the [Apache Commons Text VEX document](https://raw.githubusercontent.com/apache/commons-text/refs/heads/master/src/conf/security/VEX.cyclonedx.xml), exploitation is limited to the use of **`StringSubstitutor`** and **`StringLookup`**.
* These classes are **not used directly** in Solr’s codebase.
* Commons Text is only included in two Solr modules:

  * `solr-sql`
  * `solr-hadoop-auth`
* Neither module makes any direct or indirect use of the vulnerable classes.
* The only dependency that uses these classes is **Commons Configuration**, which is pulled in transitively via **Hadoop**.

  * Specifically, it is used by the `MetricsConfig` class in the `hadoop-common` library.
  * This code path parses only the `hadoop-metrics2.properties` file, which is considered a **trusted configuration file**, typically provided by the system administrator.

As a result, the vulnerable expression interpolation logic is **never invoked with untrusted input**, and Solr **does not meet the conditions for exploitability** outlined in the [Apache Commons Configuration VEX document](https://raw.githubusercontent.com/apache/commons-configuration/refs/heads/master/src/conf/security/VEX.cyclonedx.xml).

### References

* [Apache Commons Text VEX document](https://raw.githubusercontent.com/apache/commons-text/refs/heads/master/src/conf/security/VEX.cyclonedx.xml)
* [Apache Commons Configuration VEX document](https://raw.githubusercontent.com/apache/commons-configuration/refs/heads/master/src/conf/security/VEX.cyclonedx.xml)
@vlsi
Copy link

vlsi commented Oct 30, 2025

Could you please add a test for the change?

In other words, you suggest adding a VEX file that says "solr is currently not affected by not_affected".
However, what if someone later adds ClassUtils usage into Solr code? Then the VEX file would be a false claim.

Correct me if I am wrong, but adding such a VEX would require manual review on every release (==one would have to review the full code including the transitive dependencies and reflection to prove ClassUtils can't be called).

@ppkarwasz
Copy link
Contributor Author

The current VEX statement is explicitly scoped to the version range 9.0.0–9.9.0. If a future Solr release includes commons-lang3 version 3.15.0 or higher, the analysis would need to be redone from scratch, since the relevant code paths could have changed.

This assessment was performed manually and verified against version 9.9.0, so it would be more accurate to narrow the statement to that specific release rather than the entire range.

For future releases, the dependency has already been upgraded to commons-lang3:3.18.0 in apache/solr#3549, which fully addresses the underlying CVE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants