CVE-2026-22022: CWE-285 Improper Authorization in Apache Software Foundation Apache Solr
Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted by this vulnerability: * Use of Solr's "RuleBasedAuthorizationPlugin" * A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles" * A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read". * A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission * A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening proxy or gateway) Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role. Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1.
AI Analysis
Technical Summary
CVE-2026-22022 is a vulnerability classified under CWE-285 (Improper Authorization) affecting Apache Solr versions 5.3.0 through 9.10.0 when the RuleBasedAuthorizationPlugin is used with certain configurations. The vulnerability stems from insufficiently strict input validation within the plugin's authorization logic, which can allow unauthorized users to access specific Solr APIs that should be restricted. The conditions for exploitation include: (1) use of the RuleBasedAuthorizationPlugin, (2) a configuration specifying multiple roles, (3) permission lists that include predefined rules such as 'config-read', 'config-edit', 'schema-read', 'metrics-read', or 'security-read' but do not include the 'all' permission, and (4) network setups that allow direct, unfiltered HTTP/HTTPS requests to Solr instances. Under these conditions, an attacker can bypass intended access controls and perform unauthorized read or edit operations on Solr configurations, schemas, metrics, or security settings. This can lead to exposure or manipulation of sensitive data and system configurations. The vulnerability does not require user interaction or authentication but does require network access to the Solr service. No public exploits have been reported yet, but the risk remains significant due to the widespread use of Solr in enterprise search and data indexing. Mitigation is straightforward: upgrading to Solr 9.10.1 or later, or modifying the RuleBasedAuthorizationPlugin configuration to include the 'all' permission assigned to an admin or privileged role, effectively tightening access controls and preventing unauthorized API access.
Potential Impact
For European organizations, this vulnerability poses a significant risk of unauthorized access to critical Solr APIs, potentially leading to exposure or unauthorized modification of search indexes, configurations, and security settings. This can compromise data confidentiality and integrity, disrupt search services, and undermine trust in data-driven applications. Organizations relying on Solr for enterprise search, e-commerce, or public sector data indexing could face operational disruptions or data breaches. The impact is heightened in sectors with strict data protection regulations such as GDPR, where unauthorized data access can lead to regulatory penalties and reputational damage. Since exploitation requires network access to Solr, organizations with publicly accessible Solr instances or insufficient network segmentation are particularly vulnerable. The absence of authentication requirements for exploitation increases the risk of automated or opportunistic attacks. Overall, the vulnerability threatens the confidentiality and integrity of data managed by Solr deployments across European enterprises and government agencies.
Mitigation Recommendations
To mitigate CVE-2026-22022, European organizations should: 1) Immediately upgrade Apache Solr to version 9.10.1 or later, where the vulnerability is fixed. 2) Review and audit RuleBasedAuthorizationPlugin configurations to ensure the 'all' predefined permission is included and assigned exclusively to admin or highly privileged roles, thereby enforcing strict access control. 3) Implement network-level protections such as firewalls, reverse proxies, or API gateways to restrict direct, unfiltered access to Solr endpoints, limiting exposure to trusted internal networks or authenticated clients only. 4) Employ monitoring and logging of Solr API access to detect anomalous or unauthorized requests promptly. 5) Conduct penetration testing and security assessments focused on Solr deployments to verify the effectiveness of authorization controls. 6) Educate DevOps and security teams about the risks of misconfigured authorization plugins and the importance of least privilege principles in Solr security configurations. These steps go beyond generic advice by focusing on configuration hardening, network segmentation, and proactive detection tailored to this specific vulnerability.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Italy
CVE-2026-22022: CWE-285 Improper Authorization in Apache Software Foundation Apache Solr
Description
Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted by this vulnerability: * Use of Solr's "RuleBasedAuthorizationPlugin" * A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles" * A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read". * A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission * A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening proxy or gateway) Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role. Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1.
AI-Powered Analysis
Technical Analysis
CVE-2026-22022 is a vulnerability classified under CWE-285 (Improper Authorization) affecting Apache Solr versions 5.3.0 through 9.10.0 when the RuleBasedAuthorizationPlugin is used with certain configurations. The vulnerability stems from insufficiently strict input validation within the plugin's authorization logic, which can allow unauthorized users to access specific Solr APIs that should be restricted. The conditions for exploitation include: (1) use of the RuleBasedAuthorizationPlugin, (2) a configuration specifying multiple roles, (3) permission lists that include predefined rules such as 'config-read', 'config-edit', 'schema-read', 'metrics-read', or 'security-read' but do not include the 'all' permission, and (4) network setups that allow direct, unfiltered HTTP/HTTPS requests to Solr instances. Under these conditions, an attacker can bypass intended access controls and perform unauthorized read or edit operations on Solr configurations, schemas, metrics, or security settings. This can lead to exposure or manipulation of sensitive data and system configurations. The vulnerability does not require user interaction or authentication but does require network access to the Solr service. No public exploits have been reported yet, but the risk remains significant due to the widespread use of Solr in enterprise search and data indexing. Mitigation is straightforward: upgrading to Solr 9.10.1 or later, or modifying the RuleBasedAuthorizationPlugin configuration to include the 'all' permission assigned to an admin or privileged role, effectively tightening access controls and preventing unauthorized API access.
Potential Impact
For European organizations, this vulnerability poses a significant risk of unauthorized access to critical Solr APIs, potentially leading to exposure or unauthorized modification of search indexes, configurations, and security settings. This can compromise data confidentiality and integrity, disrupt search services, and undermine trust in data-driven applications. Organizations relying on Solr for enterprise search, e-commerce, or public sector data indexing could face operational disruptions or data breaches. The impact is heightened in sectors with strict data protection regulations such as GDPR, where unauthorized data access can lead to regulatory penalties and reputational damage. Since exploitation requires network access to Solr, organizations with publicly accessible Solr instances or insufficient network segmentation are particularly vulnerable. The absence of authentication requirements for exploitation increases the risk of automated or opportunistic attacks. Overall, the vulnerability threatens the confidentiality and integrity of data managed by Solr deployments across European enterprises and government agencies.
Mitigation Recommendations
To mitigate CVE-2026-22022, European organizations should: 1) Immediately upgrade Apache Solr to version 9.10.1 or later, where the vulnerability is fixed. 2) Review and audit RuleBasedAuthorizationPlugin configurations to ensure the 'all' predefined permission is included and assigned exclusively to admin or highly privileged roles, thereby enforcing strict access control. 3) Implement network-level protections such as firewalls, reverse proxies, or API gateways to restrict direct, unfiltered access to Solr endpoints, limiting exposure to trusted internal networks or authenticated clients only. 4) Employ monitoring and logging of Solr API access to detect anomalous or unauthorized requests promptly. 5) Conduct penetration testing and security assessments focused on Solr deployments to verify the effectiveness of authorization controls. 6) Educate DevOps and security teams about the risks of misconfigured authorization plugins and the importance of least privilege principles in Solr security configurations. These steps go beyond generic advice by focusing on configuration hardening, network segmentation, and proactive detection tailored to this specific vulnerability.
Affected Countries
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- apache
- Date Reserved
- 2026-01-05T20:52:03.246Z
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 6970dd444623b1157cd11f81
Added to database: 1/21/2026, 2:05:56 PM
Last enriched: 1/21/2026, 2:20:43 PM
Last updated: 2/7/2026, 10:07:27 PM
Views: 87
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Related Threats
CVE-2026-25858: CWE-640 Weak Password Recovery Mechanism for Forgotten Password in macrozheng mall
CriticalCVE-2026-25857: CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in Shenzhen Tenda Technology Tenda G300-F
HighCVE-2025-15564: Divide By Zero in Mapnik
MediumCVE-2026-2113: Deserialization in yuan1994 tpadmin
MediumCVE-2026-2111: Path Traversal in JeecgBoot
MediumActions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console in Console -> Billing for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.