Apache Solr CVE-2026-44825: Quick Look at Hardcoded Credentials in BasicAuth Bootstrapping

Introduction

Apache Solr's authentication setup tool silently installs a set of backdoor accounts. Administrators who ran it to secure their clusters were, at the same time, creating a publicly accessible administrative entry point. CVE-2026-44825, with a CVSS score of 8.1 (HIGH), affects the bin/solr auth enable command in Solr versions 9.4.0 through 9.10.1 and 10.0.0. No patched release is available yet.

Apache Solr, built on Apache Lucene, is the dominant open source enterprise search platform. According to 6sense, it holds approximately 79% of the enterprise search market, so the potential blast radius of this vulnerability is unusually broad and covers organizations of all sizes. Solr runs search for everything from e-commerce platforms to internal knowledge management systems, which makes it a high-value target for attackers who want access to indexed data.

Technical Information

Root Cause

CVE-2026-44825 comes from a design flaw in the Basic Authentication bootstrapping tool, invoked via bin/solr auth enable. When an administrator runs this command to enable BasicAuth on a Solr cluster, the tool does two things. It creates the user account the administrator specified, and it silently provisions four additional "template" user accounts with hardcoded, publicly known default credentials:

• superadmin
• admin
• search
• index

The bootstrapping process does not prominently tell the operator that these template accounts exist. An administrator who runs the command, sets their own credentials, and moves on has no obvious reason to suspect that security.json now holds four additional accounts with known passwords. The internal Solr issue tracker reference for this bug is SOLR-18233.

CWE Classification

The vulnerability has two CWE classifications. Together they point to a systemic design problem more than a simple coding error:

CVSS v3.1 Breakdown

The CVSS v3.1 vector string is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, which gives a base score of 8.1 (HIGH):

The "High" attack complexity is the only factor keeping this from a Critical rating. In practice, once the default passwords are publicly known and scanners are deployed, the effective complexity for internet-facing instances drops to near zero.

Attack Flow

An attacker would exploit this vulnerability in three steps:

1. Reconnaissance: Identify internet-exposed Apache Solr instances running versions 9.4.0 through 9.10.1 or 10.0.0. Solr's default HTTP interface and API endpoints have well-known fingerprints, so discovery is straightforward.

2. Default credential testing: Try to authenticate to the Solr admin API with the publicly known default credentials for the template user accounts. These credentials are hardcoded in the bin/solr auth enable tool and are identical across every deployment that used this bootstrapping method. Once the advisory details are fully disclosed, they are effectively public knowledge.

3. Full cluster compromise: Authenticating as superadmin or admin gives the attacker full administrative access to the Solr cluster. From there the attacker can read, modify, or delete all indexed data, alter cluster configuration, and create or remove collections. Depending on the deployment architecture, the attacker may also be able to pivot to deeper network access. The search and index accounts may have more limited permissions but could still expose sensitive data or allow index manipulation.

This attack chain is concerning because it is so simple. It needs no memory corruption, race condition, or complex chain of requests. It is a login with known credentials.

Conditions Where Clusters Are Not Affected

The advisory explicitly identifies two safe configurations:

• Clusters where bin/solr auth enable was never used to bootstrap BasicAuth. If authentication was configured manually or through other mechanisms, the template users were never created.
• Clusters where the template users have already been assigned strong passwords after the bootstrap process.

Affected Systems and Versions

The following Apache Solr versions are confirmed vulnerable:

• Apache Solr 9.4.0 through 9.10.1 (all releases in this range on the 9.x branch)
• Apache Solr 10.0.0 (the initial 10.x release)

The vulnerability is present only in clusters where bin/solr auth enable was used to bootstrap Basic Authentication. Clusters that configured authentication some other way, or where the template user passwords were changed after bootstrapping, are not affected.

The planned fix versions are 9.11.0 and 10.1.0, and neither has been released yet. Until they ship, the only mitigation is the manual workaround of removing the template accounts from security.json or giving them new credentials.

Mitigation

Immediate Workaround

The Apache Solr advisory gives a workaround that fully mitigates the vulnerability without a software upgrade. On every affected cluster, administrators should make one of two changes to the security.json configuration file:

1. Remove the superadmin, admin, search, and index user entries from security.json entirely. This is the more secure option, because it eliminates the accounts instead of relying on password strength.

2. Replace the default passwords for all four template accounts with strong, unique passwords.

Prioritization Guidance

Additional Defensive Measures

• Restrict access to Solr admin interfaces to trusted internal networks. Do not expose Solr's HTTP API to the public internet.
• Audit every Solr deployment in the organization to find the ones that used bin/solr auth enable for bootstrapping.
• Check security.json on every cluster for the four template users.

Threat Intelligence

As of June 1, 2026, available sources show no confirmed active exploitation of CVE-2026-44825. The CVE was published only days ago, so there has been little time for exploitation to be observed.

Several factors still point to a high likelihood of exploitation in the near term:

• Naveen Sunkavally of Horizon3.ai found the vulnerability. Horizon3.ai is an offensive security firm known for publishing proof-of-concept exploits, and its past disclosures for other CVEs (including CVE-2026-27771 affecting Gitea and CVE-2026-9082) have come with detailed technical write-ups. A public PoC for CVE-2026-44825 should be anticipated.
• VulnDB has catalogued the vulnerability as VDB-367397 with exploit pricing information, which shows it is already on the radar of the commercial exploit intelligence community.
• Proofpoint's threat intelligence research reports that 12 distinct 2026 CVEs have already been observed in active network-facing exploitation, compared to 8 on CISA's Known Exploited Vulnerabilities catalog. That indicates new vulnerabilities are being exploited at a fast pace this year.
• Threat actors have targeted Apache Solr before, including active exploitation of CVE-2019-12409 (a remote code execution vulnerability related to JMX configuration).
• Default credentials are trivially testable at scale. Once the specific passwords are publicly known, automated scanning tools can test every internet-facing Solr instance in hours.

Solr's dominant market position (79% enterprise search market share), an exploit that amounts to a known username and password, and a discoverer with a track record of releasing PoCs together leave defenders much less time to remediate.

Vendor Security History

The Apache Solr project has disclosed multiple authentication- and authorization-related vulnerabilities in 2026 alone:

Three advisories in five months have all hit the authentication and authorization subsystem. That suggests this area of the Solr codebase warrants a comprehensive security audit rather than point fixes. The issues cover three different auth mechanisms with three different classes of flaw: BasicAuth (hardcoded credentials), JWT authentication (insecure defaults), and rule-based authorization (bypass).

The Apache Software Foundation is the CNA for Solr vulnerabilities. Jan Hoydahl issued the advisory for CVE-2026-44825 and posted it to both the [email protected] and [email protected] mailing lists. The vendor response included clear mitigation instructions and explicit guidance on which configurations are not affected, which helps with operational triage. The main concern is that disclosure came before any patched version was available, so organizations have to rely entirely on manual workarounds.

References

• NVD: CVE-2026-44825
• CVE Record: CVE-2026-44825
• Apache Solr Advisory (Official Mailing List)
• Apache Solr Advisory (Alternate Thread)
• oss-security Mailing List Post
• oss-security Announcement on X
• Solr Security News
• Basic Authentication Plugin Reference Guide
• Configuring Authentication and Authorization
• VulnDB Entry: VDB-367397
• Apache Solr Market Share (6sense)
• Proofpoint: 2026 Vulnerability Exploitation in the Wild
• CVE-2026-22022 Advisory
• Solr CVE Dependency Status