It was found that Apache Solr would accept an object from an unauthenticated user that could be manipulated through subsequent post requests. An attacker could use this flaw to assemble an object that could permit execution of arbitrary code on the server.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr. This issue affects Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.

Solr Streaming Expressions allows users to extract data from other Solr Clouds, using a "zkHost" parameter.

When original SolrCloud is setup to use ZooKeeper credentials and ACLs, they will be sent to whatever "zkHost" the user provides.

An attacker could setup a server to mock ZooKeeper, that accepts ZooKeeper requests with credentials and ACLs and extracts the sensitive information, then send a streaming expression using the mock server's address in "zkHost".

Streaming Expressions are exposed via the "/streaming" handler, with "read" permissions.

Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.

From these versions on, only zkHost values that have the same server address (regardless of chroot), will use the given ZooKeeper credentials and ACLs when connecting.

This vulnerability in Apache Solr 6.0.0 to 6.6.3, 7.0.0 to 7.3.0 relates to an XML external entity expansion (XXE) in Solr config files (solrconfig.xml, schema.xml, managed-schema). In addition, Xinclude functionality provided in these config files is also affected in a similar way. The vulnerability can be used as XXE using file/ftp/http protocols in order to read arbitrary local files from the Solr server or the internal network. Users are advised to upgrade to either Solr 6.6.4 or Solr 7.3.1 releases both of which address the vulnerability. Once upgrade is complete, no other steps are required. Those releases only allow external entities and Xincludes that refer to local files / zookeeper resources below the Solr instance directory (using Solr's ResourceLoader); usage of absolute URLs is denied. Keep in mind, that external entities and XInclude are explicitly supported to better structure config files in large installations. Before Solr 6 this was no problem, as config files were not accessible through the APIs.

A flaw was found in the Apache Solr's Config API, where it would permit the configuration of the JMX server via an HTTP POST request. An attacker could use this flaw to direct traffic to a malicious RMI server, and then trigger remote code execution or conduct further attacks.

Apache Solr could allow a remote attacker to execute arbitrary code on the system, caused by the Schema Designer blindly trusting all configsets. An attacker could exploit his vulnerability to execute arbitrary code on the system.

Apache Solr could allow a remote authenticated attacker to obtain sensitive information, caused by system property redaction logic inconsistencies. By using the /admin/info/properties endpoint, an attacker could exploit his vulnerability to leak certain passwords.

Apache Solr could allow a remote attacker to upload arbitrary files, caused by the improper control of dynamically-managed code resources. By using Backup/Restore APIs, a remote attacker could exploit this vulnerability to upload a malicious file, which could allow the attacker to execute arbitrary code on the vulnerable system.

When using the Index Replication feature, Apache Solr nodes can pull index files from a master/leader node using an HTTP API which accepts a file name. However, Solr before 5.5.4 and 6.x before 6.4.1 did not validate the file name, hence it was possible to craft a special request involving path traversal, leaving any file readable to the Solr server process exposed. Solr servers protected and restricted by firewall rules and/or authentication would not be at risk since only trusted clients and users would gain direct HTTP access.

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. This can trick the nodes in cluster to believe that the malicious node is a member of the cluster. So, if Solr users have enabled BasicAuth authentication mechanism using the BasicAuthPlugin or if the user has implemented a custom Authentication plugin, which does not implement either "HttpClientInterceptorPlugin" or "HttpClientBuilderPlugin", his/her servers are vulnerable to this attack. Users who only use SSL without basic authentication or those who use Kerberos are not affected.