CVE-2021-27905: Server-Side Request Forgery in Apache Solr
Summary
CVE-2021-27905: Server-Side Request Forgery in Apache Solr. Affects org.apache.solr:solr-parent versions < 8.8.2. Fixed in 8.8.2. How to fix ↓
Also tracked for
- solr · Bitnami
- lucene-solr · Debian:11
The same CVE-2021-27905 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
Apache Solr is an open-source search platform built on Apache Lucene. It provides full-text search, faceted search, and indexing capabilities. Solr uses a ReplicationHandler to replicate index data from one core to another. The ReplicationHandler has a parameter called 'masterUrl' (also known as 'leaderUrl') that designates another ReplicationHandler on a different Solr core for replication. However, prior to version 8.8.2, Solr did not properly validate this parameter, leading to a Server-Side Request Forgery (SSRF) vulnerability.
Vulnerability Detail
The SSRF vulnerability in Apache Solr allows an attacker to make arbitrary requests on behalf of the server, potentially leading to unauthorized access to internal resources or network scanning. By exploiting this vulnerability, an attacker could bypass security measures, access sensitive information, or launch further attacks against other systems. The vulnerability affects all Solr versions prior to 8.8.2.
How To Fix
Minimum fixed version
8.8.2
This is the first release that contains the fix.
Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →
Workaround
If upgrading to the latest version is not immediately feasible, a temporary workaround is to manually validate the 'masterUrl' parameter against a similar configuration used for the 'shards' parameter. By implementing this validation, the risk of SSRF attacks can be mitigated. Here is an example of how to perform the validation in Java:
String masterUrl = request.getParameter("masterUrl");
String shards = request.getParameter("shards");
if (masterUrl != null && shards != null && masterUrl.startsWith(shards)) {
// Proceed with replication
} else {
// Reject the request
}
Conclusion
The Server-Side Request Forgery (SSRF) vulnerability in Apache Solr can be mitigated by upgrading to version 8.8.2 or later. It is important to promptly apply the patch to ensure the security of the system. If immediate upgrade is not possible, implementing the provided workaround can help mitigate the risk. For further assistance or support in vulnerability remediation, please contact DevNack.com.
See every vulnerability recorded for org.apache.solr:solr-parent →
FAQ
Apache Solr is an open-source search platform built on Apache Lucene. It provides powerful search capabilities, including full-text search, faceted search, and indexing.
The ReplicationHandler in Solr is responsible for replicating index data from one Solr core to another. It is used to keep multiple cores in sync and ensure data redundancy.
A Server-Side Request Forgery (SSRF) vulnerability allows an attacker to make arbitrary requests on behalf of the server. This can lead to unauthorized access to internal resources, network scanning, or further attacks against other systems.
To fix the SSRF vulnerability, it is recommended to upgrade to Apache Solr version 8.8.2 or later. This version includes the necessary validation checks for the 'masterUrl' parameter to prevent SSRF attacks.
Yes, if upgrading to the latest version is not immediately feasible, a temporary workaround is to manually validate the 'masterUrl' parameter against a similar configuration used for the 'shards' parameter. This can help mitigate the risk of SSRF attacks.
Related vulnerabilities
Recent vulnerabilities recorded for org.apache.solr:solr-parent.
