CVE-2026-22022: 
Java vulnerability analysis and mitigation

CVE-2026-22022 is an authorization bypass vulnerability in Apache Solr's Rule Based Authorization Plugin (RuleBasedAuthorizationPlugin) that allows unauthenticated remote attackers to access restricted Solr APIs. It affects Apache Solr versions 5.3.0 through 9.10.0 and was publicly disclosed on January 21, 2026, with the fix available in Solr 9.10.1. The vulnerability carries a CVSS v3.1 base score of 8.2 (High) (Apache Mailing List, Openwall OSS-Sec). IBM Operational Decision Manager and Oracle products incorporating Apache Solr are also affected (Oracle, IBM Advisory).

The root cause is classified as CWE-285 (Improper Authorization) — specifically, insufficiently strict input validation within the RuleBasedAuthorizationPlugin component (Openwall OSS-Sec). The flaw allows attackers to bypass authorization checks enforced by certain pre-defined permission rules (config-read, config-edit, schema-read, metrics-read, security-read) when the all permission is not explicitly defined in the plugin's security.json configuration. Exploitation requires no authentication and is conducted over the network via standard HTTP/HTTPS requests, provided the Solr instance is directly reachable without an intervening proxy or gateway. All five conditions must be simultaneously present: use of RuleBasedAuthorizationPlugin, multiple roles defined, use of one of the vulnerable pre-defined permissions, absence of the all permission, and direct network access to Solr (Apache Mailing List).

Successful exploitation allows an unauthenticated network attacker to read sensitive configuration data, schema information, operational metrics, and security settings from the Solr instance — resulting in high confidentiality impact and low integrity impact with no availability impact (Openwall OSS-Sec). Exposed data may include Solr's security.json contents (which can contain credentials or role mappings), index schema details, and system metrics that could facilitate further targeted attacks. The scope is limited to the Solr instance itself, but information gained could enable lateral movement or privilege escalation within broader environments that rely on Solr for search or data indexing.

1. Reconnaissance: Identify internet-facing Apache Solr instances (versions 5.3.0–9.10.0) using tools like Shodan or Censys, searching for Solr admin interfaces or API endpoints exposed directly without a proxy.
2. Verify configuration: Probe the Solr instance to determine if the RuleBasedAuthorizationPlugin is active by attempting to access the /solr/admin/info/system or similar endpoints and observing authentication behavior.
3. Identify vulnerable permission scope: Attempt unauthenticated HTTP GET requests to endpoints protected by the vulnerable pre-defined permissions (e.g., /solr/admin/metrics, /solr/<collection>/config, /solr/<collection>/schema, /solr/admin/authorization) to determine if authorization checks are improperly enforced.
4. Bypass authorization: Craft HTTP requests targeting the restricted API endpoints (e.g., GET /solr/admin/authorization or GET /solr/<collection>/config) without credentials; if the all permission is absent from the configuration, the plugin fails to enforce access control and returns the protected data.
5. Exfiltrate sensitive data: Retrieve configuration details, schema definitions, metrics, and security settings — including role mappings and potentially credential information stored in security.json — for use in further attacks (Openwall OSS-Sec, Apache Mailing List).

• Network: Unauthenticated HTTP GET requests to Solr API endpoints such as /solr/admin/metrics, /solr/admin/authorization, /solr/<collection>/config, or /solr/<collection>/schema from external or unexpected IP addresses.
• Logs: Solr access logs showing successful (HTTP 200) responses to requests for config-read, schema-read, metrics-read, or security-read endpoints without associated authentication tokens or credentials.
• Logs: Repeated access to /solr/admin/authorization or security.json-related endpoints from a single source IP, potentially indicating reconnaissance or data harvesting activity.
• Network: Absence of proxy or gateway log entries corresponding to Solr API requests that appear in Solr's own access logs, indicating direct client access to Solr.

The primary remediation is to upgrade Apache Solr to version 9.10.1 or later, which addresses the vulnerability (Apache Mailing List). As a configuration-based workaround, administrators should add the all pre-defined permission to the RuleBasedAuthorizationPlugin's security.json and associate it with an admin or other privileged role, which prevents unauthorized access to unspecified API paths. Additionally, deploying a network-level proxy or gateway that filters and restricts direct client access to Solr APIs eliminates the network precondition required for exploitation. IBM has released a security bulletin addressing this CVE in IBM Operational Decision Manager (IBM Advisory), and Oracle addressed it in the April 2026 Critical Patch Update (Oracle).

The vulnerability received moderate coverage in the security community following its disclosure on January 20–21, 2026, with mentions on Bluesky, Mastodon, and security news aggregators such as SecurityOnline.info. The Apache Solr project acknowledged the issue via its official mailing list and credited the finder "monkeontheroof" (Openwall OSS-Sec). HeroDevs published a blog post explaining the vulnerability alongside a related CVE (CVE-2026-22444), providing additional context for organizations running older Solr versions. No significant controversy or vendor disputes were noted.