Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-44825

CVE-2026-44825: Apache Solr Auth Bypass Vulnerability

CVE-2026-44825 is an authentication bypass vulnerability in Apache Solr caused by hardcoded credentials in the Basic Authentication setup tool. This article covers the technical details, affected versions, and mitigation steps.

Published:

CVE-2026-44825 Overview

CVE-2026-44825 is a hardcoded credentials vulnerability in the Apache Solr Basic Authentication setup tool. The bin/solr auth enable command silently provisions template user accounts (superadmin, admin, search, index) with publicly known default passwords alongside the user-specified account. A remote attacker who knows these defaults can authenticate to the cluster and gain full administrative access. The flaw affects Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0. The vulnerability is classified under [CWE-798: Use of Hard-coded Credentials].

Critical Impact

Unauthenticated remote attackers can obtain full administrative control of affected Apache Solr clusters using publicly known default credentials, leading to complete compromise of confidentiality, integrity, and availability.

Affected Products

  • Apache Solr 9.4.0 through 9.10.1
  • Apache Solr 10.0.0
  • Clusters bootstrapped with bin/solr auth enable retaining template users

Discovery Timeline

  • 2026-06-01 - CVE-2026-44825 published to NVD
  • 2026-06-01 - Last updated in NVD database

Technical Details for CVE-2026-44825

Vulnerability Analysis

The vulnerability resides in the Apache Solr Basic Authentication bootstrap workflow invoked through bin/solr auth enable. When an administrator enables Basic Authentication, the tool writes a security.json file containing the operator-supplied account. It also silently installs four additional template accounts: superadmin, admin, search, and index. These accounts are provisioned with default passwords that are publicly documented in the Solr source tree. Administrators receive no prompt, warning, or visible record that these accounts exist after setup completes.

Because Apache Solr typically exposes its HTTP API to the network, an attacker who reaches the cluster endpoint can submit Basic Authentication requests using the known credentials. Successful authentication grants administrative privileges over collections, configurations, and the underlying Solr APIs.

Root Cause

The root cause is the silent installation of template users with known static passwords during the Basic Authentication bootstrap process. The setup tool does not randomize the template passwords, does not require the operator to set replacement values, and does not surface the existence of these accounts in interactive output. The pattern matches [CWE-798] because authentication relies on credentials embedded in the distributed software rather than per-deployment secrets.

Attack Vector

The attack requires only network reachability to the Solr HTTP interface. An attacker enumerates Solr instances, submits HTTP requests to administrative endpoints such as /solr/admin/authentication or /solr/admin/collections, and supplies one of the template usernames with its known default password in the Authorization: Basic header. Upon successful authentication, the attacker can modify collections, register request handlers, exfiltrate indexed data, or pivot through the cluster. No user interaction is required, and the exploit is reproducible against any cluster bootstrapped with bin/solr auth enable whose template users retain default passwords.

No verified public proof-of-concept code is available at this time. See the Apache Security Thread and Openwall OSS-Security Discussion for vendor-confirmed technical details.

Detection Methods for CVE-2026-44825

Indicators of Compromise

  • Presence of superadmin, admin, search, or index entries inside the cluster security.json file
  • Successful HTTP 200 responses to /solr/admin/* endpoints carrying Authorization: Basic headers for the template usernames
  • Unexpected creation, modification, or reload of Solr collections, config sets, or request handlers
  • Outbound connections from Solr nodes to unfamiliar hosts following administrative API calls

Detection Strategies

  • Inspect every security.json across the fleet and flag clusters that contain any of the four template usernames
  • Parse Solr access logs for authentication events tied to superadmin, admin, search, or index originating from non-administrative source addresses
  • Alert on Collections API or Config API calls authenticated as a template user, particularly those that register Velocity, XSLT, or stream expression handlers

Monitoring Recommendations

  • Centralize Solr access and audit logs in a SIEM and apply detection rules for the four template usernames
  • Track process lineage on Solr hosts to identify child processes spawned by the Java Solr process after administrative API activity
  • Monitor egress traffic from Solr nodes for anomalies that may indicate data exfiltration following credential abuse

How to Mitigate CVE-2026-44825

Immediate Actions Required

  • Open security.json on every Solr 9.4.0 through 9.10.1 and 10.0.0 cluster and delete the superadmin, admin, search, and index template users
  • Alternatively, reset the passwords of the template users to strong, unique values managed through your secret store
  • Restrict network exposure of Solr administrative ports to trusted management networks only
  • Review historical access logs for authentication attempts using the template usernames and investigate any matches

Patch Information

Apache has indicated that future releases 9.11.0 and 10.1.0 will not be vulnerable, and upgrading will fully resolve the issue once those versions are available. Until those releases ship, administrators must apply the configuration-level workarounds described above. Refer to the Apache Security Thread for the official vendor advisory.

Workarounds

  • Remove the four template users (superadmin, admin, search, index) from security.json and restart Solr to load the updated configuration
  • Assign strong, unique passwords to the template users if removal is not operationally feasible
  • Place Solr behind a reverse proxy or firewall that restricts access to the HTTP interface to authorized administrators
  • Avoid using bin/solr auth enable to bootstrap Basic Authentication; configure security.json manually with only the accounts required
bash
# Configuration example: minimal security.json without template users
# Replace the hash below with a value generated for your chosen password.
cat > security.json <<'EOF'
{
  "authentication": {
    "blockUnknown": true,
    "class": "solr.BasicAuthPlugin",
    "credentials": {
      "solradmin": "<sha256(password+salt)>  <salt>"
    },
    "forwardCredentials": false
  },
  "authorization": {
    "class": "solr.RuleBasedAuthorizationPlugin",
    "permissions": [
      { "name": "security-edit", "role": "admin" }
    ],
    "user-role": {
      "solradmin": "admin"
    }
  }
}
EOF

# Upload to ZooKeeper for SolrCloud deployments
bin/solr zk cp file:security.json zk:/security.json -z <zk-host>:2181

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.