CVE-2023-50292 is a permission flaw in the Apache Solr Schema Designer. It loaded configsets without checking whether they were trusted, which could let unauthenticated users reach external library loading. NVD rates it High (7.5), while Apache rates it critical. The listed fix is Solr 9.3.0.
What's affected
Product: Apache Solr. Affected: 8.10.0 through 8.11.2, and 9.0.0 before 9.3.0. Fixed: 9.3.0, per the Apache announcement. The announcement names no fixed release for the 8.x line, so if you run 8.10.0 through 8.11.2, plan a move to 9.3.0 or later and check the Solr security page for any later 8.x update. The record was published on 9 February 2024.
Severity is a real conflict here. NVD scores it 7.5 High with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, an impact on confidentiality only. The Apache Solr project rates the issue critical in its announcement, and describes it as possibly leading to remote code execution by unauthenticated users. Because the two sources disagree sharply, take the Apache rating as the safe working assumption until you have confirmed your own exposure.
One detail: the second reference listed in the NVD record points to the page for a different Solr CVE, CVE-2023-50298. The announcement for this one is the oss-security post linked in the sources.
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 whether the Schema Designer is reachable. It is part of the Admin UI, so if the UI is open to users who are not authenticated, the exposure is higher. Look at whether your Solr authentication and authorization settings cover the Schema Designer and configset API paths.
What to do now
- Upgrade to Solr 9.3.0 or later. For 8.10.0 through 8.11.2 there is no listed 8.x fix, so plan the move to 9.x.
- Turn on authentication and authorization, so configsets are created by authenticated users and become trusted ones.
- Restrict network access to the Solr admin interface to administrators.
- List the configsets on each node and delete any that you did not create.
- Review Solr logs for configset or Schema Designer activity from unexpected sources.
Why it matters
The record maps this to CWE-732, incorrect permission assignment for a critical resource, and the Apache text also names improper control of dynamically managed code resources. The design point is trust. Solr only allows external library loading for configsets created by authenticated users, which are marked trusted. That rule is what stops unauthenticated users from getting code execution through a configset.
The Schema Designer, added to make schema and configset work easier, loaded configsets without considering that mark. So a configset made by an unauthenticated user could load external libraries when run through the Designer, undoing the protection.
The lesson is general. A security boundary that depends on a flag must be checked by every code path that touches the object, including features added later. KEV is false. The fix is tracked as SOLR-16777. For your open source dependencies more broadly, the free scan at gold.safeguard.sh/scan lists affected versions in your repositories.
Quick check
Does Apache really call this critical?
Yes. Its announcement says severity critical, while NVD scores it 7.5 High. The difference is in how each weighs the possible code execution.
What if I am on Solr 8.x?
The announcement lists 9.3.0 as the fix and gives no 8.x release. Upgrade to 9.x, and watch the Solr security page for 8.x updates.
Sources
Last reviewed: 19 October 2026.
