GHSA-qhr7-h655-pw6r: Apache Solr: Enabling BasicAuth using bin/solr CLI configures additional insecure users
Hardcoded credentials in the Basic Authentication setup tool (bin/solr auth enable) in Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0 allows a remote attacker to gain full administrative access to the cluster via publicly known default credentials installed silently alongside the user-specified account.
As an immediate workaround without upgrading, delete the template users (superadmin, admin, search, index) from security.json or change their passwords. The future, not yet released, versions 9.11.0 and 10.1.0 will not be vulnerable, and it will be enough to upgrade to solve the issue.
Not affected: Clusters where bin/solr auth enable was not used to bootstrap BasicAuth Clusters where template users have been assigned strong passwords after bootstrap
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
bitnami/solrto a version that resolves this vulnerability.Fixed in 10.1.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 9.11.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 10.1.0 - Configuration
As an immediate workaround without upgrading, delete the template users superadmin, admin, search, and index from security.json, or change their passwords.
Apache Solr Basic Authentication Template users in security.json = Delete superadmin, admin, search, and index, or change their passwords to strong passwords
Event History
Frequently Asked Questions
Which Solr deployments are exposed to this issue?
Clusters are affected if Basic Authentication was bootstrapped with bin/solr auth enable on Solr 9.4.0 through 9.10.1 or 10.0.0, unless the installed template users were subsequently assigned strong passwords. Clusters that did not use that command to bootstrap BasicAuth are not affected.
What does an attacker need to exploit the vulnerability?
A remote attacker can use the publicly known default credentials silently installed for template users to obtain full administrative access to the cluster. The issue requires no privileges or user interaction.
What can be done if upgrading is not immediately possible?
Delete the template users superadmin, admin, search, and index from security.json, or change their passwords to strong values. This removes or replaces the insecure credentials created during BasicAuth setup.
How can administrators determine whether their cluster is already affected?
Review whether bin/solr auth enable was used to bootstrap BasicAuth and inspect security.json for the template users superadmin, admin, search, and index. A cluster remains affected when those accounts retain the installed default credentials.
Which upgrades address the issue?
The issue is addressed in the future, not-yet-released Solr versions 9.11.0 and 10.1.0. Upgrading to either of those versions will resolve the vulnerability.