CVE-2023-50291: High Credential Leak in Apache Solr

CVE-2023-50291 is an insufficiently protected credentials flaw in Apache Solr. The /admin/info/properties endpoint hid only properties with password in the name, so values such as basicauth or aws.secretKey were shown. NVD rates it High (7.5), Apache rates it moderate. Upgrade to 8.11.3 or 9.3.0.

What's affected

Product: Apache Solr. Affected: 6.0.0 through 8.11.2, and 9.0.0 before 9.3.0. Fixed: 8.11.3 and 9.3.0, per the Apache announcement on the oss-security list and the Solr security page. The record was published on 9 February 2024.

Severity differs between sources. 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 Solr project labels it moderate. The gap comes from access: Apache says the endpoint is protected by the config-read permission, so on a Solr cloud with authorization enabled only logged in users who hold that permission can see the values. NVD scores the case with no authentication, which applies when authorization is off.

Which of these applies to you depends on your configuration, so check both the version and whether authorization is on.

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 your startup options for system properties that carry secrets, such as a basic authentication string or cloud keys passed with a -D flag. Those are the values this issue could reveal.

What to do now

1. Upgrade to Solr 8.11.3 or 9.3.0 or later.
2. If you cannot upgrade yet, Apache gives a workaround: set the system property solr.redaction.system.pattern to a pattern that matches password, secret and basicauth.
3. Rotate any credential that was passed to Solr as a Java system property, since it may have been visible to people with config-read access or, on open instances, to anyone.
4. Enable authorization on every Solr cloud and keep the admin interface off the public internet.
5. Prefer a secrets manager or a protected configuration file to command line properties, which also show up in process listings.

Why it matters

The weakness is CWE-522, insufficiently protected credentials. Solr already tried to hide sensitive Java system properties, but the two endpoints that publish them applied different rules. One hid anything with password in the name, and the other, the one on the admin home screen, relied on that narrow match. Real configurations use names like basicauth and cloud secret keys, so the filter missed them.

Apache's fix replaces the inconsistent rules with one option, solr.hiddenSysProps, that governs every endpoint. By default it hides all known sensitive properties, including basicauth, and any property whose name contains secret or password.

This is a good reminder that redaction by name is fragile. If a secret can show up in a property, a log line or a status page, somebody will eventually look at the page. KEV is false for this CVE. The Safeguard Gold directory lists it along with related Solr entries.

Try it yourself

Solr often arrives as a transitive dependency or inside a bundled product. The demo shows how an inventory finds it.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Apache Solr security page
• oss-security announcement

Last reviewed: 19 October 2026.