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:
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.
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:
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.
You will find more security related information on our Wiki: https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity
Below is a list of already announced CVE vulnerabilities. These are also available as an ATOM feed:
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
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:
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
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:
Solr 8.11.1
or greater (when available), which will include an updated version (>= 2.16.0
) of the Log4J dependency.solr.in.sh
file to include:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
solr.in.cmd
file to include:
set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
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
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:
Solr 8.8.2
or greater.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
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:
Solr 8.8.2
or greater.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
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:
Solr 8.8.2
or greater.Credit: Geza Nagy
References: SOLR-15233: CVE-2021-29943: Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections
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:
configset.upload.enabled
to false
(see docs)Solr 8.6.3
or greater.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
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:
Mitigation: Upgrade to Solr 8.6, and/or ensure only trusted clients can make requests of Solr's replication handler.
Credit: Matei "Mal" Badanoiu
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:
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
Severity: Medium
Vendor:
The Apache Software Foundation
Versions Affected:
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:
Credit:
Matei "Mal" Badanoiu
References:
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
Severity: High
Vendor:
The Apache Software Foundation
Versions Affected:
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:
Credit:
Michael Stepankin (JPMorgan Chase)
References:
Severity: High
Vendor:
The Apache Software Foundation
Versions Affected:
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:
Credit:
Michael Stepankin
References:
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:
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.
id | versions | jars | state | detail |
---|---|---|---|---|
CVE-2022-33980 | < 9.1 | commons-configuration2-2.7.jar | not affected | Solr uses commons-configuration2 for "hadoop-auth" only (for Kerberos). It is only used for loading Hadoop configuration files that would only ever be provided by trusted administrators, not externally (untrusted). |
CVE-2022-42889 | < 9.1 | commons-text-1.9.jar | not affected | Solr uses commons-text directly (StringEscapeUtils.escapeEcmaScript) in LoadAdminUiServlet that is not vulnerable. Solr also has a "hadoop-auth" module that uses Apache Hadoop which uses commons-text through commons-configuration2. For Solr, the concern is limited to loading Hadoop configuration files that would only ever be provided by trusted administrators, not externally (untrusted). |
CVE-2022-25168 | < 9.1 | hadoop-common-3.2.2.jar | not affected | The vulnerable code won't be used by Solr because Solr only is only using HDFS as a client. |
CVE-2021-44832 | 7.4-8.11.1 | log4j-core-2.14.1.jar, log4j-core-2.16.0.jar | not affected | Solr's default log configuration doesn't use JDBCAppender and we don't imagine a user would want to use it or other obscure appenders. |
CVE-2021-45105, CVE-2021-45046 | 7.4-8.11.1 | log4j-core-2.14.1.jar, log4j-core-2.16.0.jar | not affected | The MDC data used by Solr are for the collection, shard, replica, core and node names, and a potential trace id, which are all sanitized. Furthermore, Solr's default log configuration doesn't use double-dollar-sign and we don't imagine a user would want to do that. |
CVE-2020-13955 | 8.1.0- today | avatica-core-1.13.0.jar, calcite-core-1.18.0.jar | not affected | Solr's SQL adapter does not use the vulnerable class "HttpUtils". Calcite only used it to talk to Druid or Splunk. |
CVE-2018-10237 | 5.4.0-today | carrot2-guava-18.0.jar | not affected | Only used with the Carrot2 clustering engine. |
CVE-2014-0114 | 4.9.0-7.5.0 | commons-beanutils-1.8.3.jar | not affected | This is only used at compile time and it cannot be used to attack Solr. Since it is generally unnecessary, the dependency has been removed as of 7.5.0. See SOLR-12617. |
CVE-2019-10086 | 8.0.0-8.3.0 | commons-beanutils-1.9.3.jar | not affected | While commons-beanutils was removed in 7.5, it was added back in 8.0 in error and removed again in 8.3. The vulnerable class was not used in any Solr code path. This jar remains a dependency of both Velocity and hadoop-common, but Solr does not use it in our implementations. |
CVE-2012-2098, CVE-2018-1324, CVE-2018-11771 | 4.6.0-today | commons-compress (only as part of Ant 1.8.2) | not affected | Only used in test framework and at build time. |
CVE-2018-1000632 | 4.6.0-today | dom4j-1.6.1.jar | not affected | Only used in Solr tests. |
CVE-2018-10237 | 4.6.0-today | guava-*.jar | not affected | Only used in tests. |
CVE-2017-15718 | 6.6.1-7.6.0 | hadoop-auth-2.7.4.jar, hadoop-hdfs-2.7.4.jar (all Hadoop) | not affected | Does not impact Solr because Solr uses Hadoop as a client library. |
CVE-2017-14952 | 6.0.0-7.5.0 | icu4j-56.1.jar, icu4j-59.1.jar | not affected | Issue applies only to the C++ release of ICU and not ICU4J, which is what Lucene uses. ICU4J is at v63.2 as of Lucene/Solr 7.6.0 |
CVE-2017-15095, CVE-2017-17485, CVE-2017-7525, CVE-2018-5968, CVE-2018-7489, CVE-2019-12086, CVE-2019-12384, CVE-2018-12814, CVE-2019-14379, CVE-2019-14439, CVE-2020-35490, CVE-2020-35491, CVE-2021-20190, CVE-2019-14540, CVE-2019-16335 | 4.7.0-today | jackson-databind-*.jar | not affected | These CVEs, and most of the known jackson-databind CVEs since 2017, are all related to problematic 'gadgets' that could be exploited during deserialization of untrusted data. The Jackson developers described 4 conditions that must be met in order for a problematic gadget to be exploited. See https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062. Solr's use of jackson-databind does not meet 1 of the 4 conditions described which makes these CVEs unexploitable. The specific condition that Solr does not meet is the 3rd one: 'Enable polymorphic type handling' Solr does not include any polymorphic type handling, and Solr does not configure jackson-databind de/serialization to expect or include class names in serialized JSON. Two CVEs, 2019-14540 & 2019-16335, are related to HikariConfig and HikariDataSource classes, neither of which are used in Solr's code base. |
CVE-2019-10241, CVE-2019-10247 | 7.7.0-8.2 | jetty-9.4.14 | not affected | Solr upgraded to Jetty 9.4.19 for the 8.2 release. Additionally, the path to exploit these vulnerabilities was fixed in 8.1 and 7.7.2. Earlier versions can manually patch their configurations as described in SOLR-13409. |
CVE-2020-27218 | 7.3.0-8.8.0 | jetty-9.4.0 to 9.4.34 | not affected | Only exploitable through use of Jetty's GzipHandler, which is only implemented in Embedded Solr Server. |
CVE-2020-27223 | 7.3.0-present | jetty-9.4.6 to 9.4.36 | not affected | Only exploitable if Solr's webapp directory is deployed as a symlink, which is not Solr's default. |
CVE-2021-33813 | to present | jdom-*.jar | not affected | JDOM is only used in Solr Cell, which should not be used in production which makes the vulnerability unexploitable. It is a dependency of Apache Tika, which has analyzed the issue and determined the vulnerability is limited to two libraries not commonly used in search applications, see TIKA-3488 for details. Since Tika should be used outside of Solr, use a version of Tika which updates the affected libraries if concerned about exposure to this issue. |
CVE-2018-1000056 | 4.6.0-7.6.0 | junit-4.10.jar | not affected | JUnit only used in tests; CVE only refers to a Jenkins plugin not used by Solr. |
CVE-2014-7940, CVE-2016-6293, CVE-2016-7415, CVE-2017-14952, CVE-2017-17484, CVE-2017-7867, CVE-2017-7868 | 7.3.1 | lucene-analyzers-icu-7.3.1.jar | not affected | All of these issues apply to the C++ release of ICU and not ICU4J, which is what Lucene uses. |
CVE-2019-16869 | 8.2-8.3 | netty-all-4.1.29.Final.jar | not affected | This is not included in Solr but is a dependency of ZooKeeper 3.5.5. The version was upgraded in ZooKeeper 3.5.6, included with Solr 8.3. The specific classes mentioned in the CVE are not used in Solr (nor in ZooKeeper as far as the Solr community can determine). |
CVE-2017-14868, CVE-2017-14949 | 5.2.0-today | org.restlet-2.3.0.jar | not affected | Solr should not be exposed outside a firewall where bad actors can send HTTP requests. These two CVEs specifically involve classes (SimpleXMLProvider and XmlRepresentation, respectively) that Solr does not use in any code path. |
CVE-2015-5237 | 6.5.0-today | protobuf-java-3.1.0.jar | not affected | Dependency for Hadoop and Calcite. ?? |
CVE-2018-1471 | 5.4.0-7.7.2, 8.0-8.3 | simple-xml-2.7.1.jar | not affected | Dependency of Carrot2 and used during compilation, not at runtime (see SOLR-769. This .jar was replaced in Solr 8.3 and backported to 7.7.3 (see SOLR-13779). |
CVE-2018-8088 | 4.x-today | slf4j-api-1.7.24.jar, jcl-over-slf4j-1.7.24.jar, jul-to-slf4j-1.7.24.jar | not affected | The reported CVE impacts org.slf4j.ext.EventData, which is not used in Solr. |
CVE-2018-1335 | 7.3.1-7.5.0 | tika-core.1.17.jar | not affected | Solr does not run tika-server, so this is not a problem. |
CVE- | 7.3.1-today | tika-core.*.jar | not affected | All Tika issues that could be Solr vulnerabilities would only be exploitable if untrusted files are indexed with SolrCell. This is not recommended in production systems, so Solr does not consider these valid CVEs for Solr. |
CVE- | 6.6.2-today | velocity-tools-2.0.jar | not affected | Solr does not ship a Struts jar. This is a transitive POM listing and not included with Solr (see comment in SOLR-2849). |
CVE-2016-6809, CVE-2018-1335, CVE-2018-1338, CVE-2018-1339 | 5.5.5, 6.2.0-today | vorbis-java-tika-0.8.jar | not affected | See https://github.com/Gagravarr/VorbisJava/issues/30; reported CVEs are not related to OggVorbis at all. |
CVE-2012-0881 | ~2.9-today | xercesImpl-2.9.1.jar | not affected | Only used in Lucene Benchmarks and Solr tests. |