CVE-2023-50386 is a dangerous file upload flaw in Apache Solr. Configsets accepted jar and class files, and a backup written to a classpath directory could make them loadable. NVD rates it High (8.8), Apache rates it moderate. Upgrade to 8.11.3 or 9.4.1.
What's affected
Product: Apache Solr. Affected: 6.0.0 through 8.11.2, and 9.0.0 before 9.4.1. Fixed: 8.11.3 and 9.4.1, per the Apache announcement on oss-security and the Solr security page. The record was published on 9 February 2024.
Severity differs. NVD scores it 8.8 High with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, which assumes a low privilege account. Apache labels it moderate. The Apache text explains why: when Solr runs in the secure way it strongly recommends, with authorization enabled, the issue is limited to extending the Backup permission with the ability to add libraries.
The conditions matter. The configset API accepted Java jar and class files. Backups use the LocalFileSystemRepository by default. If the backup went to a directory that Solr also uses in its class loaders, those files became available to any configset, trusted or not.
How to check if you're exposed
Find the Solr version on each node. Any of these works.
bin/solr version
curl -s "http://localhost:8983/solr/admin/info/system?wt=json" | grep -i spec-version
The Admin UI also shows the version on its dashboard. Check every node in a SolrCloud cluster, including ones used for testing and any embedded in a product you buy, because vendors often bundle Solr and pin an old release.
If you manage Java projects, Solr can also be a library dependency. Search your build files for the org.apache.solr group. A software composition scan of the repository lists the resolved versions, including transitive ones. The free scan at https://gold.safeguard.sh/scan does that in the browser.
Then check two settings. First, where your backups are written, and whether that path is also on a Solr class path or library directory. Second, who holds the permission to call the configset and backup APIs. Anything that lets a user upload to a configset and trigger a backup is part of the path described by Apache.
What to do now
- Upgrade to Solr 8.11.3 or 9.4.1 or later.
- Turn on authorization if it is off, and give the backup and configset permissions only to administrators.
- Make sure the backup location is not a directory that Solr loads classes or libraries from.
- Review existing configsets for jar or class files that nobody on your team put there.
- Check your backup directories for jar files that do not belong.
Why it matters
The record maps this to CWE-434, unrestricted upload of a file with a dangerous type, and CWE-913, improper control of dynamically managed code resources. Neither piece is alarming alone. Uploading a jar to a configset is allowed in some cases, and saving a backup to disk is normal. The danger is the combination: a backup landing in a path that the Java class loader reads turns stored data into code the server can run.
The fix adds two protections that Apache lists. Users can no longer upload files to a configset that could be executed through a Java class loader, and the Backup API restricts saving backups to directories that are not used by the class loader.
KEV is false, and the announcement does not claim exploitation. The fix is tracked as SOLR-16949. If your Solr runs with authorization on, the practical risk is lower, but upgrading is still straightforward. Use the demo below to see how reachability analysis ranks findings like this.
Try it yourself
Whether code can be reached decides how urgent a Solr finding is. The demo below shows reachability analysis at work.
Click through it at your own pace, or open it full screen.
Quick check
Does this need an account?
The NVD vector says low privileges. Apache says that with authorization enabled the issue is limited to people who already hold the Backup permission.
What exactly do the fixed versions change?
Per Apache: executable files can no longer be uploaded to a configset in a way that a class loader can run, and backups cannot be saved to directories the class loader uses.
Sources
Last reviewed: 19 October 2026.
