Total
33 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2019-12401 | 1 Apache | 1 Solr | 2023-02-28 | 5.0 MEDIUM | 7.5 HIGH |
| Solr versions 1.3.0 to 1.4.1, 3.1.0 to 3.6.2 and 4.0.0 to 4.10.4 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. | |||||
| CVE-2021-33813 | 5 Apache, Debian, Fedoraproject and 2 more | 6 Solr, Tika, Debian Linux and 3 more | 2023-02-28 | 5.0 MEDIUM | 7.5 HIGH |
| An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to cause a denial of service via a crafted HTTP request. | |||||
| CVE-2013-6408 | 1 Apache | 1 Solr | 2023-02-12 | 6.4 MEDIUM | N/A |
| The DocumentAnalysisRequestHandler in Apache Solr before 4.3.1 does not properly use the EmptyEntityResolver, which allows remote attackers to have an unspecified impact via XML data containing an external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue. NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-6407. | |||||
| CVE-2013-6397 | 1 Apache | 1 Solr | 2023-02-12 | 4.3 MEDIUM | N/A |
| Directory traversal vulnerability in SolrResourceLoader in Apache Solr before 4.6 allows remote attackers to read arbitrary files via a .. (dot dot) or full pathname in the tr parameter to solr/select/, when the response writer (wt parameter) is set to XSLT. NOTE: this can be leveraged using a separate XXE (XML eXternal Entity) vulnerability to allow access to files across restricted network boundaries. | |||||
| CVE-2020-9492 | 2 Apache, Oracle | 3 Hadoop, Solr, Financial Services Crime And Compliance Management Studio | 2022-12-06 | 6.5 MEDIUM | 8.8 HIGH |
| In Apache Hadoop 3.2.0 to 3.2.1, 3.0.0-alpha1 to 3.1.3, and 2.0.0-alpha to 2.10.0, WebHDFS client might send SPNEGO authorization header to remote URL without proper verification. | |||||
| CVE-2021-44548 | 2 Apache, Microsoft | 2 Solr, Windows | 2022-08-09 | 6.8 MEDIUM | 9.8 CRITICAL |
| 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. | |||||
| CVE-2021-28163 | 5 Apache, Eclipse, Fedoraproject and 2 more | 23 Ignite, Solr, Jetty and 20 more | 2022-05-12 | 4.0 MEDIUM | 2.7 LOW |
| In Eclipse Jetty 9.4.32 to 9.4.38, 10.0.0.beta2 to 10.0.1, and 11.0.0.beta2 to 11.0.1, if a user uses a webapps directory that is a symlink, the contents of the webapps directory is deployed as a static webapp, inadvertently serving the webapps themselves and anything else that might be in that directory. | |||||
| CVE-2017-12629 | 4 Apache, Canonical, Debian and 1 more | 5 Solr, Ubuntu Linux, Debian Linux and 2 more | 2022-04-19 | 7.5 HIGH | 9.8 CRITICAL |
| Remote code execution occurs in Apache Solr before 7.1 with Apache Lucene before 7.1 by exploiting XXE in conjunction with use of a Config API add-listener command to reach the RunExecutableListener class. Elasticsearch, although it uses Lucene, is NOT vulnerable to this. Note that the XML external entity expansion vulnerability occurs in the XML Query Parser which is available, by default, for any query request with parameters deftype=xmlparser and can be exploited to upload malicious data to the /upload request handler or as Blind XXE using ftp wrapper in order to read arbitrary local files from the Solr server. Note also that the second vulnerability relates to remote code execution using the RunExecutableListener available on all affected versions of Solr. | |||||
| CVE-2021-29262 | 1 Apache | 1 Solr | 2022-04-01 | 4.3 MEDIUM | 7.5 HIGH |
| 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. | |||||
| CVE-2020-13957 | 1 Apache | 1 Solr | 2022-02-22 | 7.5 HIGH | 9.8 CRITICAL |
| Apache Solr versions 6.6.0 to 6.6.6, 7.0.0 to 7.7.3 and 8.0.0 to 8.6.2 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. | |||||
| CVE-2019-17558 | 2 Apache, Oracle | 2 Solr, Primavera Unifier | 2022-02-19 | 4.6 MEDIUM | 7.5 HIGH |
| Apache Solr 5.0.0 to Apache Solr 8.3.1 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). | |||||
| CVE-2020-27223 | 5 Apache, Debian, Eclipse and 2 more | 16 Nifi, Solr, Spark and 13 more | 2021-09-16 | 4.3 MEDIUM | 5.3 MEDIUM |
| In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values. | |||||
| CVE-2021-27905 | 1 Apache | 1 Solr | 2021-09-16 | 7.5 HIGH | 9.8 CRITICAL |
| The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr 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. This problem affects essentially all Solr versions prior to it getting fixed in 8.8.2. | |||||
| CVE-2019-0193 | 1 Apache | 1 Solr | 2021-07-30 | 9.0 HIGH | 7.2 HIGH |
| In Apache Solr, 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. | |||||
| CVE-2021-29943 | 1 Apache | 1 Solr | 2021-06-08 | 6.4 MEDIUM | 9.1 CRITICAL |
| 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. | |||||
| CVE-2020-13941 | 1 Apache | 1 Solr | 2021-03-24 | 6.5 MEDIUM | 8.8 HIGH |
| Reported in SOLR-14515 (private) and fixed in SOLR-14561 (public), released in Solr version 8.6.0. The Replication handler (https://lucene.apache.org/solr/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. | |||||
| CVE-2017-3164 | 1 Apache | 1 Solr | 2020-12-09 | 5.0 MEDIUM | 7.5 HIGH |
| Server Side Request Forgery in Apache Solr, versions 1.3 until 7.6 (inclusive). Since the "shards" parameter does not have a corresponding whitelist mechanism, a remote attacker with access to the server could make Solr perform an HTTP GET request to any reachable URL. | |||||
| CVE-2019-0192 | 2 Apache, Netapp | 2 Solr, Storage Automation Store | 2020-12-09 | 7.5 HIGH | 9.8 CRITICAL |
| In Apache Solr versions 5.0.0 to 5.5.5 and 6.0.0 to 6.6.5, the Config API allows to configure the 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. | |||||
| CVE-2019-12409 | 2 Apache, Linux | 2 Solr, Linux Kernel | 2020-07-23 | 7.5 HIGH | 9.8 CRITICAL |
| 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. 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. | |||||
| CVE-2018-11802 | 1 Apache | 1 Solr | 2020-04-03 | 4.0 MEDIUM | 4.3 MEDIUM |
| In Apache Solr, the cluster can be partitioned into multiple collections and only a subset of nodes actually host any given collection. However, if a node receives a request for a collection it does not host, it proxies the request to a relevant node and serves the request. Solr bypasses all authorization settings for such requests. This affects all Solr versions prior to 7.7 that use the default authorization mechanism of Solr (RuleBasedAuthorizationPlugin). | |||||