CVE-2026-44825
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk41th percentile - higher than 41% of all known CVEs
Summary
Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0 contain hardcoded default credentials in the Basic Authentication setup tool (bin/solr auth enable). A remote attacker can gain full administrative access to the cluster using publicly known default passwords.
Risk Assessment
The organization is at risk of complete cluster takeover by an unauthorized attacker, potentially leading to data breaches or service disruption.
Recommendation
Immediately delete the default users (superadmin, admin, search, index) from security.json or change their passwords. Plan to upgrade to versions 9.11.0 or 10.1.0 when released.
Other vulnerabilities in Apache Solr
See all- CVE-2026-22444High
The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting. These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem. On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.
- CVE-2026-22022High
Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted: use of the RuleBasedAuthorizationPlugin, a config with multiple roles, a permission list using one or more of the predefined permission rules (config-read, config-edit, schema-read, metrics-read, security-read), no "all" permission defined, and a networking setup that allows unfiltered requests to Solr.
- CVE-2017-3163High
A vulnerability in Apache Solr allows attackers to exploit the index replication feature to read files from the server due to improper validation of file names. Versions before 5.5.4 and 6.x before 6.4.1 are susceptible to path traversal attacks.
- CVE-2017-7660High
Apache Solr uses a PKI based mechanism to secure inter-node communication when security is enabled. It is possible to create a specially crafted node name that does not exist as part of the cluster and point it to a malicious node, which can trick other nodes in the cluster.
- CVE-2019-17558HighActively exploited
Apache Solr 5.0.0 to Apache Solr 8.3.1 are vulnerable to a Remote Code Execution through the VelocityResponseWriter. A Velocity template can be provided through Velocity templates in a configset `velocity/` directory or as a parameter. Parameter-provided templates are disabled by default but can be enabled by setting `params.resource.loader.enabled` to `true`, which requires configuration API access. Solr 8.4 removed the params resource loader entirely and only enables configset-provided template rendering when the configset is `trusted`.
- CVE-2019-0193HighActively exploited
In Apache Solr, the DataImportHandler (DIH) has a feature where the entire DIH configuration can come from a request's 'dataConfig' parameter. The debug mode of the DIH admin screen uses this, which is a security risk since a DIH config can contain scripts. Starting with Solr 8.2.0, use of this parameter requires setting the Java System property 'enable.dih.dataConfigParam' to true.
- CVE-2017-12629Critical
Apache Solr before 7.1 is vulnerable to remote code execution, which can be exploited via an XXE attack in conjunction with the Config API add-listener command, leading to the RunExecutableListener class.
Original NVD description (English source)
Hardcoded credentials in the Basic Authentication setup tool (bin/solr auth enable) in Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0 allows a remote attacker to gain full administrative access to the cluster via publicly known default credentials installed silently alongside the user-specified account. As an immediate workaround without upgrading, delete the template users (superadmin, admin, search, index) from security.json or change their passwords. The future, not yet released, versions 9.11.0 and 10.1.0 will not be vulnerable, and it will be enough to upgrade to solve the issue. Not affected: * Clusters where bin/solr auth enable was not used to bootstrap BasicAuth * Clusters where template users have been assigned strong passwords after bootstrap
Vulnerability data from NVD (NIST) · CISA KEV · EPSS