[
https://issues.apache.org/jira/browse/SOLR-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094837#comment-18094837
]
David Smiley commented on SOLR-18233:
-------------------------------------
I've noticed a flaky test failure that is _nearby_ this Jira issue... WDYT?
(Written by Claude Opus)
h4. Flaky BATS test: "enable auth connects via zookeeper" (test_auth.bats)
Intermittent failure on Solr-TestIntegration-main nightly runs (e.g. builds 597
and 599 fail, 595/596/598 pass — alternating). Not a recent regression:
\{{AuthTool}}, the \{{ZkController}} bootstrap, and \{{test_auth.bats}} have no
relevant recent changes.
h5. Symptom
{\{test_auth.bats}} test 8 runs:
{code}
solr start
run solr auth enable --type basicAuth --credentials name:password -z
localhost:${ZK_PORT}
assert_output --partial 'Successfully enabled basic auth'
{code}
The assertion fails because \{{auth enable}} prints instead:
{code}
ERROR: KeeperErrorCode = NoNode for /security.json
{code}
h5. Root cause
{\{AuthTool}} writes security.json with \{{zkClient.setData("/security.json",
...)}}, which requires the znode to already exist. \{{/security.json}} is
normally bootstrapped as \{{{}}} during startup by
\{{ZkController.createClusterZkNodes()}} (\{{ensureExists}}), called
synchronously in the \{{ZkController}} constructor. That bootstrap races
against \{{solr start}} reporting "ready": ~50% of the time the CLI's \{{auth
enable -z}} connects to ZK before the node exists, and \{{setData}} throws
\{{NoNode}}.
{\{AuthTool}} does check existence earlier (checkSecurityJsonExists) but only
to detect an already-enabled cluster; it then assumes the node exists at the
\{{setData}} call. So the enable path is fragile to an absent node — both this
startup race and a genuinely fresh ZK.
h5. Proposed fix
Make \{{auth enable}} create \{{/security.json}} if absent instead of blindly
calling \{{setData}}:
{code:java}
byte[] bytes = securityJson.getBytes(StandardCharsets.UTF_8);
if (zkClient.exists("/security.json")) {
zkClient.setData("/security.json", bytes);
} else {
zkClient.create("/security.json", bytes, CreateMode.PERSISTENT);
}
{code}
This closes the race and makes \{{auth enable -z}} work against any ZK.
> 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
> Labels: pull-request-available
> Fix For: 10.1, 9.11
>
> Time Spent: 7.5h
> Remaining Estimate: 0h
>
> 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]
