Security readout for executives and security teams
Plain-English summary
Apache Solr clusters before 7.7 can bypass authorization in a specific clustered setup. A node that does not host a requested collection may proxy the request to another node, and Solr can skip configured authorization checks for that proxied path.
Executive priority
Prioritize if Solr stores sensitive indexed data or administrative APIs are reachable beyond tightly trusted systems. Authorization bypasses can undermine access controls even when authentication appears configured.
Technical view
The issue affects Apache Solr versions before 7.7 using Solr's default RuleBasedAuthorizationPlugin. In clusters partitioned across collections, requests received by non-hosting nodes are proxied to relevant nodes, but authorization settings are bypassed for those proxied requests.
Likely exposure
Exposure is most likely in SolrCloud-style clustered deployments before 7.7 that use RuleBasedAuthorizationPlugin and split collections across subsets of nodes.
Exploitation context
The source bundle does not identify active exploitation, and KEV is false. The risk is unauthorized access through Solr's internal request proxying behavior, especially where Solr is reachable by untrusted users or broad internal networks.
Researcher notes
Evidence is limited to the CVE description and Apache disclosure reference. No CVSS, CWE, exploit maturity, or detailed patch notes are included in the provided bundle, so validation should focus on affected version, auth plugin, and clustered collection routing.
Mitigation direction
- Upgrade affected Solr deployments to version 7.7 or later.
- Check Apache Solr guidance before relying on alternate mitigations.
- Restrict Solr access to trusted networks and authenticated service paths.
- Review authorization configuration for RuleBasedAuthorizationPlugin usage.
Validation and detection
- Inventory Solr versions across all cluster nodes.
- Confirm whether RuleBasedAuthorizationPlugin is enabled.
- Identify collections hosted by only a subset of nodes.
- Review logs for suspicious collection access through non-hosting nodes.
- Validate authorization behavior in staging after upgrade.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CVE-2018-11802 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Unknown
- CVSS
- Not scored
- Known Exploited
- No
- Published
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
CVSS and timeline data
No CVSS vectors or timeline events were available in the normalized CVE source material.
Source materials
- CVE List V5 sourceCVE List V5
- https://www.openwall.com/lists/oss-security/2019/04/24/1CVE reference · x_refsource_MISC
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.