What is the CVSS score of CVE-2025-24814?

CVE-2025-24814 has a CVSS 3.1 base score of 5.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L. EPSS exploitation probability: 0.8%.

Which versions of Solr are affected by CVE-2025-24814?

Organizations using Core creation should be aware of moderate risk from CVE-2025-24814 rated CVSS 5.5. Exploitation could compromise the security of affected deployments.. A patch is available.

How to fix or mitigate CVE-2025-24814?

Within 30 days: Identify affected systems and apply vendor patches as part of regular patch cycle. Monitor vendor channels for patch availability.

Solr CVE-2025-24814

MEDIUM

Execution with Unnecessary Privileges (CWE-250)

2025-01-27 security@apache.org

Privilege Escalation Apache Solr Red Hat

5.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

5.5 MEDIUM

AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L

Red Hat

4.6 LOW

qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

Required

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

Low

Lifecycle Timeline

Patch released

Mar 31, 2026 - 21:13 nvd

Patch available

Analysis Generated

Mar 28, 2026 - 18:05 vuln.today

CVE Published

Jan 27, 2025 - 09:15 nvd

MEDIUM 5.5

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

27 maven packages depend on org.apache.solr:solr-core (21 direct, 6 indirect)

Ecosystem-wide dependent count for version 9.8.0.

DescriptionCVE.org

Core creation allows users to replace "trusted" configset files with arbitrary configuration

Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or "user-managed" mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual "trusted" configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem. These replacement config files are treated as "trusted" and can use "<lib>" tags to add to Solr's classpath, which an attacker might use to load malicious code as a searchComponent or other plugin.

This issue affects all Apache Solr versions up through Solr 9.7. Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from "FileSystemConfigSetService"). Users are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of "<lib>" tags by default.

AnalysisAI

Core creation allows users to replace "trusted" configset files with arbitrary configuration Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or. Rated medium severity (CVSS 5.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

Technical ContextAI

This vulnerability is classified under CWE-250. Core creation allows users to replace "trusted" configset files with arbitrary configuration Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or "user-managed" mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual "trusted" configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem. These replacement config files are treated as "trusted" and can use "<lib>" tags to add to Solr's classpath, which an attacker might use to load malicious code as a searchComponent or other plugin.7. Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from "FileSystemConfigSetService"). Users are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of "<lib>" tags by default. Affected products include: Apache Solr.

RemediationAI

No vendor patch is available at time of analysis. Monitor vendor advisories for updates. Apply vendor patches when available. Implement network segmentation and monitoring as interim mitigations.