[
https://issues.apache.org/jira/browse/SOLR-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-18233:
-------------------------------
Description:
h2. The CVE text
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.
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
h2. Mitigation
If you came here from the link in the CVE, there is nothing more for you to do
than what is written above. Delete the template users or change their passwords.
h2. Code changes
For the upcoming version 9.11 and 10.1 this Jira will provide the following
code changes:
_Password policy (affects all Basic Auth installations):_ Solr's Basic
Authentication has had minimal password requirements. While the Admin UI
enforced a few rules, it still permitted passwords identical to the username
(e.g. {{{}admin{}}}/{{{}admin{}}}). This change disallows username/password
equality both at login and at account creation, via the API and Admin UI alike.
As a side effect, any existing installation retaining the well-known template
credentials will have those accounts silently disabled until the passwords are
changed.
_{{bin/solr auth enable}} cleanup:_ The command previously uploaded a bundled
{{security.json}} template containing four undocumented accounts with weak
default credentials. With this change:
* The {{superadmin}} template account is removed from the bundled template
* The remaining template accounts ship with no password set rather than a
default one
* The command will prompt the operator to set passwords for any template
accounts at enable-time
* Documentation for {{bin/solr auth enable}} is updated to clearly describe
all accounts it creates
These changes collectively strengthen the security posture of both new and
existing Solr installations using Basic Authentication.
was:
h2. The CVE text
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.
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
h2. Mitigation
If you came here from the link in the CVE, there is nothing more for you to do
than what is written above. Delete the template users or change their passwords.
h2. No code changes?
There will be code changes for
> CVE-2026-44825 SolrCloud bin/solr hardcoded credentials
> -------------------------------------------------------
>
> Key: SOLR-18233
> URL: https://issues.apache.org/jira/browse/SOLR-18233
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, security
> Affects Versions: 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10, 10.0, 9.10.1
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Blocker
> Fix For: 10.1, 9.11
>
>
> h2. The CVE text
> 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.
> 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
> h2. Mitigation
> If you came here from the link in the CVE, there is nothing more for you to
> do than what is written above. Delete the template users or change their
> passwords.
> h2. Code changes
> For the upcoming version 9.11 and 10.1 this Jira will provide the following
> code changes:
> _Password policy (affects all Basic Auth installations):_ Solr's Basic
> Authentication has had minimal password requirements. While the Admin UI
> enforced a few rules, it still permitted passwords identical to the username
> (e.g. {{{}admin{}}}/{{{}admin{}}}). This change disallows username/password
> equality both at login and at account creation, via the API and Admin UI
> alike. As a side effect, any existing installation retaining the well-known
> template credentials will have those accounts silently disabled until the
> passwords are changed.
> _{{bin/solr auth enable}} cleanup:_ The command previously uploaded a bundled
> {{security.json}} template containing four undocumented accounts with weak
> default credentials. With this change:
> * The {{superadmin}} template account is removed from the bundled template
> * The remaining template accounts ship with no password set rather than a
> default one
> * The command will prompt the operator to set passwords for any template
> accounts at enable-time
> * Documentation for {{bin/solr auth enable}} is updated to clearly describe
> all accounts it creates
> These changes collectively strengthen the security posture of both new and
> existing Solr installations using Basic Authentication.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
