Package Instance

Unrestricted Upload of File with Dangerous Type
Apache Solr contain an insecure setting for the `ENABLE_REMOTE_JMX_OPTS` configuration option in the default `solr. then JMX monitoring will be enabled and exposed on `RMI_PORT` (`default=18983`), without any authentication. If this port is opened for inbound traffic in your firewall, then anyone with network access to your Solr nodes will be able to access JMX, which may in turn allow them to upload malicious code for execution on the Solr server.

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.
The Solr Metrics API publishes all unprotected environment variables available to each Apache Solr instance. Users are able to specify which environment variables to hide, however, the default list is designed to work for known secret Java system properties. Environment variables cannot be strictly defined in Solr, like Java system properties can be, and may be set for the entire host, unlike Java system properties which are set per-Java-proccess.

The Solr Metrics API is protected by the "metrics-read" permission.
Therefore, Solr Clouds with Authorization setup will only be vulnerable via users with the "metrics-read" permission.
This issue affects Apache Solr: from 9.0.0 before 9.3.0.

Users are recommended to upgrade to version 9.3.0 or later, in which environment variables are not published via the Metrics API.

Insecure Default Initialization of Resource vulnerability in Apache Solr
New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name, are created without setting the "trusted" metadata.
ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to "trusted" ConfigSets that may not have been created with an Authenticated request.
"trusted" ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when the request that uploads the ConfigSet is Authenticated & Authorized.

This issue affects Apache Solr: from 6.6.0 before 8.11.4, from 9.0.0 before 9.7.0. This issue does not affect Solr instances that are secured via Authentication/Authorization.

Users are primarily recommended to use Authentication and Authorization when running Solr. However, upgrading to version 9.7.0, or 8.11.4 will mitigate this issue otherwise.

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.

Privilege escalation
Solr's Kerberos plugin can be configured to use delegation tokens, which allows an application to reuse the authentication of an end-user or another application. There are two issues with this functionality (when using `SecurityAwareZkACLProvider` type of ACL provider e.g. `SaslZkACLProvider`). Firstly, access to the security configuration can be leaked to users other than the solr super user. Secondly, malicious users can exploit this leaked configuration for privilege escalation to further expose/modify private data and/or disrupt operations in the Solr cluster.

Apache Solr: Insufficient file-access checking in standalone core-creation requests
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.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html  is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles.

Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores.  Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.