CVE-2021-44548: 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 [email protected].

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-44548

2021-12-18

Apache Solr information disclosure vulnerability through DataImportHandler

CVE-2021-44228

2021-12-10

Apache Solr affected by Apache Log4J CVE-2021-44228

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

2021-12-18, CVE-2021-44548: Apache Solr information disclosure vulnerability through DataImportHandler ¶

Severity:
Moderate

Versions Affected:
All versions prior to 8.11.1. Affected platforms: Windows.

Description:
An Improper Input Validation vulnerability in DataImportHandler of Apache Solr allows an attacker to provide a Windows UNC path resulting in an SMB network call being made from the Solr host to another host on the network. If the attacker has wider access to the network, this may lead to 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

This issue affects all Apache Solr versions prior to 8.11.1. This issue only affects Windows.

Mitigation:
Upgrade to Solr 8.11.1, and/or ensure only trusted clients can make requests to Solr’s DataImport handler.

Credit:
Apache Solr would like to thank LaiHan of Nsfocus security team for reporting the issue

References:
Jira issue SOLR-15826

2021-12-10, Apache Solr affected by Apache Log4J CVE-2021-44228 ¶

Severity: Critical

Versions Affected: 7.4.0 to 7.7.3, 8.0.0 to 8.11.0

Description: Apache Solr releases prior to 8.11.1 were using a bundled version of the Apache Log4J library vulnerable to RCE. For full impact and additional detail consult the Log4J security page.

Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7 through 7.3) use Log4J 1.2.17 which may be vulnerable for installations using non-default logging configurations that include the JMS Appender, see https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 for discussion.

Solr’s Prometheus Exporter uses Log4J as well but it does not log user input or data, so we don’t see a risk there.

Apache Solr releases are not vulnerable to the followup CVE-2021-45046 and CVE-2021-45105, because the MDC patterns used by Solr are for the collection, shard, replica, core and node names, and a potential trace id, which are all sanitized and injected into log files with "%X". Passing system property log4j2.formatMsgNoLookups=true (as described below) is suitable to mitigate.

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

• Upgrade to Solr 8.11.1 or greater (when available), which will include an updated version (>= 2.16.0) of the Log4J dependency.
• If you are using Solr’s official docker image, it has already been mitigated in all versions listed as supported on Docker Hub: https://hub.docker.com/_/solr. You may need to re-pull the image.
• Manually update the version of Log4J on your runtime classpath and restart your Solr application.
• (Linux/MacOS) Edit your solr.in.sh file to include: SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
• (Windows) Edit your solr.in.cmd file to include: set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
• Follow any of the other mitgations listed at https://logging.apache.org/log4j/2.x/security.html

References: https://logging.apache.org/log4j/2.x/security.html

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:

• https://issues.apache.org/jira/browse/SOLR-13971
• https://issues.apache.org/jira/browse/SOLR-14025
• https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity

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:

• https://issues.apache.org/jira/browse/SOLR-13750
• https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity

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:

• https://issues.apache.org/jira/browse/SOLR-13669
• https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity

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:

• https://issues.apache.org/jira/browse/SOLR-13301
• https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity

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:

• https://issues.apache.org/jira/browse/SOLR-12770
• https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity

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