dbcve.org
SolrApplication · Apache

CVE-2023-50386

HIGH · 8.8 CVSS v3.1 Published 2024-02-09
Fix available
A fix is available. Upgrade to 8.11.3 / 9.4.1 or later.
See remediation →
94/100
Remediation priority · Urgent
High EPSS Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Apache Solr versions 6.0.0-8.11.2 and 9.0.0-9.4.0 allow arbitrary Java code execution through a chain: ConfigSets API accepts jar/class file uploads, LocalFileSystemRepository saves these files during backup to directories within Solr's ClassPath, and the malicious classes become available to all ConfigSets via ClassLoaders, enabling remote code execution.

MitigationUpgrade to Solr 8.11.3 or 9.4.1 which block uploading executable file types to ConfigSets and restrict backup directories from ClassLoader paths. Ensure Authorization is enabled and verify backups are not stored in Solr's ClassPath directories.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
SolrApplication
Affected:>= 6.0.0, < 8.11.3>= 9.0.0, < 9.4.1

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check installed Solr version
    Run 'solr -v' or check the solr-core jar version in the installation directory, or query the Solr API: GET /solr/admin/info/system
    Affected if The version is 6.0.0-8.11.2 or 9.0.0-9.4.0
  2. Verify if authorization is enabled
    Check solr.in.sh or solr.in.cmd for the 'SOLR_AUTH_TYPE' and 'SOLR_AUTHENTICATION_OPTS' variables, or inspect the security.json file in ZooKeeper if used
    Affected if No authentication or authorization is configured, meaning the ConfigSets API is publicly accessible
  3. Check if ConfigSets API accepts uploads
    Attempt a GET request to /solr/admin/configs?action=LIST to see if ConfigSet management is reachable without credentials, or review security configuration for 'configsets' permission
    Affected if The ConfigSets API is accessible without authentication or to untrusted users
  4. Inspect backup repository configuration
    Review solr.xml or the backup collection's configuration for <backup> repository settings; check if LocalFileSystemRepository is explicitly configured
    Affected if LocalFileSystemRepository is used for backups without explicit restrictions on output directories
  5. Check backup output directory location
    Inspect the backup location parameter when creating backups or review solr.xml for the default backup.repository.root directory
    Affected if Backups are stored in directories that are part of Solr's ClassPath (such as lib/ or the Solr home directory)
  6. Verify if jar/class files can be uploaded to ConfigSets
    Attempt to upload a ConfigSet containing .jar or .class files via POST to /solr/admin/configs?action=UPLOAD, or review the ConfigSet upload settings
    Affected if The system accepts ConfigSet uploads containing executable file types (.jar, .class)

A user is affected if their Solr version falls within the vulnerable range AND the ConfigSets API is accessible to untrusted users, AND backups can be stored in ClassPath directories allowing uploaded classes to be loaded.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 8.11.3 / 9.4.1 or later
Fixed in 8.11.39.4.1
Interim mitigation

Upgrade to Solr 8.11.3 or 9.4.1 which block uploading executable file types to ConfigSets and restrict backup directories from ClassLoader paths. Ensure Authorization is enabled and verify backups are not stored in Solr's ClassPath directories.

Recommended fix High confidence

Solr 8.11.3 or Solr 9.4.1 (depending on your major version branch)

  1. 1. Download Apache Solr version 8.11.3 (for 6.x-8.x users) or 9.4.1 (for 9.x users) from the official Apache Solr distribution site.
  2. 2. Stop the running Solr instance.
  3. 3. Backup your existing Solr installation directory, configuration files, and all Solr data/cores.
  4. 4. Replace the existing Solr installation with the new version by extracting the downloaded archive.
  5. 5. Restore your configuration files and data directories from the backup.
  6. 6. Verify that security (Authorization) is enabled in solr.in.sh/solr.in.cfg or solr.xml as recommended in the vulnerability description.
  7. 7. Restart the Solr service and verify all collections are accessible.
Caveat Review the release notes for your target version for any configuration or API changes between your current version and the upgrade version, particularly if upgrading across major version boundaries (e.g., 8.x to 9.x).

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Solr Scoped from the published advisory
  • Consultation4.0 h
  • Implementation4.0 h
  • Testing8.0 h
  • Review / QA3.0 h
19.0 hours of engineering $3,260
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,216.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2023-50386 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2023-50386 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data