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.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-22444)

Note that Nessus relies on the presence of the package as reported by the vendor.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-22444)

ID	Name	Product	Family	Severity
297683	Linux Distros Unpatched Vulnerability : CVE-2026-22444	Nessus	Misc.	high
436886	SCA: security update for org.apache.solr:solr-core (GHSA-vc2w-4v3p-2mqw)	Tenable Cloud Security	SCA Checks	high
436886	SCA: security update for org.apache.solr:solr-core (GHSA-vc2w-4v3p-2mqw)	Tenable Self-Hosted Container Security	SCA Checks	high

Detections

Analytics

CVE-2026-22444

high

Tenable Plugins

high

high

high