Apache Solr 5
Apache Solr 5
The Apache Solr 5 reached end of service life on Oct 24, 2017 — Apache Solr no longer ships security patches or fixes for it. Our third-party support keeps it safe to run: 24/7 engineers manage issues, remediate vulnerabilities, and help you maintain compliance.
24/7 engineers own your Apache Solr 5 incidents end to end.
Mitigation and patch-around guidance when the vendor no longer ships fixes.
Controls evidence and documentation that keep auditors satisfied.
Specifications
- product
- solr
- release
- 5
- product Label
- Apache Solr
- release Label
- 5
- codename
- lts
- latest Version
- 5.5.5
- release Date
- 2015-02-19
- maintained
- source Url
- https://endoflife.date/solr
Lifecycle Dates
- End of Service Life
- Oct 24, 2017
- Last OEM Support
- Oct 24, 2017
OEM vs. 3rd Party Support
See how third-party support compares to the vendor contract for Apache Solr 5 — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.
| Feature | OEM Support | 3rd Party Support |
|---|---|---|
| Post-EOSL Support | ||
| Break/Fix Support | Until EOSL | |
| 24/7 Monitoring | ||
| Vulnerability Scanning & Remediation | ||
| Managed Operations | ||
| Procedure & Configuration Review | ||
| Compliance & Audit Documentation | Limited | |
| Discounted Migration to Other Platforms |
Why Choose 3rd Party Support for Apache Solr 5?
Vulnerability Remediation
Scanning, mitigation and patch-around guidance for Apache Solr 5 when the vendor no longer ships fixes.
Compliance Maintenance
Procedure review, controls evidence and the documentation auditors ask for — maintained continuously, not scrambled at audit time.
24/7 Expert Support
Engineers who know this release monitor, manage and fix issues around the clock — break/fix to managed operations.
Apache Solr 5 Support: Frequently Asked Questions
Is the Apache Solr 5 still supported?
Apache Solr ended support for the Apache Solr 5 on Oct 24, 2017 — no more patches or fixes from the vendor. Third-party support keeps it covered: our engineers manage issues, remediate vulnerabilities, and help you maintain compliance for as long as you run it.
When is the Apache Solr 5 end of service life (EOSL) date?
Apache Solr lists the end of service life for the Apache Solr 5 as Oct 24, 2017.
Can I keep using the Apache Solr 5 after its EOSL date?
Yes. EOSL means Apache Solr stops issuing patches and support — the software itself keeps running. Third-party support covers it from there: issue management, security vulnerability remediation, and the compliance documentation auditors ask for, for as long as you choose to run it.
How much does third-party support for the Apache Solr 5 cost?
Typically 40-70% below the OEM maintenance renewal price. Exact pricing depends on quantity, service level and location — request a quote and we respond within 24 hours.
Known Vulnerabilities Affecting Apache Solr 5
18 published CVEs affect the Apache Solr 5, including 13 rated critical or high severity. Apache Solr no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.
| CVE | Severity | CVSS | Published | Summary |
|---|---|---|---|---|
| CVE-2021-44548 | CRITICAL | 9.8 | Dec 23, 2021 | 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 S |
| CVE-2021-27905 | CRITICAL | 9.8 | Apr 13, 2021 | 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 version |
| CVE-2019-0192 | CRITICAL | 9.8 | Mar 7, 2019 | 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-2021-29943 | CRITICAL | 9.1 | Apr 13, 2021 | 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 | HIGH | 8.8 | Aug 17, 2020 | 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-2023-44487 | HIGH | 7.5 | Oct 10, 2023 | The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. |
| CVE-2021-29262 | HIGH | 7.5 | Apr 13, 2021 | 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-2019-17558 | HIGH | 7.5 | Dec 30, 2019 | 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`. |
| CVE-2017-3164 | HIGH | 7.5 | Mar 8, 2019 | 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-2018-1308 | HIGH | 7.5 | Apr 9, 2018 | 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. |
| CVE-2017-3163 | HIGH | 7.5 | Aug 30, 2017 | 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 u |
| CVE-2017-7660 | HIGH | 7.5 | Jul 7, 2017 | 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 |
| CVE-2019-0193 | HIGH | 7.2 | Aug 1, 2019 | 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 pr |
| CVE-2015-8797 | MEDIUM | 6.1 | Feb 15, 2016 | 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. |
| CVE-2015-8796 | MEDIUM | 6.1 | Feb 15, 2016 | Cross-site scripting (XSS) vulnerability in webapp/web/js/scripts/schema-browser.js in the Admin UI in Apache Solr before 5.3 allows remote attackers to inject arbitrary web script or HTML via a crafted schema-browse URL. |
| CVE-2015-8795 | MEDIUM | 6.1 | Feb 15, 2016 | 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. |
| CVE-2025-24814 | MEDIUM | 5.5 | Jan 27, 2025 | Core creation allows users to replace "trusted" configset files with arbitrary configuration Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or "user-managed" mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual "trusted" configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem. These replacement config |
| CVE-2018-11802 | MEDIUM | 4.3 | Apr 1, 2020 | 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). |