CVE-2026-22444

highpriority · track · 10EPSS 0.007 · 52 %ileexploit · PoCDEEUUS
grimoire priorityP1 · Urgent
Exploitable?
Public exploit
2 exploits · PoC
Likely / severe?
0.69% (52nd) EPSS
CVSS 7.1 · high
Is it mine?
11 products
Check your exposure
Who says so?
5 sources
cnnvd · enisa_euvd · osv · cert_bund

EPSS · scored 2026-10-27

The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .  These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.  On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.  Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users.  This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles. Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores.  Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.

01

cvss

Technical severity, 0–10. One row per scoring source.

7.1
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 6.7–7.1

v3.17.1highCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:Nsecondary · ENISA EU
v3.17.1highCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:Nsecondaryexploitability 2.8 · impact 4.2
v3.17.1highCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:Nsecondary · OSV
v3.16.7mediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N/E:Psecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Trackcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

exploits (2)

Public proof-of-concept and weaponised exploit code.

05

affected products (11)

Products and version ranges known to be affected.

06

advisories (3)

Vendor and ecosystem advisories describing this.

  • WID-SEC-W-2026-0182Apache Solr: Mehrere SchwachstellenDeutsch2026-01-20csaf · cert_bundDE

    Ein Angreifer kann mehrere Schwachstellen in Apache Solr ausnutzen, um Sicherheitsvorkehrungen zu umgehen, Daten zu manipulieren und vertrauliche Informationen offenzulegen.

  • GHSA-vc2w-4v3p-2mqwApache Solr: Insufficient file-access checking in standalone core-creation requests2026-01-21ghsa · osvUS

    The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .  These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.  On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.  Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users.  This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles. Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores.  Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.

  • BIT-solr-2026-22444Apache Solr: Insufficient file-access checking in standalone core-creation requests2026-01-26vendor · osvUS

    The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .  These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.  On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.  Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users.  This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles. Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores.  Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.

07

also known as (5)

Other names and identifiers for this entity.

08

sources

Which sources assert this record, and when.

published 2026-01-21modified 2026-06-17
09

references (6)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan