CVE-2026-22022 and CVE-2026-22444: Apache Solr Authorization Bypass and File-Access Vulnerabilities Explained

Your search infrastructure may be quietly exposing sensitive data, and your security scanner just told you about it.

Two vulnerabilities disclosed in January 2026, CVE-2026-22022 and CVE-2026-22444, affect Apache Solr deployments across a wide range of versions. CVE-2026-22022 is an authorization bypass in the RuleBasedAuthorizationPlugin affecting Solr 5.3.0 through 9.10.0. CVE-2026-22444 is an insufficient file-access validation flaw in Solr's standalone core-creation API affecting Solr 8.6 through 9.10.0. Both are fixed in Solr 9.10.1, but for organizations running Solr 8.11.x or earlier (all of which are end-of-life), there is no OSS patch. NES for Apache Solr & Lucene delivers remediated packages for EOL Solr versions, including 8.11.x.

Important: These two CVEs have different affected version ranges and different root causes. This post covers both, but treats each vulnerability separately where precision matters.

‍

What Are These Vulnerabilities?

CVE-2026-22022: Authorization Bypass in RuleBasedAuthorizationPlugin

CVE-2026-22022 is an improper authorization vulnerability (CWE-285) in Apache Solr's RuleBasedAuthorizationPlugin. When certain predefined permission rules (such as config-read, config-edit, schema-read, metrics-read, or security-read) are configured without a catch-all all permission, the plugin fails to properly restrict access. This allows unauthenticated or low-privilege users to bypass authorization and reach protected Solr APIs.

CVSS 3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

The attack is network-accessible, requires no authentication or user interaction, and can expose sensitive configuration data, schema definitions, and security settings.

CVE-2026-22444: Insufficient File-Access Checking in Core Creation

CVE-2026-22444 targets Solr's standalone-mode create core API. The API lacks sufficient input validation on parameters that reference file-system paths, allowing it to bypass Solr's allowPaths security setting. Attackers with access to the core-creation endpoint can force Solr to read file-system paths that should be restricted, create cores using unexpected configsets, and, on Windows systems with UNC paths enabled, trigger disclosure of NTLM credential hashes.

This CVE applies specifically to Solr deployments in standalone mode where the create core API is exposed to untrusted users.

‍

Why This Matters

Apache Solr is deeply embedded in enterprise search stacks. It powers e-commerce product search, internal knowledge bases, log analytics, and document retrieval systems across industries. In many organizations, Solr is infrastructure that was deployed years ago and has been running reliably ever since, often on versions that predate current support windows.

These two CVEs surface a pattern that matters: Solr's authorization and access-control mechanisms have systemic gaps. CVE-2026-22022 shows that even organizations that configured role-based authorization may still have unprotected API endpoints. CVE-2026-22444 shows that file-system boundary enforcement can be circumvented through the core-creation API.

For teams running Solr in production, the practical consequences include:

• Scanner findings that block deployments. Tools like Snyk, Tenable, and Qualys will flag both CVEs. For organizations subject to SOC 2, PCI DSS, HIPAA, or FedRAMP requirements, unresolved findings on production infrastructure components create audit risk.
• Exposure of sensitive data. The authorization bypass in CVE-2026-22022 can expose Solr configuration, schema, and security settings to unauthorized users. The file-access flaw in CVE-2026-22444 can leak file-system contents or credential hashes.
• Silent risk in "stable" infrastructure. Solr clusters are often managed by platform or operations teams rather than application developers. Vulnerabilities in search infrastructure can sit undetected because security reviews tend to focus on application code, not long-running middleware.

Who Is Affected

These two CVEs have different affected version ranges. The table below breaks down each separately.

‍

Solr 8.11.4 was the final release of Solr 8, confirmed EOL by the Apache project. No further OSS releases will be made for the 8.x line. For Solr versions older than 8.11, community support ended even earlier.

Solr 9.10.1 is the last release in the 9.x series. With Solr 10.0.0 now released, organizations on 9.x should be aware that this line will eventually transition to EOL as well.

HeroDevs has already remediated both CVEs in NES for Apache Solr & Lucene v8.11.6. Organizations running Solr 8.11.x in production can apply the NES patch as a drop-in replacement without migrating to Solr 9 or 10.

‍

Why This Is Hard to Fix

The standard recommendation is to upgrade to Solr 9.10.1. For teams already on the 9.10.x line, this is a straightforward patch. But for the large number of organizations still running Solr 8.11.x or earlier, the path forward is significantly more complex.

Upgrading from Solr 8 to Solr 9 is not a minor version bump. Solr 9 requires Java 11 (minimum), introduces changes to API behavior, modifies security plugin configurations, and removes or replaces features that Solr 8 deployments may depend on. For organizations with custom schema configurations, complex SolrCloud topologies, or integrations with upstream data pipelines, the migration effort is measured in months, not days.

And Solr 9.x is itself a transitional target. With Solr 10.0.0 already released, teams evaluating a Solr 8-to-9 migration need to consider whether the investment makes sense, or whether they should plan a longer migration directly to Solr 10. Either way, the timeline extends further.

Meanwhile, the CVEs are active now. Scanners are flagging them now. Compliance deadlines do not wait for migration planning to finish.

This is the gap where organizations get stuck: the vulnerability is real, the upgrade is not practical in the short term, and doing nothing is not an option.

‍

Technical Breakdown

CVE-2026-22022

The RuleBasedAuthorizationPlugin evaluates incoming requests against a list of predefined permission rules defined in security.json. The vulnerability exists because, when the all predefined permission is not included in the configuration, the plugin does not properly restrict access to certain API endpoints. Specifically, requests targeting config-read, config-edit, schema-read, metrics-read, and security-read operations can bypass the intended authorization checks.

The conditions for exploitation require that the deployment uses RuleBasedAuthorizationPlugin with multiple roles, uses one or more of the affected predefined permissions, omits the all permission from its configuration, and allows unfiltered network requests to reach Solr. All four conditions must be present.

CVE-2026-22444

Solr's create core API in standalone mode accepts parameters that reference file-system paths. The API is intended to validate these paths against Solr's allowPaths security setting, but the validation is insufficient. An attacker with access to the core-creation endpoint can supply paths that bypass the restriction, causing Solr to read directories or files that should be off-limits. On Windows systems where UNC paths are enabled, this can additionally leak NTLM hashes.

The conditions for exploitation require standalone mode, the allowPaths setting to be in use, and the create core API to be accessible to untrusted users (either because RuleBasedAuthorizationPlugin is disabled, or the core-admin-edit permission is granted to low-trust roles).

‍

How to Fix It

Supported versions: Upgrade to 9.10.1

For organizations running Solr 9.10.x, the fix is available immediately: upgrade to Solr 9.10.1. No commercial agreement is required. The release is available through standard Apache distribution channels.

Immediate mitigation (all versions)

Regardless of version, teams should review their security.json configuration. Adding the all predefined permission and associating it with an admin role mitigates CVE-2026-22022. Ensuring the core-admin-edit permission is restricted to trusted roles mitigates CVE-2026-22444. These are configuration-level changes that can be applied while planning a longer-term upgrade or patch.

Network-level controls (reverse proxies, API gateways, firewall rules restricting access to Solr ports 8983/8984) also reduce exposure for both CVEs.

EOL versions: NES for Apache Solr & Lucene

For organizations on Solr 8.11.x or earlier, there is no OSS fix. The Apache project has confirmed that Solr 8.11.4 was the final 8.x release, and no further patches will be issued for any 8.x version.

NES for Apache Solr & Lucene resolves both CVE-2026-22022 and CVE-2026-22444 for EOL Solr versions. NES packages are drop-in replacements: they require zero code changes and no application migration. Your team gets the security fix on the version you are already running, while you plan your upgrade to Solr 9 or 10 on your own timeline.

‍

Taking Action

If your organization runs Apache Solr 8.11.x (or earlier) in production, these CVEs represent exactly the kind of risk that compounds over time. The vulnerabilities are disclosed, scanners are flagging them, and there is no upstream fix coming for your version.

HeroDevs NES for Apache Solr & Lucene is designed to close this gap. Remediated packages for CVE-2026-22022, CVE-2026-22444, and every subsequent CVE, delivered as drop-in replacements that keep your Solr deployment secure and compliant while you plan your migration.

Get in touch with HeroDevs to learn how NES can resolve these vulnerabilities for your team today.