Solr Security News

How to report a security issue

If you believe you have discovered a vulnerability in Solr, you may first want to consult the list of known false positives to make sure you are reporting a real vulnerability. Then please disclose responsibly by following these ASF guidelines for reporting.

You may file your request by email to security@solr.apache.org.

More information

You will find more security related information on our Wiki: https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity, such as information on how to treat the automated reports from security scanning tools.

Recent CVE reports for Apache Solr

Below is a list of already announced CVE vulnerabilities. These are also available as an ATOM feed:

CVE# Date Announcement
CVE-2021-27905 2021-04-12 SSRF vulnerability with the Replication handler
CVE-2021-29262 2021-04-12 Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings
CVE-2021-29943 2021-04-12 Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections
CVE-2020-13957 2020-10-12 The checks added to unauthenticated configset uploads in Apache Solr can be circumvented
CVE-2020-13941 2020-08-14 Apache Solr information disclosure vulnerability
CVE-2019-17558 2019-12-30 Apache Solr RCE through VelocityResponseWriter
CVE-2019-12409 2019-11-18 Apache Solr RCE vulnerability due to bad config default
CVE-2019-12401 2019-09-09 XML Bomb in Apache Solr versions prior to 5.0
2019-08-14 [ANNOUNCE] 8.1.1 and 8.2.0 users check ENABLE_REMOTE_JMX_OPTS setting
CVE-2019-0193 2019-07-31 Apache Solr, Remote Code Execution via DataImportHandler
CVE-2019-0192 2019-03-06 Deserialization of untrusted data via jmx.serviceUrl in Apache Solr
CVE-2017-3164 2019-02-12 SSRF issue in Apache Solr
CVE-2018-1308 2018-04-08 XXE attack through Apache Solr's DIH's dataConfig request parameter
CVE-2016-6809 2017-10-26 Java code execution for serialized objects embedded in MATLAB files parsed by Apache Solr using Tika
CVE-2017-9803 2017-10-18 Several critical vulnerabilities discovered in Apache Solr (XXE & RCE)

2021-04-12, CVE-2021-27905: SSRF vulnerability with the Replication handler

Severity: High

Versions Affected: 7.0.0 to 7.7.3 8.0.0 to 8.8.1

Description: The ReplicationHandler (normally registered at "/replication" under a Solr core) has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. To prevent a SSRF vulnerability, Solr ought to check these parameters against a similar configuration it uses for the "shards" parameter. Prior to this bug getting fixed, it did not.

Mitigation: Any of the following are enough to prevent this vulnerability:

  • Upgrade to Solr 8.8.2 or greater.
  • If upgrading is not an option, consider applying the patch in SOLR-15217
  • Ensure that any access to the replication handler is purely internal to Solr. Typically, it's only accessed externally for diagnostic/informational purposes.

Credit: Reported by Caolinhong(Skay) from QI-ANXIN Cert (QI-ANXIN Technology Group Inc.)

References: SOLR-15217: CVE-2021-27905: SSRF vulnerability with the Replication handler


2021-04-12, CVE-2021-29262: Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings

Severity: High

Versions Affected: 7.0.0 to 7.7.3 8.0.0 to 8.8.1

Description: When starting Apache Solr versions prior to 8.8.2, 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.

Mitigation: Any of the following are enough to prevent this vulnerability:

  • Manually set appropriate ACLs on /security.json znode.
  • Upgrade to Solr 8.8.2 or greater.
  • If upgrading is not an option, consider applying the patch in SOLR-15249
  • Ensure that any access to zookeeper is only by trusted application.

Credit: Timothy Potter and Mike Drob, Apple Cloud Services

References: SOLR-15249: CVE-2021-29262: Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings


2021-04-12, CVE-2021-29943: Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections

Severity: High

Versions Affected: 7.0.0 to 7.7.3 8.0.0 to 8.8.1

Description: When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.

Mitigation: Any of the following are enough to prevent this vulnerability:

  • Upgrade to Solr 8.8.2 or greater.
  • If upgrading is not an option, consider applying the patch in SOLR-15233
  • Use a different authentication plugin, such as the KerberosPlugin or HadoopAuthPlugin

Credit: Geza Nagy

References: SOLR-15233: CVE-2021-29943: Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections


2020-10-12, CVE-2020-13957: The checks added to unauthenticated configset uploads in Apache Solr can be circumvented

Severity: High

Versions Affected: 6.6.0 to 6.6.6 7.0.0 to 7.7.3 8.0.0 to 8.6.2

Description: Solr 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.

Mitigation: Any of the following are enough to prevent this vulnerability:

  • Disable UPLOAD command in ConfigSets API if not used by setting the system property: configset.upload.enabled to false (see docs)
  • Use Authentication/Authorization and make sure unknown requests aren't allowed (see docs)
  • Upgrade to Solr 8.6.3 or greater.
  • If upgrading is not an option, consider applying the patch in SOLR-14663
  • No Solr API, including the Admin UI, is designed to be exposed to non-trusted parties. Tune your firewall so that only trusted computers and people are allowed access

Credit: Tomás Fernández Löbbe, András Salamon

References: SOLR-14925: CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented


2020-08-14, CVE-2020-13941: Apache Solr information disclosure vulnerability

Severity: Medium

Versions Affected:
Before Solr 8.6. Some risks are specific to Windows.

Description: Reported in SOLR-14515 (private) and fixed in SOLR-14561 (public), released in Solr version 8.6.0. The Replication handler (https://solr.apache.org/guide/8_6/index-replication.html#http-api-commands-for-the-replicationhandler) allows commands backup, restore and deleteBackup. Each of these take a location parameter, which was not validated, i.e you could read/write to any location the solr user can access.

On a windows system SMB paths such as \10.0.0.99\share\folder may also be used, leading to:

  • The possibility of restoring another SolrCore from a server on the network (or mounted remote file system) may lead to:
    • Exposing search index data that the attacker should otherwise not have access to
    • Replacing the index data entirely by loading it from a remote file system that the attacker controls
  • Launching SMB attacks which may result in:
    • The exfiltration of sensitive data such as OS user hashes (NTLM/LM hashes),
    • In case of misconfigured systems, SMB Relay Attacks which can lead to user impersonation on SMB Shares or, in a worse-case scenario, Remote Code Execution

Mitigation: Upgrade to Solr 8.6, and/or ensure only trusted clients can make requests of Solr's replication handler.

Credit: Matei "Mal" Badanoiu


2019-12-30, CVE-2019-17558: Apache Solr RCE through VelocityResponseWriter

Severity: High

Vendor:
The Apache Software Foundation

Versions Affected: 5.0.0 to 8.3.1

Description:
The affected versions 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. A user defined configset could contain renderable, potentially malicious, templates. Parameter provided templates are disabled by default, but can be enabled by setting params.resource.loader.enabled by defining a response writer with that setting set to true. Defining a response writer requires configuration API access.

Solr 8.4 removed the params resource loader entirely, and only enables the configset-provided template rendering when the configset is trusted (has been uploaded by an authenticated user).

Mitigation:
Ensure your network settings are configured so that only trusted traffic communicates with Solr, especially to the configuration APIs.

Credit:
Github user s00py

References:


2019-11-18, CVE-2019-12409: Apache Solr RCE vulnerability due to bad config default

Severity: High

Vendor:
The Apache Software Foundation

Versions Affected:
Solr 8.1.1 and 8.2.0 for Linux

Description:
The 8.1.1 and 8.2.0 releases of Apache Solr contain an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option in the default solr.in.sh configuration file shipping with Solr.

Windows users are not affected.

If you use the default solr.in.sh file from the affected releases, 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.

The vulnerability is already public [1] and mitigation steps were announced on project mailing lists and news page [3] on August 14th, without mentioning RCE at that time.

Mitigation:
Make sure your effective solr.in.sh file has ENABLE_REMOTE_JMX_OPTS set to 'false' on every Solr node and then restart Solr. Note that the effective solr.in.sh file may reside in /etc/defaults/ or another location depending on the install. You can then validate that the 'com.sun.management.jmxremote*' family of properties are not listed in the "Java Properties" section of the Solr Admin UI, or configured in a secure way.

There is no need to upgrade or update any code.

Remember to follow the Solr Documentation's advice to never expose Solr nodes directly in a hostile network environment.

Credit:
Matei "Mal" Badanoiu
Solr JIRA user 'jnyryan' (John)

References:
[1] https://issues.apache.org/jira/browse/SOLR-13647
[3] https://solr.apache.org/news.html


2019-09-09, CVE-2019-12401: XML Bomb in Apache Solr versions prior to 5.0

Severity: Medium

Vendor:
The Apache Software Foundation

Versions Affected:

  • 1.3.0 to 1.4.1
  • 3.1.0 to 3.6.2
  • 4.0.0 to 4.10.4

Description:
Solr versions prior to 5.0.0 are vulnerable to an XML resource consumption attack (a.k.a. Lol Bomb) via it’s update handler. By leveraging XML DOCTYPE and ENTITY type elements, the attacker can create a pattern that will expand when the server parses the XML causing OOMs

Mitigation:

  • Upgrade to Apache Solr 5.0 or later.
  • Ensure your network settings are configured so that only trusted traffic is allowed to post documents to the running Solr instances.

Credit:
Matei "Mal" Badanoiu

References:


2019-08-14, [ANNOUNCE] 8.1.1 and 8.2.0 users check ENABLE_REMOTE_JMX_OPTS setting

Severity: Low

Versions Affected:
8.1.1 and 8.2.0 for Linux

Description:
It has been discovered [1] that the 8.1.1 and 8.2.0 releases contain a bad default
setting for the ENABLE_REMOTE_JMX_OPTS setting in the default solr.in.sh file
shipping with Solr.

Windows users and users with custom solr.in.sh files are not affected.

If you are using the default solr.in.sh file from the affected releases, then
JMX monitoring will be enabled and exposed on JMX_PORT (default = 18983),
without any authentication. So if your firewalls allows inbound traffic on
JMX_PORT, then anyone with network access to your Solr nodes will be able to
access monitoring data exposed over JMX.

Mitigation:
Edit solr.in.sh, set ENABLE_REMOTE_JMX_OPTS=false and restart Solr.
Alternatively wait for the future 8.3.0 release and upgrade.

References:
[1] https://issues.apache.org/jira/browse/SOLR-13647

2019-07-31, CVE-2019-0193: Apache Solr, Remote Code Execution via DataImportHandler

Severity: High

Vendor:
The Apache Software Foundation

Versions Affected:

  • 5.0.0 to 5.5.5
  • 6.0.0 to 6.6.5

Description:
The DataImportHandler, an optional but popular module to pull in data from databases and other sources, has a feature in which the whole DIH configuration can come from a request's "dataConfig" parameter. The debug mode of the DIH admin screen uses this to allow convenient debugging / development of a DIH config. Since a DIH config can contain scripts, this parameter is a security risk. Starting with version 8.2.0 of Solr, use of this parameter requires setting the Java System property enable.dih.dataConfigParam to true.

Mitigation:

  • Upgrade to 8.2.0 or later, which is secure by default.
  • or, edit solrconfig.xml to configure all DataImportHandler usages with an "invariants" section listing the "dataConfig" parameter set to am empty string.
  • Ensure your network settings are configured so that only trusted traffic communicates with Solr, especially to the DIH request handler. This is a best practice to all of Solr.

Credit:
Michael Stepankin (JPMorgan Chase)

References:


2019-03-06, CVE-2019-0192: Deserialization of untrusted data via jmx.serviceUrl in Apache Solr

Severity: High

Vendor:
The Apache Software Foundation

Versions Affected:

  • 5.0.0 to 5.5.5
  • 6.0.0 to 6.6.5

Description:
ConfigAPI allows to configure Solr's 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.

Mitigation:
Any of the following are enough to prevent this vulnerability:

  • Upgrade to Apache Solr 7.0 or later.
  • Disable the ConfigAPI if not in use, by running Solr with the system property “disable.configEdit=true”
  • If upgrading or disabling the Config API are not viable options, apply patch in [1] and re-compile Solr.
  • Ensure your network settings are configured so that only trusted traffic is allowed to ingress/egress your hosts running Solr.

Credit:
Michael Stepankin

References:


2019-02-12, CVE-2017-3164: SSRF issue in Apache Solr

Severity: High

Vendor:
The Apache Software Foundation

Versions Affected: Apache Solr versions from 1.3 to 7.6.0

Description:
The "shards" parameter does not have a corresponding whitelist mechanism, so it can request any URL.

Mitigation:
Upgrade to Apache Solr 7.7.0 or later. Ensure your network settings are configured so that only trusted traffic is allowed to ingress/egress your hosts running Solr.

Credit:
dk from Chaitin Tech

References:


2018-04-08, CVE-2018-1308: XXE attack through Apache Solr's DIH's dataConfig request parameter

CVE-2018-1308: XXE attack through Apache Solr's DIH's dataConfig request parameter

Severity: Major

Vendor:
The Apache Software Foundation

Versions Affected:

  • Solr 1.2 to 6.6.2
  • Solr 7.0.0 to 7.2.1

Description:
The details of this vulnerability were reported to the Apache Security mailing list.

This vulnerability relates to an XML external entity expansion (XXE) in the &dataConfig=<inlinexml> parameter of Solr's DataImportHandler. It 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. See [1] for more details.

Mitigation:
Users are advised to upgrade to either Solr 6.6.3 or Solr 7.3.0 releases both of which address the vulnerability. Once upgrade is complete, no other steps are required. Those releases disable external entities in anonymous XML files passed through this request parameter.

If users are unable to upgrade to Solr 6.6.3 or Solr 7.3.0 then they are advised to disable data import handler in their solrconfig.xml file and restart their Solr instances. Alternatively, if Solr instances are only used locally without access to public internet, the vulnerability cannot be used directly, so it may not be required to update, and instead reverse proxies or Solr client applications should be guarded to not allow end users to inject dataConfig request parameters. Please refer to [2] on how to correctly secure Solr servers.

Credit:
麦 香浓郁

References:

[1] https://issues.apache.org/jira/browse/SOLR-11971
[2] https://cwiki.apache.org/confluence/display/solr/SolrSecurity


2017-10-26, CVE-2016-6809: Java code execution for serialized objects embedded in MATLAB files parsed by Apache Solr using Tika

Severity: Important

Vendor:
The Apache Software Foundation

Versions Affected:

  • Solr 5.0.0 to 5.5.4
  • Solr 6.0.0 to 6.6.1
  • Solr 7.0.0 to 7.0.1

Description:
Apache Solr uses Apache Tika for parsing binary file types such as doc, xls, pdf etc. Apache Tika wraps the jmatio parser (https://github.com/gradusnikov/jmatio) to handle MATLAB files. The parser uses native deserialization on serialized Java objects embedded in MATLAB files. A malicious user could inject arbitrary code into a MATLAB file that would be executed when the object is deserialized.

This vulnerability was originally described at http://mail-archives.apache.org/mod_mbox/tika-user/201611.mbox/%3C2125912914.1308916.1478787314903%40mail.yahoo.com%3E

Mitigation:
Users are advised to upgrade to either Solr 5.5.5 or Solr 6.6.2 or Solr 7.1.0 releases which have fixed this vulnerability.

Solr 5.5.5 upgrades the jmatio parser to v1.2 and disables the Java deserialisation support to protect against this vulnerability.

Solr 6.6.2 and Solr 7.1.0 have upgraded the bundled Tika to v1.16.

Once upgrade is complete, no other steps are required.

References:


2017-10-18, Several critical vulnerabilities discovered in Apache Solr (XXE & RCE)

Severity:
Critical

Vendor:
The Apache Software Foundation

Versions Affected:

  • Solr 5.5.0 to 5.5.4
  • Solr 6.0.0 to 6.6.1
  • Solr 7.0.0 to 7.0.1

Description:
The details of this vulnerability were reported on public mailing lists. See https://s.apache.org/FJDl

The first vulnerability relates to XML external entity expansion in the XML Query Parser which is available, by default, for any query request with parameters deftype=xmlparser. This can be exploited to upload malicious data to the /upload request handler. It can also be used as Blind XXE using ftp wrapper in order to read arbitrary local files from the solr server.

The second vulnerability relates to remote code execution using the RunExecutableListener available on all affected versions of Solr.

At the time of the above report, this was a 0-day vulnerability with a working exploit affecting the versions of Solr mentioned in the previous section. However, mitigation steps were announced to protect Solr users the same day. See https://solr.apache.org/news.html#12-october-2017-please-secure-your-apache-solr-servers-since-a-zero-day-exploit-has-been-reported-on-a-public-mailing-list

Mitigation:
Users are advised to upgrade to either Solr 6.6.2 or Solr 7.1.0 releases both of which address the two vulnerabilities. Once upgrade is complete, no other steps are required.

If users are unable to upgrade to Solr 6.6.2 or Solr 7.1.0 then they are advised to restart their Solr instances with the system parameter -Ddisable.configEdit=true. This will disallow any changes to be made to your configurations via the Config API. This is a key factor in this vulnerability, since it allows GET requests to add the RunExecutableListener to your config. Users are also advised to re-map the XML Query Parser to another parser to mitigate the XXE vulnerability. For example, adding the following to the solrconfig.xml file re-maps the xmlparser to the edismax parser: <queryParser name="xmlparser" class="solr.ExtendedDismaxQParserPlugin"/>

Credit:

  • Michael Stepankin (JPMorgan Chase)
  • Olga Barinova (Gotham Digital Science)

References: