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

Introduction

A silently installed set of backdoor accounts in Apache Solr's authentication setup tool means that administrators who thought they were securing their clusters were simultaneously creating a publicly accessible administrative entry point. CVE-2026-44825, carrying a CVSS score of 8.1 (HIGH), affects the bin/solr auth enable command across Solr versions 9.4.0 through 9.10.1 and 10.0.0, and no patched release is available yet.

Apache Solr is the dominant open source enterprise search platform, built on Apache Lucene. According to 6sense, it holds approximately 79% market share in the enterprise search category, meaning this vulnerability has an unusually broad potential blast radius across organizations of all sizes. Solr powers search functionality in everything from e-commerce platforms to internal knowledge management systems, making it a high value target for attackers seeking access to indexed data.

Technical Information

Root Cause

CVE-2026-44825 stems 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 performs two actions: it creates the administrator's specified user account, and it silently provisions four additional "template" user accounts with hardcoded, publicly known default credentials. These template accounts are:

• superadmin
• admin
• search
• index

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

CWE Classification

The vulnerability carries a dual CWE classification that signals this is a systemic design problem rather 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, yielding 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 through the following 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 that make discovery straightforward.

2. Default Credential Testing: Attempt to authenticate to the Solr admin API using the publicly known default credentials for the template user accounts. Since these credentials are hardcoded in the bin/solr auth enable tool and identical across all deployments that used this bootstrapping method, they are effectively public knowledge once the advisory details are fully disclosed.

3. Full Cluster Compromise: Upon successful authentication as superadmin or admin, the attacker gains full administrative access to the Solr cluster. This enables reading, modifying, or deleting all indexed data; altering cluster configuration; creating or removing collections; and potentially pivoting to deeper network access depending on the deployment architecture. The search and index accounts may have more limited permissions but could still expose sensitive data or allow index manipulation.

The simplicity of this attack chain is what makes it particularly concerning. There is no memory corruption, no race condition, no 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 only present in clusters where bin/solr auth enable was used to bootstrap Basic Authentication. Clusters that configured authentication through other means, 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, neither of which has been released yet. Until those versions ship, the only mitigation is the manual workaround of removing or re-credentialing the template accounts in security.json.

Mitigation

Immediate Workaround

The Apache Solr advisory provides a workaround that fully mitigates the vulnerability without requiring a software upgrade. On every affected cluster, administrators should take one of two actions on the security.json configuration file:

1. Delete the template user accounts: Remove the superadmin, admin, search, and index user entries from security.json entirely. This is the more secure option as it eliminates the accounts rather than relying on password strength.

2. Change the template user passwords: 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 all Solr deployments across the organization to determine which ones used bin/solr auth enable for bootstrapping.
• Inspect security.json on every cluster for the presence of the four template users.

Threat Intelligence

As of June 1, 2026, no confirmed active exploitation of CVE-2026-44825 has been observed in available sources. The CVE was published just days ago, which limits the window for observed exploitation.

However, several factors point toward a high likelihood of near-term exploitation:

Discoverer profile: The vulnerability was found by Naveen Sunkavally of Horizon3.ai, an offensive security firm known for publishing proof of concept exploits. Their past disclosures for other CVEs (including CVE-2026-27771 affecting Gitea and CVE-2026-9082) have been accompanied by detailed technical write-ups. A public PoC for CVE-2026-44825 should be anticipated.

Commercial exploit intelligence interest: VulnDB has catalogued this vulnerability as VDB-367397 with exploit pricing information, indicating it is already on the radar of the commercial exploit intelligence community.

2026 exploitation trends: 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. This indicates a fast exploitation cadence for new vulnerabilities this year.

Historical Solr targeting: Apache Solr has been targeted by threat actors before, including active exploitation of CVE-2019-12409 (a remote code execution vulnerability related to JMX configuration).

Trivial mass scanning potential: 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.

The combination of Solr's dominant market position (79% enterprise search market share), the trivial nature of the exploit (known username and password), and the discoverer's track record of releasing PoCs compresses the remediation timeline significantly.

Vendor Security History

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

This pattern is notable. Three advisories in five months, all targeting the authentication and authorization subsystem, suggest that this area of the Solr codebase warrants a comprehensive security audit rather than point fixes. The issues span BasicAuth (hardcoded credentials), JWT authentication (insecure defaults), and rule-based authorization (bypass), covering three different auth mechanisms with three different classes of flaw.

The Apache Software Foundation serves as the CNA for Solr vulnerabilities. The advisory for CVE-2026-44825 was issued by Jan Hoydahl and posted 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 is helpful for operational triage. The main concern is that the disclosure occurred before patched versions are available, requiring organizations 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