Patchfirst
CVE-2023-50386 Public exploit High · 8.8 EPSS 83.7%

Apache Solr: Backup/Restore APIs allow for deployment of executables in malicious ConfigSets

Apache Software Foundation · Apache Solr

Summary

Apache Solr (affected versions 6.0.0 through 8.11.2 and 9.0.0 before 9.4.1) contains a flaw in its ConfigSets and Backup APIs, where uploaded Java jar and class files can be written by backups to a directory that Solr loads into its ClassPath. An attacker with network access and low-privileged credentials, with no user interaction, can deploy executable code through a malicious ConfigSet, and this is more limited when Solr authorization is enabled, where the impact is restricted to gaining the ability to add libraries via backup permissions.

Official description · CVE.org

Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1. In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API. When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups). If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted. When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries. Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue. In these versions, the following protections have been added: * Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader. * The Backup API restricts saving backups to directories that are used in the ClassLoader.

Breakdown
66.1 / 100
Exploited
Yes, in VulnCheck KEV
Reports
0
Tactics
0/15

First seen exploited 7 months after disclosure. Public exploit code (Metasploit) appeared 15 days after disclosure.

  1. Disclosedday 0
  2. Public exploit codeMetasploit+15 days
  3. First seen exploitedVulnCheck KEV evidence+7 mo

7 fixes in solr-core over 2 years. The latest fix listed for solr-core is 9.10.1.

Fixes in solr-coreMaven package, by fixed version. Earlier and later fixes in the same package, not necessarily the same bug.

  1. 9.3.0CVE-2023-5029015 Jan 2024
  2. 9.3.0CVE-2023-502919 Feb 2024
  3. 9.3.0CVE-2023-502929 Feb 2024
  4. 9.4.1CVE-2023-503869 Feb 2024
  5. 9.8.0CVE-2024-5201227 Jan 2025
  6. 9.8.0CVE-2025-2481427 Jan 2025
  7. 9.10.1CVE-2026-2202221 Jan 2026Latest listed

techniques

No techniques linked

No ATT&CK techniques are linked to this CVE yet. MITRE CTID has not mapped it, and no report passage in the corpus ties it to a technique.

Am I affected? What do I upgrade to?

From GitHub Security Advisories and OSV

1 package in 1 ecosystem. Main package: org.apache.solr:solr-core.

Mavenorg.apache.solr:solr-coreGHSA-37vr-vmg4-jwpw

Upgrade to 9.4.1

Fixes this CVE and 1 other known vulnerability in this package (CVE-2023-50290).

Still affected on this line by CVE-2026-44825 (no fix published).

Set the version to 9.4.1 or later in your pom.xml or build.gradle.

The first fix for CVE-2023-50386.

Affected versions, by release line

If you runUpgrade to
9.0.0 up to 9.4.19.4.1
6.0.0 up to 8.11.38.11.3

“Up to” means the second version is the fix and is not affected.

Check your lockfile against all CVEs

What security researchers reported

Not named in any threat report yet

References

2 links, grouped by NVD tag
↑ ↓ chooseEnter openEsc close