CVE-2025-24814 is a critical security vulnerability in Apache Solr affecting versions up to 9.7. This flaw lets attackers replace supposedly “trusted” configuration files within Solr cores—potentially loading malicious code into your search instance. If you’re running a standalone Solr (not SolrCloud), using the default FileSystemConfigSetService (out-of-the-box config), _and_ you haven’t enabled authentication or authorization, your Solr is at risk.

This post gives a simple breakdown of what CVE-2025-24814 is, how it can be exploited, and what you should do about it.

What’s Going On Under the Hood?

Solr uses "configsets" to manage core configuration files (like solrconfig.xml and schema.xml). These files can contain powerful directives — including <lib> tags that let you add new code (JARs) directly into Solr’s running environment.

The bug: If authentication and authorization (permissions) are turned off (the default for many setups), Solr’s API lets _any user_ create new cores or update existing ones and point at _arbitrary_ configsets living anywhere on the file system. Solr doesn’t check if these config files are “trusted.” If an attacker is able to upload or point Solr to malicious files, they can then use <lib> to load arbitrary Java code.

Step-by-Step Exploit

1. Prepare Malicious JAR – Attacker develops a Java class with a payload (e.g., reverse shell, webshell), compiles it, jars the class (e.g. evil-plugin.jar), and places it somewhere on the filesystem Solr can access (could be via previous exploits, file upload endpoint, or other means).

2. Create Malicious Configset – Attacker crafts a custom solrconfig.xml referencing their jar with e.g:

`xml


_They may also copy a minimal, valid schema.xml into the same directory._

3. Core Creation Request – Attacker sends an HTTP POST to Solr’s Core Admin endpoint with the instanceDir or configSetBaseDir property pointing to their malicious config directory:

`http

POST /solr/admin/cores?action=CREATE&name=evilcore&instanceDir=../../tmp/myevilconfig/

Or, for an existing core, using RELOAD or SETCOREPROPERTY actions.

4. Solr Loads Attacker Code – The <lib> in the attacker’s solrconfig.xml is treated as trusted. Solr loads the JAR, runs attacker’s code.

Result: Attacker achieves Remote Code Execution (RCE) inside Solr’s Java process. They may also persist deeper into the system.

Vulnerable Example

Suppose your Solr server has /tmp/evil-plugin.jar, and a malicious Solr configset at /tmp/evildir/ with:

/tmp/evildir/solrconfig.xml

<config>
   <lib path="/tmp/evil-plugin.jar"/>
   <searchComponent name="backdoor" class="evil.PluginComponent"/>
</config>

And a valid schema.xml in the same directory.

The attacker then issues

curl "http://solr-server:8983/solr/admin/cores?action=CREATE&name=evilcore&instanceDir=/tmp/evildir";

Solr reads the config, loads the JAR, and the attacker’s code runs as “trusted.”

Original References

- Official Apache Solr Security Announcement
- Solr JIRA Issue - SOLR-XXXXX (Example) *(Replace with actual issue when public)*
- Upgrading Solr – Release Notes

- Use Solr’s built-in security

- Solr Authentication/Authorization Guide
- At a minimum, require logins for core/collection management endpoints.

2. Use SolrCloud, Not Standalone

- SolrCloud stores configsets in Zookeeper — not the local filesystem — making this type of abuse much harder.

3. Upgrade to Solr 9.8.+

- Solr 9.8 disables <lib> by default; you must re-enable it manually after review. See Downloading Solr.

It turns any user with admin API access into a Solr “plugin developer.”

- Malicious code can be executed inside your Solr instance (potentially root access depending on user).

If you run standalone Solr in production, patch and enable permissions immediately.

*For more technical details, see the official CVE-2025-24814 advisory or Solr upgrade instructions. Stay safe!*

Timeline

Published on: 01/27/2025 09:15:14 UTC
Last modified on: 02/15/2025 01:15:11 UTC