Apache Solr: ConfigSets created during a backup restore command are trusted implicitly
Description
Insecure Default Initialization of Resource vulnerability in Apache Solr.
New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name, are created without setting the "trusted" metadata. ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to "trusted" ConfigSets that may not have been created with an Authenticated request. "trusted" ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when the request that uploads the ConfigSet is Authenticated & Authorized.
This issue affects Apache Solr: from 6.6.0 before 8.11.4, from 9.0.0 before 9.7.0. This issue does not affect Solr instances that are secured via Authentication/Authorization.
Users are primarily recommended to use Authentication and Authorization when running Solr. However, upgrading to version 9.7.0, or 8.11.4 will mitigate this issue otherwise.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Apache Solr Restore command creates ConfigSets without the "trusted" flag, allowing unauthenticated users to upload malicious ConfigSets that can load arbitrary code, leading to RCE.
CVE-2024-45217 is an insecure default initialization vulnerability in Apache Solr. When a new ConfigSet is created via the Restore command (which copies a ConfigSet from a backup and assigns it a new name), the "trusted" metadata flag is not set. Solr implicitly treats ConfigSets without this flag as trusted, meaning they can load custom code into classloaders. This flag is intended to be set only for Authenticated and Authorized requests [1][2].
Attackers can exploit this by crafting a malicious backup containing a ConfigSet with a modified solrconfig.xml. Using the Restore API, they can create a new ConfigSet from the backup without proper authentication. The lack of the "trusted" flag allows the ConfigSet to be trusted by default, enabling the loading of arbitrary classes [4]. No authentication is required if Solr is not secured, making unauthenticated network access sufficient for exploitation.
Successful exploitation can lead to remote code execution (RCE) on the Solr server. An attacker can upload a ConfigSet that includes malicious code in solrconfig.xml, which Solr will then load and execute [4]. This compromises the confidentiality, integrity, and availability of the system.
The issue affects Apache Solr versions 6.6.0 through 8.11.3 and 9.0.0 through 9.6.2. Solr instances secured with Authentication and Authorization are not affected. The recommended mitigation is to enable authentication and authorization. For those unable to do so, upgrading to Solr 8.11.4 or 9.7.0 fixes the issue [1][2].
AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
org.apache.solr:solrMaven | >= 6.6.0, < 8.11.4 | 8.11.4 |
org.apache.solr:solrMaven | >= 9.0.0, < 9.7.0 | 9.7.0 |
Affected products
3- osv-coords2 versions
>= 6.6.0, < 8.11.4+ 1 more
- (no CPE)range: >= 6.6.0, < 8.11.4
- (no CPE)range: >= 6.6.0, < 8.11.4
- Apache Software Foundation/Apache Solrv5Range: 6.6.0
Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
6- github.com/advisories/GHSA-h7w9-c5vx-x7j3ghsaADVISORY
- nvd.nist.gov/vuln/detail/CVE-2024-45217ghsaADVISORY
- solr.apache.org/security.htmlghsavendor-advisoryWEB
- svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/webappghsaPACKAGE
- www.openwall.com/lists/oss-security/2024/10/15/9ghsaWEB
- issues.apache.org/jira/browse/SOLR-17418ghsaWEB
News mentions
0No linked articles in our index yet.