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@lucene.apache.org or alternatively file a private security issue in Solr JIRA.

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-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
2017-10-18 Several critical vulnerabilities discovered in Apache Solr (XXE & RCE)
2017-10-12 Please secure your Apache Solr servers since a zero-day exploit has been reported on a public mailing list
CVE-2017-9803 2017-09-18 Security vulnerability in kerberos delegation token functionality**
CVE-2017-7660 2017-07-07 Security Vulnerability in secure inter-node communication in Apache Solr**
CVE-2017-3163 2017-02-15 Apache Solr ReplicationHandler path traversal attack**
CVE-2014-3529 2014-08-18 Recommendation to update Apache POI in Apache Solr 4.8.0, 4.8.1, and 4.9.0 installations

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://lucene.apache.org/solr/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://wiki.apache.org/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://lucene.apache.org/solr/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:


2017-10-12, Please secure your Apache Solr servers since a zero-day exploit has been reported on a public mailing list

Please secure your Solr servers since a zero-day exploit has been reported on a public mailing list. This has been assigned a public CVE (CVE-2017-12629) which we will reference in future communication about resolution and mitigation steps.

Here is what we're recommending and what we're doing now:

  • Until fixes are available, all Solr users are advised to restart their Solr instances with the system property -Ddisable.configEdit=true. This will disallow any changes to be made to configurations via the Config API. This is a key factor in this vulnerability, since it allows GET requests to add the RunExecutableListener to the config. This is sufficient to protect you from this type of attack, but means you cannot use the edit capabilities of the Config API until the other fixes described below are in place. Users are also advised to remap the XML Query Parser to another parser to mitigate the XXE vulnerability. For example, adding the following to the solrconfig.xml file maps the xmlparser to the edismax parser: <queryParser name="xmlparser" class="solr.ExtendedDismaxQParserPlugin"/>.

  • A new release of Lucene/Solr was in the vote phase, but we have now pulled it back to be able to address these issues in the upcoming 7.1 release. We will also determine mitigation steps for users on earlier versions, which may include a 6.6.2 release for users still on 6.x.

  • The RunExecutableListener will be removed in 7.1. It was previously used by Solr for index replication but has been replaced and is no longer needed.

  • The XML Parser will be fixed and the fixes will be included in the 7.1 release.

  • The 7.1 release was already slated to include a change to disable the stream.body parameter by default, which will further help protect systems.


2017-09-18, CVE-2017-9803: Security vulnerability in kerberos delegation token functionality**

CVE-2017-9803: Security vulnerability in kerberos delegation token functionality

Severity: Important

Vendor:
The Apache Software Foundation

Versions Affected:
Solr 6.2.0 to 6.6.0

Description:

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.

The vulnerability is fixed from Solr 6.6.1 onwards.

Mitigation:
6.x users should upgrade to 6.6.1

Credit:
This issue was discovered by Hrishikesh Gadre of Cloudera Inc.

References:


2017-07-07, CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr**

CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr

Severity: Important

Vendor:
The Apache Software Foundation

Versions Affected:

  • Solr 5.3 to 5.5.4
  • Solr 6.0 to 6.5.1

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

Mitigation:

Credit:
This issue was discovered by Noble Paul of Lucidworks Inc.

References:


2017-02-15, CVE-2017-3163: Apache Solr ReplicationHandler path traversal attack**

CVE-2017-3163: Apache Solr ReplicationHandler path traversal attack

Severity: Moderate

Vendor:
The Apache Software Foundation

Versions Affected:
Solr 1.4 to 6.4.0

Description:
When using the Index Replication feature, Solr nodes can pull index files from a master/leader node using an HTTP API which accepts a file name. However, Solr 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.

Mitigation:

  • 6.x users should upgrade to 6.4.1
  • 5.x users should upgrade to 5.5.4
  • 4.x, 3.x and 1.4 users should upgrade to a supported version of Solr or setup proper firewalling, or disable the ReplicationHandler if not in use.

Credit:
This issue was discovered by Hrishikesh Gadre of Cloudera Inc.

References:


2014-08-18, CVE-2014-3529, CVE-2014-3574: Recommendation to update Apache POI in Apache Solr 4.8.0, 4.8.1, and 4.9.0 installations

Apache Solr versions 4.8.0, 4.8.1, 4.9.0 bundle Apache POI 3.10-beta2 with its binary release tarball. This version (and all previous ones) of Apache POI are vulnerable to the following issues:

CVE-2014-3529: XML External Entity (XXE) problem in Apache POI's OpenXML parser

Information disclosure: Apache POI uses Java's XML components to parse OpenXML files produced by Microsoft Office products (DOCX, XLSX, PPTX,...). Applications that accept such files from end-users are vulnerable to XML External Entity (XXE) attacks, which allows remote attackers to bypass security restrictions and read arbitrary files via a crafted OpenXML document that provides an XML external entity declaration in conjunction with an entity reference.

CVE-2014-3574: XML Entity Expansion (XEE) problem in Apache POI's OpenXML parser

Denial of service: Apache POI uses Java's XML components and Apache Xmlbeans to parse OpenXML files produced by Microsoft Office products (DOCX, XLSX, PPTX,...). Applications that accept such files from end-users are vulnerable to XML Entity Expansion (XEE) attacks ("XML bombs"), which allows remote hackers to consume large amounts of CPU resources.

The Apache POI PMC released a bugfix version (3.10.1) today.

Solr users are affected by these issues, if they enable the "Apache Solr Content Extraction Library (Solr Cell)" contrib module from the folder "contrib/extraction" of the release tarball.

Users of Apache Solr are strongly advised to keep the module disabled if they don't use it. Alternatively, users of Apache Solr 4.8.0, 4.8.1, or 4.9.0 can update the affected libraries by replacing the vulnerable JAR files in the distribution folder. Users of previous versions have to update their Solr release first, patching older versions is impossible.

To replace the vulnerable JAR files follow these steps:

  • Download the Apache POI 3.10.1 binary release.

  • Unzip the archive.

  • Delete the following files in your "solr-4.X.X/contrib/extraction/lib" folder:

    • poi-3.10-beta2.jar
    • poi-ooxml-3.10-beta2.jar
    • poi-ooxml-schemas-3.10-beta2.jar
    • poi-scratchpad-3.10-beta2.jar
    • xmlbeans-2.3.0.jar
  • Copy the following files from the base folder of the Apache POI distribution to the "solr-4.X.X/contrib/extraction/lib" folder:

    • poi-3.10.1-20140818.jar
    • poi-ooxml-3.10.1-20140818.jar
    • poi-ooxml-schemas-3.10.1-20140818.jar
    • poi-scratchpad-3.10.1-20140818.jar
  • Copy "xmlbeans-2.6.0.jar" from POI's "ooxml-lib/" folder to the "solr-4.X.X/contrib/extraction/lib" folder.

  • Verify that the "solr-4.X.X/contrib/extraction/lib" no longer contains any files with version number "3.10-beta2".

  • Verify that the folder contains one xmlbeans JAR file with version 2.6.0.

If you just want to disable extraction of Microsoft Office documents, delete the files above and don't replace them. "Solr Cell" will automatically detect this and disable Microsoft Office document extraction.

Coming versions of Apache Solr will have the updated libraries bundled.