cve,link,title,description,vendor,products,score,severity,epss,cisa,article,ransomware,exploited,poc,trended,trended_no_1,published,trended_score
CVE-2024-45216,https://securityvulnerability.io/vulnerability/CVE-2024-45216,Improper Authentication Vulnerability in Apache Solr,"Improper Authentication vulnerability in Apache Solr.

Solr instances using the PKIAuthenticationPlugin, which is enabled by default when Solr Authentication is used, are vulnerable to Authentication bypass.
A fake ending at the end of any Solr API URL path, will allow requests to skip Authentication while maintaining the API contract with the original URL Path.
This fake ending looks like an unprotected API path, however it is stripped off internally after authentication but before API routing.


This issue affects Apache Solr: from 5.3.0 before 8.11.4, from 9.0.0 before 9.7.0.

Users are recommended to upgrade to version 9.7.0, or 8.11.4, which fix the issue.",Apache,Apache Solr,,,0.008960000239312649,false,false,false,false,,false,false,2024-10-16T08:15:00.000Z,0
CVE-2024-31391,https://securityvulnerability.io/vulnerability/CVE-2024-31391,Insertion of Sensitive Information into Log File Vulnerability Affects Solr Operator Versions 0.3.0-0.8.0,"Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator.

This issue affects all versions of the Apache Solr Operator from 0.3.0 through 0.8.0.

When asked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the ""solr"" and ""admin"" accounts for use by end-users, and a ""k8s-oper"" account which the operator uses for its own requests to Solr.
One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic.
By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well.
Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes ""event"" containing the username and password of the ""k8s-oper"" account.

Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the `.solrOptions.security.authenticationType=basic` option, and (2) required authentication be used on probes by setting `.solrOptions.security.probesRequireAuth=true`.

Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests.  Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting `.solrOptions.security.probesRequireAuth=false`.
",Apache,Apache Solr Operator,,,0.0004299999854993075,false,false,false,false,,false,false,2024-04-12T15:00:26.569Z,0
CVE-2023-50291,https://securityvulnerability.io/vulnerability/CVE-2023-50291,Insufficiently Protected Credentials vulnerability in Apache Solr,"A vulnerability in Apache Solr allows sensitive system properties to be exposed via the '/admin/info/properties' endpoint. This endpoint, which is intended to display Java system properties, is only designed to hide properties containing 'password' in their names. As a result, other sensitive properties, such as 'basicauth' and 'aws.secretKey', remain visible in the Solr Admin UI, potentially unauthorized access to crucial credentials. This affects users with 'config-read' permission in Solr Clouds with Authorization enabled. To mitigate the risk, users are advised to upgrade to Apache Solr versions 9.3.0 or 8.11.3 or apply specific Java system properties to enhance security.",Apache,Apache Solr,7.5,HIGH,0.0022299999836832285,false,false,false,false,,false,false,2024-02-09T17:29:32.882Z,0
CVE-2023-50292,https://securityvulnerability.io/vulnerability/CVE-2023-50292,Improper Permission Assignment in Apache Solr's Schema Designer Feature,"A vulnerability exists in the Schema Designer feature of Apache Solr, affecting several versions. The issue arises from an incorrect permission assignment for critical resources, allowing unauthenticated users to load external libraries in configSets. Although the feature was designed to facilitate easier configuration and testing of Schemas and configSets, it fails to validate the trust levels of these components. As a result, configSets created by unauthenticated users can be improperly leveraged, potentially leading to unauthorized remote code execution. Users are strongly encouraged to upgrade to version 9.3.0 to mitigate this vulnerability.",Apache,Apache Solr,7.5,HIGH,0.0022299999836832285,false,false,false,false,,false,false,2024-02-09T17:29:21.249Z,0
CVE-2023-50298,https://securityvulnerability.io/vulnerability/CVE-2023-50298,Exposure of Sensitive Information to Unauthorized Actor in Apache Solr,"A vulnerability exists in Apache Solr that allows an unauthorized actor to expose sensitive information due to the mishandling of ZooKeeper credentials in Streaming Expressions. This vulnerability impacts versions from 6.0.0 to 8.11.2 and for 9.0.0 versions prior to 9.4.1. When users extract data from other Solr Clouds using the 'zkHost' parameter, ZooKeeper credentials may inadvertently be sent to a potentially malicious server set up to simulate ZooKeeper. This enables an attacker to capture sensitive data by exploiting the streaming expression functionality. It is critical for users to upgrade to versions 8.11.3 or 9.4.1 to mitigate this risk, as the updates restrict credential usage to the same server address only.",Apache,Apache Solr,7.5,HIGH,0.0008900000248104334,false,false,false,false,,false,false,2024-02-09T17:29:07.889Z,0
CVE-2023-50386,https://securityvulnerability.io/vulnerability/CVE-2023-50386,"Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere Vulnerability in Apache Solr","A security vulnerability has been identified in Apache Solr that allows improper control of dynamically-managed code resources. Specifically, the ConfigSets API in affected versions permits the upload of Java jar and class files, which could lead to execution of malicious code if these files are saved in directories that Solr interfaces with during runtime. This presents a significant risk when backups save unauthorized configurations that may include potentially harmful executables, thereby compromising system integrity. Mitigation steps have been introduced in newer versions, restricting the upload of executable files to configSets and limiting backup storage directories to enhance security management.",Apache,Apache Solr,8.8,HIGH,0.8668299913406372,false,true,false,true,true,false,false,2024-02-09T17:28:51.290Z,0
CVE-2023-50290,https://securityvulnerability.io/vulnerability/CVE-2023-50290,Sensitive Information Exposure in Apache Solr Due to Unauthorized Actor Vulnerability,"Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr.
The Solr Metrics API publishes all unprotected environment variables available to each Apache Solr instance. Users are able to specify which environment variables to hide, however, the default list is designed to work for known secret Java system properties. Environment variables cannot be strictly defined in Solr, like Java system properties can be, and may be set for the entire host, unlike Java system properties which are set per-Java-proccess.

The Solr Metrics API is protected by the ""metrics-read"" permission.
Therefore, Solr Clouds with Authorization setup will only be vulnerable via users with the ""metrics-read"" permission.
This issue affects Apache Solr: from 9.0.0 before 9.3.0.

Users are recommended to upgrade to version 9.3.0 or later, in which environment variables are not published via the Metrics API.

",Apache,Apache Solr,6.5,MEDIUM,0.38561999797821045,false,false,false,false,,false,false,2024-01-15T09:32:44.532Z,0
CVE-2021-44548,https://securityvulnerability.io/vulnerability/CVE-2021-44548,Apache Solr information disclosure vulnerability through DataImportHandler,"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.",Apache,Apache Solr,9.8,CRITICAL,0.0029800001066178083,false,false,false,false,,false,false,2021-12-23T08:55:09.000Z,0
CVE-2021-29943,https://securityvulnerability.io/vulnerability/CVE-2021-29943,Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections,"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.",Apache,Apache Solr,9.1,CRITICAL,0.0023300000466406345,false,false,false,false,,false,false,2021-04-13T06:35:22.000Z,0
CVE-2021-29262,https://securityvulnerability.io/vulnerability/CVE-2021-29262,Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings,"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.",Apache,Apache Solr,7.5,HIGH,0.005940000060945749,false,false,false,false,,false,false,2021-04-13T06:35:21.000Z,0
CVE-2021-27905,https://securityvulnerability.io/vulnerability/CVE-2021-27905,SSRF vulnerability with the Replication handler,"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.",Apache,Apache Solr,9.8,CRITICAL,0.949400007724762,false,false,false,true,true,false,false,2021-04-13T06:35:20.000Z,0
CVE-2020-13957,https://securityvulnerability.io/vulnerability/CVE-2020-13957,,"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.",Apache,Apache Solr,9.8,CRITICAL,0.8191800117492676,false,false,false,true,true,false,false,2020-10-13T18:28:52.000Z,0
CVE-2020-13941,https://securityvulnerability.io/vulnerability/CVE-2020-13941,,"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.",Apache,Apache Solr,8.8,HIGH,0.0031900000758469105,false,false,false,false,,false,false,2020-08-17T12:16:37.000Z,0
CVE-2018-11802,https://securityvulnerability.io/vulnerability/CVE-2018-11802,,"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).",Apache,Apache Solr,4.3,MEDIUM,0.0006300000241026282,false,false,false,false,,false,false,2020-04-01T21:11:38.000Z,0
CVE-2019-17558,https://securityvulnerability.io/vulnerability/CVE-2019-17558,,"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).",Apache,Apache Solr,7.5,HIGH,0.9752500057220459,true,false,false,true,true,false,false,2019-12-30T16:36:08.000Z,0
CVE-2019-0193,https://securityvulnerability.io/vulnerability/CVE-2019-0193,,"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.",Apache,Apache Solr,7.2,HIGH,0.9299799799919128,true,false,false,true,true,false,false,2019-08-01T13:48:40.000Z,0
CVE-2017-3164,https://securityvulnerability.io/vulnerability/CVE-2017-3164,,"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.",Apache,Apache Solr,7.5,HIGH,0.04318000003695488,false,false,false,true,true,false,false,2019-03-08T21:29:00.000Z,0
CVE-2019-0192,https://securityvulnerability.io/vulnerability/CVE-2019-0192,,"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.",Apache,Apache Solr,9.8,CRITICAL,0.9417499899864197,false,false,false,true,true,false,false,2019-03-07T00:00:00.000Z,0
CVE-2018-8026,https://securityvulnerability.io/vulnerability/CVE-2018-8026,,"This vulnerability in Apache Solr 6.0.0 to 6.6.4 and 7.0.0 to 7.3.1 relates to an XML external entity expansion (XXE) in Solr config files (currency.xml, enumsConfig.xml referred from schema.xml, TIKA parsecontext config file). In addition, Xinclude functionality provided in these config files is also affected in a similar way. The vulnerability 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. The manipulated files can be uploaded as configsets using Solr's API, allowing to exploit that vulnerability.",Apache,Apache Solr,5.5,MEDIUM,0.0083600003272295,false,false,false,false,,false,false,2018-07-05T14:29:00.000Z,0
CVE-2018-8010,https://securityvulnerability.io/vulnerability/CVE-2018-8010,,"This vulnerability in Apache Solr 6.0.0 to 6.6.3, 7.0.0 to 7.3.0 relates to an XML external entity expansion (XXE) in Solr config files (solrconfig.xml, schema.xml, managed-schema). In addition, Xinclude functionality provided in these config files is also affected in a similar way. The vulnerability 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. Users are advised to upgrade to either Solr 6.6.4 or Solr 7.3.1 releases both of which address the vulnerability. Once upgrade is complete, no other steps are required. Those releases only allow external entities and Xincludes that refer to local files / zookeeper resources below the Solr instance directory (using Solr's ResourceLoader); usage of absolute URLs is denied. Keep in mind, that external entities and XInclude are explicitly supported to better structure config files in large installations. Before Solr 6 this was no problem, as config files were not accessible through the APIs.",Apache,Apache Solr,5.5,MEDIUM,0.0008900000248104334,false,false,false,false,,false,false,2018-05-21T00:00:00.000Z,0
CVE-2018-1308,https://securityvulnerability.io/vulnerability/CVE-2018-1308,,This vulnerability in Apache Solr 1.2 to 6.6.2 and 7.0.0 to 7.2.1 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.,Apache,Apache Solr,7.5,HIGH,0.0086899995803833,false,false,false,false,,false,false,2018-04-09T13:29:00.000Z,0
CVE-2017-12629,https://securityvulnerability.io/vulnerability/CVE-2017-12629,,"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.",Apache,Apache Solr Before 7.1 With Apache Lucene Before 7.1,9.8,CRITICAL,0.9708200097084045,false,false,false,false,,false,false,2017-10-14T23:29:00.000Z,0
CVE-2017-9803,https://securityvulnerability.io/vulnerability/CVE-2017-9803,,"Apache 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 Apache Solr 6.6.1 onwards.",Apache,Apache Solr,7.5,HIGH,0.0008200000156648457,false,false,false,false,,false,false,2017-09-18T00:00:00.000Z,0
CVE-2017-3163,https://securityvulnerability.io/vulnerability/CVE-2017-3163,,"When using the Index Replication feature, Apache Solr nodes can pull index files from a master/leader node using an HTTP API which accepts a file name. However, Solr before 5.5.4 and 6.x before 6.4.1 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.",Apache,Apache Solr,7.5,HIGH,0.005179999861866236,false,false,false,false,,false,false,2017-08-30T14:29:00.000Z,0
CVE-2017-7660,https://securityvulnerability.io/vulnerability/CVE-2017-7660,,"Apache 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.",Apache,Apache Solr,7.5,HIGH,0.0026199999265372753,false,false,false,false,,false,false,2017-07-07T00:00:00.000Z,0