CVE-2026-44825: Apache Solr Hardcoded Credentials — How to Detect Exposed Solr Instances on Your Network

Apache Solr's Basic Authentication setup tool silently installs four template accounts with passwords identical to their usernames. With NVD scoring this 9.8 Critical and no patched version released yet, every Solr cluster bootstrapped with bin/solr auth enable since version 9.4.0 is potentially wide open to full administrative takeover.

The Vulnerability

CVE-2026-44825 (CWE-798, CWE-1188) is a hardcoded credentials vulnerability in Apache Solr's BasicAuth bootstrap tool. When an administrator runs bin/solr auth enable to set up Solr authentication, the CLI creates the specified admin account — but also silently installs four additional template users with publicly known default credentials. The exact username/password pairs are visible in the bundled security.json template in the Solr source code on GitHub (solr/core/src/resources/security.json). Not all Solr clusters are affected — only those where bin/solr auth enable was used to bootstrap BasicAuth and the template users were not subsequently removed or given strong passwords.

The Default Credentials

The template security.json bundled with Solr installs these four accounts alongside whatever user the administrator specifies. Every password is identical to its username:

The bundled template also sets blockUnknown: false. While the CLI's --block-unknown flag defaults to true, a related bug caused the flag to write to the wrong location in security.json — meaning operators may believe anonymous access is blocked when it is not. An attacker who discovers a Solr instance can try the default credentials for full admin access, or in misconfigured SolrCloud clusters, access the API without any authentication at all.

NVD vs. Apache: Why the Score Differs

NVD scored this 9.8 Critical (attack complexity: low), while Apache self-assessed at 8.1 High (attack complexity: high). The disagreement is about whether an attacker needs to know that bin/solr auth enable was used. NVD's position: the credentials are publicly known and trivially exploitable. Apache's position: the attacker must guess which bootstrap method was used. Given that the credentials are in the public source code, NVD's assessment may be more realistic.

Investigation Workflow

Apache Solr powers search for thousands of organizations — it holds approximately 79% market share in enterprise search with 12,000+ companies using it globally. Here's how to find exposed instances on your network using RECON.

1. Port Scan: Find Solr Instances

Solr's default HTTP port is 8983. In SolrCloud mode, the embedded ZooKeeper runs on 9983. Scan your internal subnets for both ports. Some deployments use reverse proxies on 80 or 443, so also check for Solr behind load balancers.

2. HTTP Client: Probe the Admin API

Once you find open ports, use RECON's HTTP client to probe the Solr Admin API. Key endpoints to check:

• • GET /solr/admin/info/system — returns Solr version, OS, and JVM details. If this returns 200 without credentials, blockUnknown is false
• • GET /solr/admin/authentication — shows the authentication configuration, revealing whether BasicAuth is enabled
• • GET /solr/ — the Admin UI. If accessible, the instance is unauthenticated or misconfigured

If the system endpoint returns 401 Unauthorized, BasicAuth is active. On systems you are authorized to test, validate with the Solr default credentials: set the Authorization header to Basic YWRtaW46YWRtaW4= (admin:admin). A 200 response confirms the instance has hardcoded template users and is vulnerable to CVE-2026-44825.

3. TLS Inspect: Check for Encrypted Solr

Some production Solr deployments run behind TLS. Inspect certificates on ports 8983 and 443 for subjects or SANs containing solr, search, or your organization's naming patterns. Self-signed certificates on port 8983 are a strong indicator of a direct Solr deployment.

4. DNS: Discover Hidden Solr Nodes

Query DNS for common Solr naming patterns: solr.*, search.*, solrcloud.*, zk.* (ZooKeeper). In SolrCloud deployments, there are often multiple nodes behind a load balancer — finding one may reveal others through the /solr/admin/collections API or ZooKeeper's mntr command on port 9983.

Cross-Reference with External Data

Related Solr Vulnerabilities

CVE-2026-44825 is not the only recent Solr security issue. If you find Solr instances, check for these as well:

• • CVE-2026-22022 — Authorization bypass in RuleBasedAuthorizationPlugin (fixed in 9.10.1)
• • CVE-2026-22444 — Insufficient file-access checking enabling RCE on Windows via UNC paths (fixed in 9.10.1, public PoC available)
• • JWT auth bypass — A May 2026 advisory about blockUnknown defaulting to false in JWT authentication (no CVE assigned)

Remediation

No patched version exists yet — Solr 9.11.0 and 10.1.0 will address this but have not been released as of June 3, 2026. Apply the workaround immediately.

1. Delete the template users now. Remove superadmin, admin, search, and index from security.json. In SolrCloud: solr zk cp zk:/security.json ./security.json -z localhost:9983, edit, then upload back. In standalone: edit $SOLR_HOME/security.json directly.
2. Or change all template passwords via the Authentication API: curl -u superadmin:superadmin http://HOST:8983/solr/admin/authentication -d '{\"set-user\":{\"superadmin\":\"STRONG_PASSWORD\"}}'
3. Set blockUnknown to true. The template defaults to false, allowing unauthenticated access. Update authentication config to block unknown users.
4. Upgrade when available. Monitor for Solr 9.11.0 and 10.1.0 releases which will not include template users.
5. Audit access logs. Check Solr access logs for authentication attempts using the template usernames, especially from unexpected source IPs.
6. Network isolation. Solr should never be directly exposed to the internet. Ensure instances are behind firewalls or VPNs with access restricted to application servers.

Sources

• → NVD: CVE-2026-44825
• → Apache Mailing List: CVE-2026-44825 Advisory
• → Apache Jira: SOLR-18233
• → oss-security: CVE-2026-44825 Disclosure
• → Apache Solr Source Code (security.json template)