CVE-2026-22444
HighSummary
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.
Risk Assessment
The risk includes unauthorized access to filesystem data, the possibility of creating cores with unauthorized configurations, and on Windows environments potential disclosure of sensitive NTLM hashes, which could lead to further attacks.
Recommendation
It is recommended to upgrade Apache Solr to a patched version if available, and to restrict access to the "create core" API to trusted users only. Also review the "allowPaths" configuration to ensure it does not permit unauthorized access.
Other vulnerabilities in Apache Solr
See all- 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-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.
- CVE-2026-44825High
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.
Original NVD description (English source)
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 https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element . 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. Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users. This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.ap