Package Instance

Incorrect Authorization
When using `ConfigurableInternodeAuthHadoopPlugin` for authentication, Apache Solr would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.

Improper Restriction of XML External Entity Reference
This vulnerability in Apache Solr relates to an XML external entity expansion (XXE) in Solr config files.

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.

Apache Solr can leak certain passwords due to System Property redaction logic inconsistencies
Insufficiently Protected Credentials vulnerability in Apache Solr.

This issue affects Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0.
One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name.
There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint.
This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI.

This /admin/info/properties endpoint is protected under the "config-read" permission.
Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission.
Users are recommended to upgrade to version 9.3.0 or 8.11.3, both of which fix the issue.
A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps".
By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password".

Users who cannot upgrade can also use the following Java system property to fix the issue:
`-Dsolr.redaction.system.pattern=.*(password|secret|basicauth).*`

Insufficiently Protected Credentials
When starting Apache Solr, configured with the `SaslZkACLProvider` or `VMParamsAllAndReadonlyDigestZkACLProvider` and no existing `security.json` `znode`, if the optional read-only user is configured then Solr would not treat that node as a sensitive path and would allow it to be readable. Additionally, with any `ZkACLProvider`, if the `security.json` is already present, Solr will not automatically update the ACLs.

Incorrect Authorization in Apache Solr
Apache Solr versions 6.6.0 to 6.6.6, 7.0.0 to 7.7.3 and 8.0.0 to 8.6.2 prevents some features considered dangerous (which could be used for remote code execution) to be configured in a ConfigSet that's uploaded via API without authentication/authorization. The checks in place to prevent such features can be circumvented by using a combination of UPLOAD/CREATE actions. This issue is patched in 8.6.3.

Server-Side Request Forgery (SSRF) in org.apache.solr:solr-core
Server Side Request Forgery in Apache Solr, versions 1.3 until 7.6 (inclusive). Since the "shards" parameter does not have a corresponding whitelist mechanism, a remote attacker with access to the server could make Solr perform an HTTP GET request to any reachable URL.

Deserialization of Untrusted Data
In Apache Solr versions, the Config API allows to configure the JMX server via an HTTP POST request. By pointing it to a malicious RMI server, an attacker could take advantage of Solr's unsafe deserialization to trigger remote code execution on the Solr side.