CVE-2023-50298 is an information exposure flaw in Apache Solr streaming expressions. ZooKeeper credentials and ACLs were sent to whatever zkHost a user supplied. NVD rates it High (7.5), while Apache rates it low. Fixed versions are 8.11.3 and 9.4.1, so plan an upgrade to one of them.
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. The record was published on 9 February 2024.
Severity differs. The NVD record scores it 7.5 (High) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. The Apache announcement labels it low. Apache's reasoning is visible in the conditions: the issue applies when the original SolrCloud is set up to use ZooKeeper credentials and ACLs, and the streaming handler needs read permission to be used.
If you do not use ZooKeeper credentials, the practical exposure is small. If you do, treat the credentials as possibly disclosed on any version in range.
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.
Next, check how your Solr cloud talks to ZooKeeper. If your startup options include ZooKeeper credentials or ACL providers, you are in the affected configuration. Also check who has read permission on the streaming handler path, since that is what a caller needs.
What to do now
- Upgrade to Solr 8.11.3 or 9.4.1 or later.
- If ZooKeeper credentials were in use on a version in range, rotate them after upgrading, because they could have been sent to a host you do not control.
- Limit who holds read permission on collections, and consider whether the streaming handler needs to be reachable by every reader.
- Restrict outbound connections from Solr nodes so they can only reach your own ZooKeeper ensemble.
- Review ZooKeeper access logs for connections from unexpected clients.
Why it matters
The record maps this to CWE-200, exposure of sensitive information to an unauthorized actor, and CWE-922, insecure storage of sensitive information. Streaming expressions can pull data from another Solr cloud, using a zkHost parameter to say where that cloud's ZooKeeper is. Solr attached its own ZooKeeper credentials and ACLs to that connection, whatever address was supplied.
The Apache text explains the weakness in terms of trust. A person with read access could stand up a fake ZooKeeper server, point a streaming expression at it, and receive the credentials that Solr sent. The fix limits credentials to zkHost values with the same server address as the original, regardless of the chroot path.
It is a neat example of a confused deputy: the server uses its own authority on behalf of a caller who has less. KEV is false. The fix is tracked as SOLR-17098. Related Solr advisories published the same day include CVE-2023-50386 and CVE-2023-50291.
Try it yourself
A low vendor rating and a high NVD score are common together. The demo shows how an exploitability check helps decide.
Click through it at your own pace, or open it full screen.
Quick check
Why is Apache more relaxed than NVD?
Apache labels it low because it needs a SolrCloud configured with ZooKeeper credentials and a caller with read permission. NVD scores the confidentiality impact without those conditions.
Do I need to rotate credentials?
If ZooKeeper credentials were in use on an affected version, rotating them after the upgrade is the careful choice. The announcement does not say credentials were taken.
Sources
Last reviewed: 19 October 2026.
