Solr^™ Security News¶

How to report a security issue

Published CVEs Detected by Scanners

Every CVE that is detected by a software scanner is by definition already public knowledge. That means the Solr PMC and the rest of the world probably already know about it.

To find a path forward in addressing a detected CVE we suggest the following process for fastest results:

1. Check further down this page to see if the CVE is listed as exploitable in Solr.
2. Check the officially published non-exploitable vulnerabilities list to see if the CVE is listed as not exploitable in Solr.
3. Search through the Solr users mailing list archive to see if anyone else has brought up this dependency CVE.
4. If no one has, then please do subscribe to the users mailing list and then send an email asking about the CVE.

Dos and Don'ts

• Please DO discuss the possible need for library upgrades on the user list.
• Please DO search Jira for the CVE number to see if we are addressing it already.
• Please DO create Jira issues and associated pull requests to propose and discuss upgrades of a single specific dependency.
• Please DO NOT attach a scan report, or paste output of a scan into Jira (just link the CVE instead)
• Please DO NOT email the security email below with a scan report it will be ignored.
• Please DO look into automating some of this with VEX and share your experience.

Use of Jira

Jira is for discussing specific development modifications. Any Jira that contains only scan report output, or references multiple dependencies at the same time is likely to be ignored/closed. The large number of folks sending us reports of things that are already known is a serious drag on our (volunteer) time so please search Jira before opening a new issue.

New Exploits You Discover in Solr

The Solr PMC greatly appreciates reports of new security vulnerabilities found in Solr itself or demonstrations of exploiting vulnerabilities via dependencies. It is important not to publish a previously unknown exploit, or exploit demonstration code on public mailing lists. Please disclose new exploits responsibly by following these ASF guidelines for reporting. The contact email for reporting newly discovered exploits in Solr is security@solr.apache.org.

Before reporting a new exploit ensure that you have tested it against an instance of Solr that is running a supported version and has been properly configured with:

1. Authentication - Exploits demonstrated without login waste our time because Solr is not meant to run such that the entire world has access to all of its APIs. Running without forcing users to log in is no more valid than running linux with a widely known default root password, or a database with a root account that has no password.
2. Authorization - It is not an exploit unless the authenticated user was configured with a role that should have prohibited the action, or the action should never be allowed for any user regardless of role. Your report should say why you think this action is not acceptable for the role(s) you tested it with.

VEX

Since the process of checking whether CVEs in dependencies of Solr affect your Solr deployment is tedious and error-prone, we are experimenting with sharing information about advisories that are known (not) to affect Solr in a machine-readable way.

File formats to share this information are called 'VEX' formats. A number of such formats are under active development, such as based on CycloneDX and CSAF.

We are currently providing vulnerability information in a CycloneDX JSON-based format here. We are very curious to hear about your experience, and to find out what is still missing to reduce the signal/noise ratio and make these tools more effective. We invite you to join the discussion at the security-discuss mailinglist or, if you prefer to collaborate in private, contact security@apache.org. It will likely be interesting to know what security scanning/reporting tool you are using, exactly on which artifacts, and if/how its vendor appears to support VEX. We'd be happy to work with you to see if we can provide this information in other variations or formats.

More information

You will find more security related information on our Wiki: https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity

Recent CVE reports for Apache Solr

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

2022-11-20, Apache Solr is vulnerable to CVE-2022-39135 via /sql handler ¶

Versions Affected: Solr 6.5 to 8.11.2 Solr 9.0

Description: Apache Calcite has a vulnerability, CVE-2022-39135, that is exploitable in Apache Solr in SolrCloud mode. If an untrusted user can supply SQL queries to Solr’s “/sql” handler (even indirectly via proxies / other apps), then the user could perform an XML External Entity (XXE) attack. This might have been exposed by some deployers of Solr in order for internal analysts to use JDBC based tooling, but would have unlikely been granted to wider audiences.

Impact: An XXE attack may lead to the disclosure of confidential data, denial of service, server side request forgery (SSRF), port scanning from the Solr node, and other system impacts.

Mitigation: Most Solr installations don’t make use of the SQL functionality. For such users, the standard Solr security advice of using a firewall should be adequate. Nonetheless, the functionality can be disabled. As of Solr 9, it has been modularized and thus became opt-in, so nothing is needed for Solr 9 users that don’t use it. Users not using SolrCloud can’t use the functionality at all. For other users that wish to disable it, you must register a request handler that masks the underlying functionality in solrconfig.xml like so:

  <requestHandler name="/sql" class="solr.NotFoundRequestHandler"/>

Users needing this SQL functionality are forced to upgrade to Solr 9.1. If Solr 8.11.3 is released, then it will be an option as well. Simply replacing Calcite and other JAR files may mostly work but could fail depending on the particulars of the query. Users interested in this or in patching their own versions of Solr should examine SOLR-16421 for a source patch.

Credit: Andreas Hubold at CoreMedia GmbH

References: https://nvd.nist.gov/vuln/detail/CVE-2022-39135 https://issues.apache.org/jira/browse/SOLR-16421

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.

Solr is not vulnerable to the followup CVE-2021-45046 and CVE-2021-45105. A listing of these and other CVEs with some justifications are listed in Solr's wiki: https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools

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

The Log4J security page refers to setting log4j2.formatMsgNoLookups=true as a "discredited" mitigation. In reality, it depends. We've looked at the root cause and audited the code paths that lead to the vulnerability, and we feel confident in this mitigation being sufficient for Solr. See https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz for discussion.

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

CVE reports for Apache Solr dependencies

Below is a list of CVE vulnerabilities in Apache Solr dependencies, and the state of their applicability to Solr.

We are currently experimenting with providing this information in a machine-readable VEX format and encourage you to participate.