CVE-2026-44825: Apache Solr — bin/solr auth enable silently creates four default users with publicly known passwords
2 June 2026. Apache Solr has disclosed CVE-2026-44825 in the BasicAuth setup: anyone who enables Basic Authentication via bin/solr auth enable in Solr 9.4.0–9.10.1 or 10.0.0 gets, alongside their own chosen account, four additional template users silently written (superadmin, admin, search, index) with publicly known default passwords into security.json. An attacker with network access to the Solr endpoint can log in with these known credentials and gains full administrative access to the cluster — change configuration, read all indexes, exfiltrate data or disrupt the service. CVSS 8.1; the fix ships with the upcoming versions 9.11.0 and 10.1.0, while the immediate workaround is to delete or re-password the template users in security.json.
TL;DR — the 90-second summary
What was published?
CVE-2026-44825 (Apache Solr, 01 June 2026). Class: insecure default configuration / hardcoded credentials. Mechanism: bin/solr auth enable bootstraps BasicAuth and, alongside the operator's chosen account, writes four template users (superadmin, admin, search, index) with publicly known passwords into security.json.
How severe?
High — CVSS v3.1 8.1 (AV:N/AC:H/PR:N/S:U/C:H/I:H/A:H), CWE-798 + CWE-1188. Reach: full administrative access to the Solr cluster via known default accounts. Entry condition: BasicAuth was set up via bin/solr auth enableand the Solr endpoint is reachable for the attacker.
Which Solr versions are affected?
Apache Solr 9.4.0 through 9.10.1 and 10.0.0. Fixed in the (at publication not yet released) versions 9.11.0 and 10.1.0.
Am I affected?
You are affected if you run a Solr instance in the stated version range whose BasicAuth was set up via bin/solr auth enable — typical for TYPO3 search via EXT:solr with its own Solr host. Not affected: clusters that never bootstrapped BasicAuth via this tool, or where the template users were subsequently given strong passwords.
Immediate mitigation?
Look into security.json and either remove the template users superadmin, admin, search, index or give them strong, unique passwords. In parallel, shield the Solr endpoint from the public network (it never belongs directly on the internet anyway). Medium term, move to 9.11.0 / 10.1.0 once available.
Criticality?
See hero badge high (CVSS 8.1). No KEV listing, very low EPSS as of 02 June — but publicly known default credentials drastically lower the exploit bar once the endpoint is reachable.
What happened
On 1 June 2026 Apache Solr published CVE-2026-44825 — a finding in the tool used to enable Basic Authentication. Solr provides the CLI command bin/solr auth enable for this, which sets up authentication and produces a security.json with the credentials. The operator specifies their own account and expects exactly that account to be created.
The problem: in versions 9.4.0 through 9.10.1 and in 10.0.0 the tool additionally and without any visible notice writes four template users into security.json — superadmin, admin, search and index — with passwords hardcoded into the tool and therefore publicly known. These accounts carry administrative roles. The operator who just enabled BasicAuth to secure their Solr has thereby unknowingly installed four backdoors with known keys.
The consequence is direct: an attacker who reaches the Solr endpoint over the network logs in with one of the known template accounts and has full administrative access to the cluster. They can change configuration, read all indexes, exfiltrate data or disrupt the service. That is exactly why the CVE classifies the weakness as a combination of CWE-798 (hardcoded credentials) and CWE-1188 (insecure default initialisation): the insecurity arises not from an operator mistake but from the default behaviour of the setup tool.
The workaround is simple and immediately actionable: delete the four template users from security.json or give them strong, unique passwords. The clean solution is the upcoming versions 9.11.0 and 10.1.0, which correct the tool so it no longer creates additional accounts; an upgrade there then suffices to resolve the issue.
Technical assessment
Structurally, CVE-2026-44825 is a lesson in the difference between “authentication enabled” and “authentication secure”. At first glance the setup tool does exactly what it should: after bin/solr auth enable Solr demands credentials. The operator sees a login prompt and ticks off “secured”. That the same step installed four known accounts is invisible in normal operation — it sits in security.json, which hardly anyone reads line by line again after setup. That invisibility is the danger: the flaw is opened not by an action but by the absence of one (nobody removes the template users because nobody knows about them).
The second point is reachability. The CVSS vector states AV:N (network) and PR:N (no privileges needed), but AC:H (high attack complexity) — the latter because two conditions must coincide: BasicAuth was bootstrapped via the vulnerable tool, and the endpoint is reachable for the attacker. Solr never belongs directly on the public internet; in a clean architecture it sits behind the application on the internal network. The uncomfortable reality, though, is that exposed Solr instances have been a recurring find in internet scans for years. Whoever runs such an exposed Solr and switched on BasicAuth “for safety” via the tool has locked the door with a known key.
Third, the TYPO3 relevance. Apache Solr is the common search infrastructure in the TYPO3 ecosystem: the extension EXT:solr (Apache Solr for TYPO3) attaches a Solr host that indexes the content. Many Mittelstand TYPO3 installations run their own Solr instance for this — partly as a Docker container, partly as a package on a search host. If that instance is in the vulnerable version range and BasicAuth was set up via bin/solr auth enable, it is affected. The index then often contains exactly the content the CMS serves — with intranets or protected areas, potentially personal or confidential data.
Who is affected
Affected
Not affected
Condition
Apache Solr 9.4.0–9.10.1 and 10.0.0 whose BasicAuth was set up via bin/solr auth enable
Solr clusters that never bootstrapped BasicAuth via this tool (manual security.json, external auth proxy)
How BasicAuth was set up
Instances whose template users still carry the default passwords
Instances whose template users were subsequently given strong passwords or deleted
State of the template users in security.json
TYPO3 stacks with EXT:solr and their own Solr host in the vulnerable version range
TYPO3 stacks without Solr, or with Solr outside the version range or without a reachable endpoint
Solr usage and version level
The fastest answer comes from a look into security.json: if the users superadmin, admin, search or index are there without you having created them deliberately, the instance is affected. The version level completes the picture (bin/solr version or the admin UI).
Impact and immediate measures
The impact is a full admin takeover of the Solr cluster via known credentials. Whoever is logged in as superadmin or admin controls configuration and indexes — so they can manipulate search results, read indexed content (including protected content) or take the service down. For TYPO3 searches whose index also contains non-public content, this is data-protection relevant.
Operational Decision Block
Act immediately if: the Solr instance is in the vulnerable version range, was secured via bin/solr auth enable and is reachable beyond just localhost.
Controlled, in a maintenance window, if: the instance is bound only locally to the application (no network path for third parties) — the workaround stays mandatory, the acute lever is smaller.
No Solr pressure if: you run no Solr or never set up BasicAuth via the tool — briefly cross-check security.json and tick it off.
In this order. First, check security.json and identify the template users superadmin, admin, search, index. Second, remove or re-password: delete the accounts or give them strong, unique passwords (and review the roles). Third, secure reachability: the Solr endpoint belongs on the internal network behind the application, not on the public internet — set firewall/network policy accordingly. Fourth, check logs: look for accesses by the template accounts in the Solr request logs (a login as superadmin/admin is a clear signal if you never use these accounts yourself). Fifth, move to 9.11.0 / 10.1.0 in the medium term, once available.
This article reflects my technical and strategic assessment. It is not legal advice and not a data-protection impact assessment.
Detection / verification
Two questions: “do I have the template users” (the config question) and “has anyone used them” (the log question).
Check snippets (copy/paste):
# 1) Determine the Solr version
bin/solr version
# 2) Check security.json for template users (path depends on setup)
grep -nE '"(superadmin|admin|search|index)"' /var/solr/data/security.json 2>/dev/null \
|| grep -nE '"(superadmin|admin|search|index)"' server/solr/security.json 2>/dev/null
# 3) If Solr is running: read the authentication config via the API
curl -s -u <your-admin>:<pw> 'http://localhost:8983/solr/admin/authentication' | jq .
# 4) Search request logs for logins by the template accounts
grep -REn '(superadmin|admin|search|index)' server/logs/*.request.log 2>/dev/null
What is suspicious: the presence of the four accounts in security.json that you did not create yourself — plus any successful request authenticated via one of these accounts if you never actively use them. Since the default passwords are publicly known, treat every foreign login via these accounts as a compromise.
Operator recommendation
Mittelstand
For TYPO3 operators with EXT:solr the fastest step is a look into the Solr host's security.json. If the template users are there, remove or re-password them — that is a minutes-long job and closes the path immediately. In parallel, make sure the Solr port (default 8983) is not reachable from the internet; in many setups that is the actually more dangerous issue, independent of this CVE.
Container / Kubernetes
If you run Solr as a container, check whether security.json comes from an image, a ConfigMap/Secret or a bin/solr auth enable init step — and whether that init step brings the template users along. The correction belongs in the image or the secret, not in the running container; then roll out the pod again. Add the version jump to 9.11.0 / 10.1.0 to image maintenance once the releases are out.
Hosting & operations
Generally for Solr: authentication is the second line of defence, network isolation the first. A Solr bound only internally to the application is attackable only from the inside even with default accounts. The combination of an exposed endpoint and known credentials is the dangerous case — and exactly the combination this CVE addresses.
Frequently asked questions about CVE-2026-44825
Does this also affect SolrCloud setups?+
Yes — in the SolrCloud case security.json lives in ZooKeeper and applies cluster-wide. The workaround (remove/re-password the template users) is applied once centrally in ZooKeeper and takes effect for all nodes.
Has my indexed data been exfiltrated?+
That can only be assessed from the logs. Look for successful requests authenticated via superadmin/admin/search/index even though you never use these accounts. Treat every such foreign login as a compromise; without logs, assume possible access when in doubt.
I set up BasicAuth manually via my own security.json — am I affected?+
Not via this path. The flaw arises from the bin/solr auth enable tool that adds the template users. A manually written security.json without these accounts is not affected — but check it briefly for the four names anyway.
Is closing the Solr port via firewall enough?+
It reduces the risk considerably (an unreachable endpoint cannot be attacked with default accounts) but does not replace cleaning up security.json. Internal attackers or other workloads on the same network could still use the accounts. Do both: close the network and remove the template users.
Do I have to wait for 9.11.0 / 10.1.0 to be safe?+
No. The workaround — delete the template users or give them strong passwords — closes the path immediately, even without an upgrade. The upgrade is the clean permanent solution once the versions are available.
How do I check whether my TYPO3 Solr instance is affected?+
Look into the Solr host's security.json and check for the users superadmin, admin, search, index that you did not create yourself — and compare the version level (bin/solr version) against the range 9.4.0–9.10.1 / 10.0.0. Together they answer the question.
Bottom line
CVE-2026-44825 is no exploit fireworks but the quiet variant of risk: a setup step that promises to “turn on security” and ships four known keys nobody deliberately ordered. The triage is cheap (a look into security.json), the workaround is a minutes-long job (delete or re-password the accounts), and the lasting solution is a normal upgrade to 9.11.0 / 10.1.0. The most important accompanying lesson is the old one: Solr never belongs openly on the internet — network isolation is the first line, authentication the second. Risk soberly: high for exposed instances secured via the tool, low for cleanly isolated ones — security.json and the firewall rule separate the two cases in minutes.
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.
![[Translate to English:] Foto von Kai Ole Hartwig.](/fileadmin/_processed_/e/9/csm_ole-neu_8000c3dfab.avif)