Version 9.7.0
Apache Solr (module: core)
Apache Solr open-source search software
Install Instructions
mvn install solr-core
Language Java
Package URL (purl) pkg:maven/org.apache.solr:solr-core@9.7.0
Find Apache Solr (module: core) vulnerabilities in your supply chain.
Apache Solr (module: core) Vulnerabilities
Sort by
CVE (Latest)
CVE (Latest)
-
CVE (Latest)
-
CVE (Oldest)
-
CVSS Score (Highest)
-
CVSS Score (Lowest)
CVE  |
CVSS Score |
CWE(s) |
EPSS Score |
EPSS % |
Impacted Versions |
|---|---|---|---|---|---|
| CVE-2015-8797 | Medium 6.1 | CWE-79 | 0.03677 | 0.91613 |
|
| CVE-2017-3163 | High 7.5 | CWE-22 | 0.00518 | 0.76608 |
|
| CVE-2017-3164 | High 7.5 | CWE-918 | 0.04318 | 0.92235 |
|
| CVE-2018-1308 | High 7.5 | CWE-611 | 0.00869 | 0.82156 |
|
| CVE-2019-0192 | High 9.8 | CWE-502 | 0.94175 | 0.99381 |
|
| CVE-2019-0193 | High 7.2 | CWE-94 | 0.92971 | 0.99268 |
|
| CVE-2019-17558 | High 7.5 | CWE-74 | 0.97525 | 0.99996 |
|
| CVE-2020-13941 | High 8.8 | CWE-20 | 0.00319 | 0.70122 |
|
| CVE-2021-27905 | High 9.8 | CWE-918 | 0.9494 | 0.99473 |
|
| CVE-2021-29262 | High 7.5 | CWE-522 | 0.00594 | 0.78172 |
|
| CVE-2017-12629 | High 9.8 | CWE-611 | 0.97082 | 0.99875 |
|
| CVE-2018-11802 | Medium 4.3 | CWE-863 | 0.00063 | 0.29497 |
|
| CVE-2018-8010 | Medium 5.5 | CWE-611 | 0.00089 | 0.39224 |
|
| CVE-2018-8026 | Medium 5.5 | CWE-611 | 0.00836 | 0.8183 |
|
| CVE-2020-13957 | High 9.8 | CWE-863, CWE-862 | 0.81918 | 0.9861 |
|
| CVE-2023-50291 | High 7.5 | CWE-522 | 0.00223 | 0.60128 |
|
| CVE-2023-50386 | High 8.8 | CWE-434, CWE-913 | 0.86683 | 0.98846 |
|
| CVE-2017-7660 | High 7.5 | CWE-287 | 0.00262 | 0.65016 |
|
| CVE-2017-9803 | High 7.5 | CWE-287 | 0.00082 | 0.36865 |
|
| CVE-2013-6397 | Medium 4.3 | CWE-22 | 0.29398 | 0.96893 |
|
| CVE-2015-8795 | Medium 6.1 | CWE-79 | 0.00243 | 0.63508 |
|
| CVE-2019-12401 | High 7.5 | CWE-776 | 0.00332 | 0.70773 |
|
| CVE-2013-6408 | Medium 6.4 | CWE-611 | 0.00335 | 0.70891 |
|
| CVE-2012-6612 | High 7.5 | CWE-611 | 0.00158 | 0.52619 |
|
| CVE-2013-6407 | Medium 6.4 | CWE-611 | 0.00335 | 0.70891 |
|
| CVE-2019-12409 | High 9.8 | CWE-434 | 0.01272 | 0.85416 |
|
| CVE-2023-50290 | Medium 6.5 | CWE-200 | 0.37698 | 0.9722 |
|
| CVE-2023-50292 | High 7.5 | CWE-732 | 0.00223 | 0.60128 |
|
Apache Solr (module: core) Vulnerability Remediation Guidance
| CVE | Description | Full list of Impacted Versions | Fix |
|---|---|---|---|
| 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.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1. In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API. When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups). If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted. When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries. Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue. In these versions, the following protections have been added: * Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader. * The Backup API restricts saving backups to directories that are used in the ClassLoader. | 7.0.0, 6.5.0, 6.5.1, 6.2.1, 6.4.0, 7.0.1, 6.6.1, 6.2.0 (Show all) | Major → 8.11.3 |
| CVE-2023-50292 | Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr. This issue affects Apache Solr: from 8.10.0 through 8.11.2, from 9.0.0 before 9.3.0. The Schema Designer was introduced to allow users to more easily configure and test new Schemas and configSets. However, when the feature was created, the "trust" (authentication) of these configSets was not considered. External library loading is only available to configSets that are "trusted" (created by authenticated users), thus non-authenticated users are unable to perform Remote Code Execution. Since the Schema Designer loaded configSets without taking their "trust" into account, configSets that were created by unauthenticated users were allowed to load external libraries when used in the Schema Designer. Users are recommended to upgrade to version 9.3.0, which fixes the issue. | 9.0.0, 8.11.2, 9.2.1, 9.2.0, 9.1.1, 8.10.0, 8.11.1, 8.11.0 (Show all) | Minor → 9.4.1 |
| CVE-2023-50291 | Insufficiently Protected Credentials vulnerability in Apache Solr. This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0. One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name. There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint. This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI. This /admin/info/properties endpoint is protected under the "config-read" permission. Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission. Users are recommended to upgrade to version 9.3.0 or 8.11.3, which fixes the issue. A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps". By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password". Users who cannot upgrade can also use the following Java system property to fix the issue: '-Dsolr.redaction.system.pattern=.*(password|secret|basicauth).*' | 7.0.0, 6.5.0, 6.5.1, 6.2.1, 6.4.0, 7.0.1, 6.6.1, 6.2.0 (Show all) | Major → 8.11.3 |
| CVE-2023-50290 | 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. | 9.0.0, 9.2.1, 9.2.0, 9.1.1, 9.1.0 | Minor → 9.4.1 |
| CVE-2021-29262 | 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. | 5.1.0, 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 4.5.1 (Show all) | Major → 8.11.3 |
| CVE-2021-27905 | 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. | 5.1.0, 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 4.5.1 (Show all) | Major → 8.11.3 |
| 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. | 7.0.0, 7.0.1, 6.6.1, 6.6.0, 7.3.1, 7.3.0, 6.6.5, 7.2.0 (Show all) | Major → 8.11.3 |
| 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. | 5.1.0, 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 4.5.1 (Show all) | Major → 8.11.3 |
| 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). | 5.1.0, 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 5.4.1 (Show all) | Major → 8.11.3 |
| CVE-2019-12409 | 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. | 8.1.1, 8.2.0 | Minor → 8.11.3 |
| CVE-2019-12401 | 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. | 4.5.1, 4.10.0, 4.10.4, 4.9.0, 4.6.0, 4.4.0, 4.1.0, 4.8.1 (Show all) | Major → 8.11.3 |
| 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. | 5.1.0, 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 4.5.1 (Show all) | Major → 8.11.3 |
| 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. | 5.1.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 5.4.1, 6.4.0 (Show all) | Major → 8.11.3 |
| 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. | 7.0.0, 6.5.0, 6.5.1, 6.2.1, 6.4.0, 7.0.1, 6.6.1, 6.2.0 (Show all) | Major → 8.11.3 |
| 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. | 7.0.0, 7.0.1, 6.6.1, 6.6.0, 7.3.0, 7.2.0, 6.6.3, 7.2.1 (Show all) | Major → 8.11.3 |
| 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. | 5.1.0, 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 4.5.1 (Show all) | Major → 8.11.3 |
| 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). | 7.0.0, 6.5.0, 6.5.1, 6.2.1, 6.4.0, 7.0.1, 6.6.1, 6.2.0 (Show all) | Major → 8.11.3 |
| 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. | 6.5.0, 6.5.1, 6.2.1, 6.4.0, 6.2.0, 6.4.2, 6.6.0, 6.4.1 (Show all) | Major → 8.11.3 |
| 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. | 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 5.4.1, 6.4.0, 5.4.0 (Show all) | Major → 8.11.3 |
| 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. | 5.1.0, 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 4.5.1 (Show all) | Major → 8.11.3 |
| 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. | 5.1.0, 6.2.1, 5.5.1, 4.5.1, 4.10.0, 4.10.4, 4.9.0, 4.6.0 (Show all) | Major → 8.11.3 |
| 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. | 7.0.0, 6.5.0, 6.5.1, 6.2.1, 5.5.4, 5.5.1, 6.4.0, 5.5.3 (Show all) | Major → 8.11.3 |
| CVE-2015-8797 | Cross-site scripting (XSS) vulnerability in webapp/web/js/scripts/plugins.js in the stats page in the Admin UI in Apache Solr before 5.3.1 allows remote attackers to inject arbitrary web script or HTML via the entry parameter to a plugins/cache URI. | 5.1.0, 4.5.1, 4.10.0, 4.10.4, 4.9.0, 4.6.0, 4.4.0, 4.1.0 (Show all) | Major → 8.11.3 |
| CVE-2015-8795 | Multiple cross-site scripting (XSS) vulnerabilities in the Admin UI in Apache Solr before 5.1 allow remote attackers to inject arbitrary web script or HTML via crafted fields that are mishandled during the rendering of the (1) Analysis page, related to webapp/web/js/scripts/analysis.js or (2) Schema-Browser page, related to webapp/web/js/scripts/schema-browser.js. | 4.5.1, 4.10.0, 4.10.4, 4.9.0, 4.6.0, 4.4.0, 4.1.0, 4.8.1 (Show all) | Major → 8.11.3 |
| CVE-2013-6408 | 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. | 4.1.0, 3.4.0, 1.4.1, 4.2.1, 4.0.0, 4.3.0, 3.5.0, 4.2.0 (Show all) | Major → 8.11.3 |
| CVE-2013-6407 | The UpdateRequestHandler for XML in Apache Solr before 4.1 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. | 4.0.0, 4.0.0-ALPHA, 4.0.0-BETA, 3.6.2, 3.6.1 | Major → 8.11.3 |
| CVE-2013-6397 | 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. | 4.5.1, 4.4.0, 4.1.0, 3.4.0, 1.4.1, 4.2.1, 4.0.0, 4.3.0 (Show all) | Major → 8.11.3 |
| CVE-2012-6612 | The (1) UpdateRequestHandler for XSLT or (2) XPathEntityProcessor in Apache Solr before 4.1 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, different vectors than CVE-2013-6407. | 3.4.0, 1.4.1, 4.0.0, 3.5.0, 3.3.0, 1.3.0, 4.0.0-ALPHA, 4.0.0-BETA (Show all) | Major → 8.11.3 |
Instantly see if these Apache Solr (module: core) vulnerabilities affect your code.
Dependencies
Packages using versions of Apache Solr (module: core) affected by its vulnerabilities
| Dependent Packages |
|---|
| org.apache.lucene:lucene-core:9.11.1 |
| org.apache.lucene:lucene-analysis-common:9.11.1 |
| org.apache.lucene:lucene-queries:9.11.1 |
| org.slf4j:slf4j-api:2.0.13 |
| org.apache.solr:solr-api:9.7.0 |
| org.apache.solr:solr-solrj:9.7.0 |
| org.apache.solr:solr-solrj-zookeeper:9.7.0 |
| org.apache.solr:solr-solrj-streaming:9.7.0 |
| io.dropwizard.metrics:metrics-core:4.2.26 |
| io.opentracing:opentracing-api:0.33.0 |
| io.swagger.core.v3:swagger-annotations-jakarta:2.2.22 |
| io.dropwizard.metrics:metrics-graphite:4.2.26 |
| io.dropwizard.metrics:metrics-jmx:4.2.26 |
| io.dropwizard.metrics:metrics-jvm:4.2.26 |
| org.glassfish.jersey.containers:jersey-container-jetty-http:2.39.1 |
| org.glassfish.jersey.inject:jersey-hk2:3.1.5 |
| org.glassfish.jersey.media:jersey-media-json-jackson:3.1.5 |
| org.glassfish.jersey.core:jersey-common:3.1.5 |
| org.glassfish.jersey.core:jersey-server:3.1.5 |
| org.glassfish.hk2:hk2-api:3.0.5 |
| jakarta.inject:jakarta.inject-api:2.0.1 |
| jakarta.ws.rs:jakarta.ws.rs-api:3.1.0 |
| jakarta.annotation:jakarta.annotation-api:2.1.1 |
| org.apache.lucene:lucene-codecs:9.11.1 |
| org.apache.lucene:lucene-backward-codecs:9.11.1 |
| org.apache.lucene:lucene-classification:9.11.1 |
| org.apache.lucene:lucene-expressions:9.11.1 |
| org.apache.lucene:lucene-grouping:9.11.1 |
| org.apache.lucene:lucene-highlighter:9.11.1 |
| org.apache.lucene:lucene-join:9.11.1 |
| org.apache.lucene:lucene-misc:9.11.1 |
| org.apache.lucene:lucene-queryparser:9.11.1 |
| org.apache.lucene:lucene-spatial-extras:9.11.1 |
| org.apache.lucene:lucene-suggest:9.11.1 |
| com.google.guava:guava:33.1.0-jre |
| org.apache.commons:commons-lang3:3.15.0 |
| org.apache.commons:commons-math3:3.6.1 |
| commons-io:commons-io:2.15.1 |
| com.carrotsearch:hppc:0.10.0 |
| com.github.ben-manes.caffeine:caffeine:3.1.8 |
| commons-codec:commons-codec:1.17.1 |
| commons-cli:commons-cli:1.8.0 |
| org.locationtech.spatial4j:spatial4j:0.8 |
| com.fasterxml.jackson.core:jackson-annotations:2.17.2 |
| com.fasterxml.jackson.core:jackson-core:2.17.2 |
| com.fasterxml.jackson.core:jackson-databind:2.17.2 |
| com.fasterxml.jackson.dataformat:jackson-dataformat-smile:2.17.2 |
| com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.17.2 |
| org.apache.httpcomponents:httpclient:4.5.14 |
| org.apache.httpcomponents:httpcore:4.4.16 |
| org.eclipse.jetty:jetty-client:10.0.22 |
| org.eclipse.jetty:jetty-http:10.0.22 |
| org.eclipse.jetty:jetty-io:10.0.22 |
| org.eclipse.jetty.toolchain:jetty-servlet-api:4.0.6 |
| org.apache.zookeeper:zookeeper:3.9.2 |
| org.apache.zookeeper:zookeeper-jute:3.9.2 |
| com.jayway.jsonpath:json-path:2.9.0 |
| com.tdunning:t-digest:3.3 |
| io.opentracing:opentracing-noop:0.33.0 |
| io.opentracing:opentracing-util:0.33.0 |
| org.apache.commons:commons-exec:1.4.0 |
| org.apache.logging.log4j:log4j-api:2.21.0 |
| org.apache.logging.log4j:log4j-core:2.21.0 |
| io.prometheus:prometheus-metrics-model:1.1.0 |
| io.prometheus:prometheus-metrics-exposition-formats:1.1.0 |
| org.codehaus.woodstox:stax2-api:4.2.2 |
| com.fasterxml.woodstox:woodstox-core:6.7.0 |
| com.j256.simplemagic:simplemagic:1.17 |
| org.apache.lucene:lucene-analysis-kuromoji:9.11.1 |
| org.apache.lucene:lucene-analysis-nori:9.11.1 |
| org.apache.lucene:lucene-analysis-phonetic:9.11.1 |
| org.xerial.snappy:snappy-java:1.1.10.5 |
| org.apache.logging.log4j:log4j-slf4j2-impl:2.21.0 |