This is an automated email from the ASF dual-hosted git repository.
github-bot pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/solr-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 2bba6b71e Commit build products
2bba6b71e is described below
commit 2bba6b71e46d806200bfb8ac73bfb10f8d9ed14b
Author: Build Pelican (action) <[email protected]>
AuthorDate: Tue Jan 20 17:52:54 2026 +0000
Commit build products
---
output/feeds/all.atom.xml | 114 ++++++++++++++--------------------
output/feeds/solr/security.atom.xml | 45 +++++++++++++-
output/index.html | 2 +-
output/news.html | 45 ++++++++++++++
output/operator/index.html | 2 +-
output/security.html | 120 +++++++++++++++++-------------------
6 files changed, 193 insertions(+), 135 deletions(-)
diff --git a/output/feeds/all.atom.xml b/output/feeds/all.atom.xml
index 9eae0606a..75a261dcb 100644
--- a/output/feeds/all.atom.xml
+++ b/output/feeds/all.atom.xml
@@ -15,7 +15,50 @@
<p>Please refer to the Upgrade Notes in the Solr Ref Guide for
information on upgrading from previous Solr versions:</p>
<p><a
href="https://solr.apache.org/guide/solr/9_10/upgrade-notes/solr-upgrade-notes.html">https://solr.apache.org/guide/solr/9_10/upgrade-notes/solr-upgrade-notes.html</a></p>
<p>Please read CHANGELOG.md for a full list of bugfixes:</p>
-<p><a
href="https://solr.apache.org/9_10_1/changes/Changes.html">https://solr.apache.org/9_10_1/changes/Changes.html</a></p></content><category
term="solr/news"/></entry><entry><title>CVE-2025-66516: Apache Solr extraction
module vulnerable to XXE attacks via XFA content in PDFs</title><link
href="/cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs.html"
rel="alternate"/><published>2025-12-09T00:00:00+00:00</published><u [...]
+<p><a
href="https://solr.apache.org/9_10_1/changes/Changes.html">https://solr.apache.org/9_10_1/changes/Changes.html</a></p></content><category
term="solr/news"/></entry><entry><title>CVE-2026-22022: Unauthorized bypass of
certain "predefined permission" rules in the
RuleBasedAuthorizationPlugin</title><link
href="/cve-2026-22022-unauthorized-bypass-of-certain-predefined-permission-rules-in-the-rulebasedauthorizationplugin.html"
rel="alternate"/><published>2026-01 [...]
+moderate</p>
+<p><strong>Description</strong>
+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
…</p></summary><content
type="html"><p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong>
+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:</p>
+<ol>
+<li>Use of Solr's "RuleBasedAuthorizationPlugin"</li>
+<li>A RuleBasedAuthorizationPlugin config (see security.json) that
specifies multiple "roles"</li>
+<li>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".</li>
+<li>A RuleBasedAuthorizationPlugin permission list that doesn't define
the "all" pre-defined permission</li>
+<li>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)</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+monkeontheroof (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18054">SOLR-18054</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22022">CVE-2026-22022</a></li>
+</ul></content><category
term="solr/security"/></entry><entry><title>CVE-2026-22444: Insufficient
file-access checking in standalone core-creation requests</title><link
href="/cve-2026-22444-insufficient-file-access-checking-in-standalone-core-creation-requests.html"
rel="alternate"/><published>2026-01-20T00:00:00+00:00</published><updated>2026-01-20T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-01-20:/cve-2026-22444-insufficient-file-access
[...]
+moderate</p>
+<p><strong>Description</strong></p>
+<p>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. These read-only
…</p></summary><content
type="html"><p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong></p>
+<p>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. 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 [...]
+<p>Solr deployments are subject to this vulnerability if they meet the
following criteria:</p>
+<ol>
+<li>Solr is running in its "standalone" mode.</li>
+<li>Solr's "allowPath" setting is being used to restrict file access to
certain directories.</li>
+<li>Solr's "create core" API is exposed and accessible to untrusted
users. This can happen if Solr's RuleBasedAuthorizationPlugin 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.</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+Damon Toey (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18058">SOLR-18058</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22444">CVE-2026-22444</a></li>
+</ul></content><category
term="solr/security"/></entry><entry><title>CVE-2025-66516: Apache Solr
extraction module vulnerable to XXE attacks via XFA content in
PDFs</title><link
href="/cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs.html"
rel="alternate"/><published>2025-12-09T00:00:00+00:00</published><updated>2025-12-09T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2025-12-09:/cve-2025-66516-apache [...]
<p>High</p>
<p><strong>Versions Affected</strong></p>
<ul>
@@ -2248,71 +2291,4 @@ features of many of the world's largest internet
sites.</p>
<p>The release is available for immediate download at:</p>
<p><a
href="https://www.apache.org/dyn/closer.lua/lucene/solr/6.6.4">https://www.apache.org/dyn/closer.lua/lucene/solr/6.6.4</a></p>
<p>Please read CHANGES.txt for a detailed list of changes:</p>
-<p><a
href="https://solr.apache.org/6_6_4/changes/Changes.html">https://solr.apache.org/6_6_4/changes/Changes.html</a></p></content><category
term="solr/news"/></entry><entry><title>Apache Solr™ 7.3.1
available</title><link href="/"
rel="alternate"/><published>2018-05-15T00:00:00+00:00</published><updated>2018-05-15T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2018-05-15:/</id><summary
type="html"><p>The Lucene PMC is ple [...]
-<p>Solr is the popular, blazing fast, open source NoSQL search platform
from the
-Apache Lucene project. Its major features include powerful full-text search,
-hit highlighting, faceted search and analytics, rich document parsing,
-geospatial search, extensive …</p></summary><content
type="html"><p>The Lucene PMC is pleased to announce the release of
Apache Solr 7.3.1</p>
-<p>Solr is the popular, blazing fast, open source NoSQL search platform
from the
-Apache Lucene project. Its major features include powerful full-text search,
-hit highlighting, faceted search and analytics, rich document parsing,
-geospatial search, extensive REST APIs as well as parallel SQL. Solr is
-enterprise grade, secure and highly scalable, providing fault tolerant
-distributed search and indexing, and powers the search and navigation
-features of many of the world's largest internet sites.</p>
-<p>This release includes 9 bug fixes since the 7.3.0 release. Some of
the major fixes are:</p>
-<ul>
-<li>Upgrade commons-fileupload dependency to 1.3.3 to address
CVE-2016-1000031</li>
-<li>Deleting replicas sometimes fails and causes the replicas to exist
in the down state</li>
-<li>A successful restore collection should mark the shard state as
active and not buffering</li>
-<li>Do not allow to use absolute URIs for including other files in
solrconfig.xml and schema parsing</li>
-</ul>
-<p>Furthermore, this release includes Apache Lucene 7.3.1 which includes
1 bug
-fix since the 7.3.0 release.</p>
-<p>The release is available for immediate download at:</p>
-<p><a
href="https://www.apache.org/dyn/closer.lua/lucene/solr/7.3.1">https://www.apache.org/dyn/closer.lua/lucene/solr/7.3.1</a></p>
-<p>Please read CHANGES.txt for a detailed list of changes:</p>
-<p><a
href="https://solr.apache.org/7_3_1/changes/Changes.html">https://solr.apache.org/7_3_1/changes/Changes.html</a></p></content><category
term="solr/news"/></entry><entry><title>CVE-2018-1308: XXE attack through
Apache Solr's DIH's dataConfig request parameter</title><link
href="/cve-2018-1308-xxe-attack-through-apache-solrs-dihs-dataconfig-request-parameter.html"
rel="alternate"/><published>2018-04-08T00:00:00+00:00</published><updated>2018-04-08T00:00:00+00:
[...]
-<p><strong>Severity:</strong> Major</p>
-<p><strong>Vendor:</strong><br>
-The Apache Software Foundation</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Solr 1.2 to 6.6.2</li>
-<li>Solr 7.0.0 to 7.2.1</li>
-</ul>
-<p><strong>Description:</strong><br>
-The details of this vulnerability were reported to the Apache Security mailing
list. </p>
-<p>This vulnerability …</p></summary><content
type="html"><p>CVE-2018-1308: XXE attack through Apache Solr's DIH's
dataConfig request parameter</p>
-<p><strong>Severity:</strong> Major</p>
-<p><strong>Vendor:</strong><br>
-The Apache Software Foundation</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Solr 1.2 to 6.6.2</li>
-<li>Solr 7.0.0 to 7.2.1</li>
-</ul>
-<p><strong>Description:</strong><br>
-The details of this vulnerability were reported to the Apache Security mailing
list. </p>
-<p>This vulnerability relates to an XML external entity expansion (XXE)
in the
-<code>&amp;dataConfig=&lt;inlinexml&gt;</code>
parameter of Solr's DataImportHandler. It can be
-used as XXE using file/ftp/http protocols in order to read arbitrary local
-files from the Solr server or the internal network. See [1] for more
details.</p>
-<p><strong>Mitigation:</strong><br>
-Users are advised to upgrade to either Solr 6.6.3 or Solr 7.3.0 releases both
-of which address the vulnerability. Once upgrade is complete, no other steps
-are required. Those releases disable external entities in anonymous XML files
-passed through this request parameter. </p>
-<p>If users are unable to upgrade to Solr 6.6.3 or Solr 7.3.0 then they
are
-advised to disable data import handler in their solrconfig.xml file and
-restart their Solr instances. Alternatively, if Solr instances are only used
-locally without access to public internet, the vulnerability cannot be used
-directly, so it may not be required to update, and instead reverse proxies or
-Solr client applications should be guarded to not allow end users to inject
-<code>dataConfig</code> request parameters. Please refer to [2] on
how to correctly
-secure Solr servers.</p>
-<p><strong>Credit:</strong><br>
-麦 香浓郁</p>
-<p><strong>References:</strong></p>
-<p>[1] <a
href="https://issues.apache.org/jira/browse/SOLR-11971">https://issues.apache.org/jira/browse/SOLR-11971</a><br>
-[2] <a
href="https://cwiki.apache.org/confluence/display/solr/SolrSecurity">https://cwiki.apache.org/confluence/display/solr/SolrSecurity</a></p></content><category
term="solr/security"/></entry></feed>
\ No newline at end of file
+<p><a
href="https://solr.apache.org/6_6_4/changes/Changes.html">https://solr.apache.org/6_6_4/changes/Changes.html</a></p></content><category
term="solr/news"/></entry></feed>
\ No newline at end of file
diff --git a/output/feeds/solr/security.atom.xml
b/output/feeds/solr/security.atom.xml
index 817dcb232..b19605241 100644
--- a/output/feeds/solr/security.atom.xml
+++ b/output/feeds/solr/security.atom.xml
@@ -1,5 +1,48 @@
<?xml version="1.0" encoding="utf-8"?>
-<feed xmlns="http://www.w3.org/2005/Atom";><title>Apache Solr -
solr/security</title><link href="/" rel="alternate"/><link
href="/feeds/solr/security.atom.xml"
rel="self"/><id>/</id><updated>2025-12-09T00:00:00+00:00</updated><entry><title>CVE-2025-66516:
Apache Solr extraction module vulnerable to XXE attacks via XFA content in
PDFs</title><link
href="/cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs.html"
rel="alternate"/><published>2025-12- [...]
+<feed xmlns="http://www.w3.org/2005/Atom";><title>Apache Solr -
solr/security</title><link href="/" rel="alternate"/><link
href="/feeds/solr/security.atom.xml"
rel="self"/><id>/</id><updated>2026-01-20T00:00:00+00:00</updated><entry><title>CVE-2026-22022:
Unauthorized bypass of certain "predefined permission" rules in the
RuleBasedAuthorizationPlugin</title><link
href="/cve-2026-22022-unauthorized-bypass-of-certain-predefined-permission-rules-in-the-rulebasedauthorizationplugin.html"
rel= [...]
+moderate</p>
+<p><strong>Description</strong>
+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
…</p></summary><content
type="html"><p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong>
+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:</p>
+<ol>
+<li>Use of Solr's "RuleBasedAuthorizationPlugin"</li>
+<li>A RuleBasedAuthorizationPlugin config (see security.json) that
specifies multiple "roles"</li>
+<li>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".</li>
+<li>A RuleBasedAuthorizationPlugin permission list that doesn't define
the "all" pre-defined permission</li>
+<li>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)</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+monkeontheroof (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18054">SOLR-18054</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22022">CVE-2026-22022</a></li>
+</ul></content><category
term="solr/security"/></entry><entry><title>CVE-2026-22444: Insufficient
file-access checking in standalone core-creation requests</title><link
href="/cve-2026-22444-insufficient-file-access-checking-in-standalone-core-creation-requests.html"
rel="alternate"/><published>2026-01-20T00:00:00+00:00</published><updated>2026-01-20T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-01-20:/cve-2026-22444-insufficient-file-access
[...]
+moderate</p>
+<p><strong>Description</strong></p>
+<p>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. These read-only
…</p></summary><content
type="html"><p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong></p>
+<p>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. 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 [...]
+<p>Solr deployments are subject to this vulnerability if they meet the
following criteria:</p>
+<ol>
+<li>Solr is running in its "standalone" mode.</li>
+<li>Solr's "allowPath" setting is being used to restrict file access to
certain directories.</li>
+<li>Solr's "create core" API is exposed and accessible to untrusted
users. This can happen if Solr's RuleBasedAuthorizationPlugin 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.</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+Damon Toey (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18058">SOLR-18058</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22444">CVE-2026-22444</a></li>
+</ul></content><category
term="solr/security"/></entry><entry><title>CVE-2025-66516: Apache Solr
extraction module vulnerable to XXE attacks via XFA content in
PDFs</title><link
href="/cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs.html"
rel="alternate"/><published>2025-12-09T00:00:00+00:00</published><updated>2025-12-09T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2025-12-09:/cve-2025-66516-apache [...]
<p>High</p>
<p><strong>Versions Affected</strong></p>
<ul>
diff --git a/output/index.html b/output/index.html
index d3d58d729..a84ca2920 100644
--- a/output/index.html
+++ b/output/index.html
@@ -130,7 +130,7 @@
</div>
<div class="header-fill"></div>
-<section class="security" latest-date="2025-12-09">
+<section class="security" latest-date="2026-01-20">
<div class="row">
<div class="large-12 columns text-center">
<h2><a href="security.html">⚠ There are recent security
announcements. Read more on the Security page.</a></h2>
diff --git a/output/news.html b/output/news.html
index e3ef8eab9..d6927dd2f 100644
--- a/output/news.html
+++ b/output/news.html
@@ -169,6 +169,51 @@
<p><a
href="https://solr.apache.org/guide/solr/9_10/upgrade-notes/solr-upgrade-notes.html";>https://solr.apache.org/guide/solr/9_10/upgrade-notes/solr-upgrade-notes.html</a></p>
<p>Please read CHANGELOG.md for a full list of bugfixes:</p>
<p><a
href="https://solr.apache.org/9_10_1/changes/Changes.html";>https://solr.apache.org/9_10_1/changes/Changes.html</a></p>
+ <h2
id="cve-2026-22022-unauthorized-bypass-of-certain-predefined-permission-rules-in-the-rulebasedauthorizationplugin">20
January 2026, CVE-2026-22022: Unauthorized bypass of certain "predefined
permission" rules in the RuleBasedAuthorizationPlugin
+ <a class="headerlink"
href="#cve-2026-22022-unauthorized-bypass-of-certain-predefined-permission-rules-in-the-rulebasedauthorizationplugin"
title="Permanent link">¶</a>
+ </h2>
+ <p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong>
+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:</p>
+<ol>
+<li>Use of Solr's "RuleBasedAuthorizationPlugin"</li>
+<li>A RuleBasedAuthorizationPlugin config (see security.json) that specifies
multiple "roles"</li>
+<li>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".</li>
+<li>A RuleBasedAuthorizationPlugin permission list that doesn't define the
"all" pre-defined permission</li>
+<li>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)</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+monkeontheroof (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18054";>SOLR-18054</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22022";>CVE-2026-22022</a></li>
+</ul>
+ <h2
id="cve-2026-22444-insufficient-file-access-checking-in-standalone-core-creation-requests">20
January 2026, CVE-2026-22444: Insufficient file-access checking in standalone
core-creation requests
+ <a class="headerlink"
href="#cve-2026-22444-insufficient-file-access-checking-in-standalone-core-creation-requests"
title="Permanent link">¶</a>
+ </h2>
+ <p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong></p>
+<p>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. 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 NTL [...]
+<p>Solr deployments are subject to this vulnerability if they meet the
following criteria:</p>
+<ol>
+<li>Solr is running in its "standalone" mode.</li>
+<li>Solr's "allowPath" setting is being used to restrict file access to
certain directories.</li>
+<li>Solr's "create core" API is exposed and accessible to untrusted users.
This can happen if Solr's RuleBasedAuthorizationPlugin 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.</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+Damon Toey (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18058";>SOLR-18058</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22444";>CVE-2026-22444</a></li>
+</ul>
<h2
id="cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs">9
December 2025, CVE-2025-66516: Apache Solr extraction module vulnerable to XXE
attacks via XFA content in PDFs
<a class="headerlink"
href="#cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs"
title="Permanent link">¶</a>
</h2>
diff --git a/output/operator/index.html b/output/operator/index.html
index 4ef9cc8bb..037be7369 100644
--- a/output/operator/index.html
+++ b/output/operator/index.html
@@ -122,7 +122,7 @@
</div>
<div class="header-fill"></div>
-<section class="security" latest-date="2025-12-09">
+<section class="security" latest-date="2026-01-20">
<div class="row">
<div class="large-12 columns text-center">
<h2><a href="/security.html">⚠ There are recent security
announcements. Read more on the Solr Security page.</a></h2>
diff --git a/output/security.html b/output/security.html
index 9cd863888..c88116848 100644
--- a/output/security.html
+++ b/output/security.html
@@ -205,6 +205,16 @@ with you to see if we can provide this information in
other variations or format
<th width="95">Date</th>
<th>Announcement</th>
</tr>
+ <tr>
+ <td><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-22022";>CVE-2026-22022</a></td>
+ <td>2026-01-20</td>
+ <td><a
href="#cve-2026-22022-unauthorized-bypass-of-certain-predefined-permission-rules-in-the-rulebasedauthorizationplugin">Unauthorized
bypass of certain "predefined permission" rules in the
RuleBasedAuthorizationPlugin</a></td>
+ </tr>
+ <tr>
+ <td><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-22444";>CVE-2026-22444</a></td>
+ <td>2026-01-20</td>
+ <td><a
href="#cve-2026-22444-insufficient-file-access-checking-in-standalone-core-creation-requests">Insufficient
file-access checking in standalone core-creation requests</a></td>
+ </tr>
<tr>
<td><a
href="https://nvd.nist.gov/vuln/detail/CVE-2025-66516";>CVE-2025-66516</a></td>
<td>2025-12-09</td>
@@ -270,18 +280,55 @@ with you to see if we can provide this information in
other variations or format
<td>2021-12-18</td>
<td><a
href="#cve-2021-44548-apache-solr-information-disclosure-vulnerability-through-dataimporthandler">Apache
Solr information disclosure vulnerability through DataImportHandler</a></td>
</tr>
- <tr>
- <td><a
href="https://nvd.nist.gov/vuln/detail/CVE-2021-44228";>CVE-2021-44228</a></td>
- <td>2021-12-10</td>
- <td><a
href="#apache-solr-affected-by-apache-log4j-cve-2021-44228">Apache Solr
affected by Apache Log4J CVE-2021-44228</a></td>
- </tr>
- <tr>
- <td><a
href="https://nvd.nist.gov/vuln/detail/CVE-2021-27905";>CVE-2021-27905</a></td>
- <td>2021-04-12</td>
- <td><a
href="#cve-2021-27905-ssrf-vulnerability-with-the-replication-handler">SSRF
vulnerability with the Replication handler</a></td>
- </tr>
</table>
+ <h2
id="cve-2026-22022-unauthorized-bypass-of-certain-predefined-permission-rules-in-the-rulebasedauthorizationplugin">2026-01-20,
CVE-2026-22022: Unauthorized bypass of certain "predefined permission" rules
in the RuleBasedAuthorizationPlugin
+ <a class="headerlink"
href="#cve-2026-22022-unauthorized-bypass-of-certain-predefined-permission-rules-in-the-rulebasedauthorizationplugin"
title="Permanent link">¶</a>
+ </h2>
+ <p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong>
+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:</p>
+<ol>
+<li>Use of Solr's "RuleBasedAuthorizationPlugin"</li>
+<li>A RuleBasedAuthorizationPlugin config (see security.json) that specifies
multiple "roles"</li>
+<li>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".</li>
+<li>A RuleBasedAuthorizationPlugin permission list that doesn't define the
"all" pre-defined permission</li>
+<li>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)</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+monkeontheroof (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18054";>SOLR-18054</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22022";>CVE-2026-22022</a></li>
+</ul>
+ <hr/>
+ <h2
id="cve-2026-22444-insufficient-file-access-checking-in-standalone-core-creation-requests">2026-01-20,
CVE-2026-22444: Insufficient file-access checking in standalone core-creation
requests
+ <a class="headerlink"
href="#cve-2026-22444-insufficient-file-access-checking-in-standalone-core-creation-requests"
title="Permanent link">¶</a>
+ </h2>
+ <p><strong>Severity</strong>
+moderate</p>
+<p><strong>Description</strong></p>
+<p>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. 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 NTL [...]
+<p>Solr deployments are subject to this vulnerability if they meet the
following criteria:</p>
+<ol>
+<li>Solr is running in its "standalone" mode.</li>
+<li>Solr's "allowPath" setting is being used to restrict file access to
certain directories.</li>
+<li>Solr's "create core" API is exposed and accessible to untrusted users.
This can happen if Solr's RuleBasedAuthorizationPlugin 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.</li>
+</ol>
+<p><strong>Mitigation</strong></p>
+<p>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.</p>
+<p><strong>Credit</strong>
+Damon Toey (reporter)</p>
+<p><strong>References</strong></p>
+<ul>
+<li>JIRA - <a
href="https://issues.apache.org/jira/browse/SOLR-18058";>SOLR-18058</a></li>
+<li>CVE - <a
href="https://www.cve.org/CVERecord?id=CVE-2026-22444";>CVE-2026-22444</a></li>
+</ul>
+ <hr/>
<h2
id="cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs">2025-12-09,
CVE-2025-66516: Apache Solr extraction module vulnerable to XXE attacks via
XFA content in PDFs
<a class="headerlink"
href="#cve-2025-66516-apache-solr-extraction-module-vulnerable-to-xxe-attacks-via-xfa-content-in-pdfs"
title="Permanent link">¶</a>
</h2>
@@ -621,59 +668,6 @@ Upgrade to Solr 8.11.1, and/or ensure only trusted clients
can make requests to
Apache Solr would like to thank LaiHan of Nsfocus security team for reporting
the issue</p>
<p><strong>References:</strong><br>
Jira issue <a
href="https://issues.apache.org/jira/browse/SOLR-15826";>SOLR-15826</a></p>
- <hr/>
- <h2 id="apache-solr-affected-by-apache-log4j-cve-2021-44228">2021-12-10,
Apache Solr affected by Apache Log4J CVE-2021-44228
- <a class="headerlink"
href="#apache-solr-affected-by-apache-log4j-cve-2021-44228" title="Permanent
link">¶</a>
- </h2>
- <p><strong>Severity:</strong>
-Critical</p>
-<p><strong>Versions Affected:</strong>
-7.4.0 to 7.7.3, 8.0.0 to 8.11.0</p>
-<p><strong>Description:</strong>
-Apache Solr releases prior to 8.11.1 were using a bundled version of the
Apache Log4J library vulnerable to RCE. For full impact and additional detail
consult the Log4J security page.</p>
-<p>Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7 through
7.3) use Log4J 1.2.17 which may be vulnerable for installations using
non-default logging configurations that include the JMS Appender, see <a
href="https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126";>https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126</a>
for discussion.</p>
-<p>Solr's Prometheus Exporter uses Log4J as well but it does not log user
input or data, so we don't see a risk there.</p>
-<p>Solr is <em>not</em> vulnerable to the followup
<strong>CVE-2021-45046</strong> and <strong>CVE-2021-45105</strong>. A listing
of these and other CVEs with some justifications are listed in Solr's wiki: <a
href="https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools";>https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools</a></p>
-<p><strong>Mitigation:</strong>
-Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
-<ul>
-<li>Upgrade to <code>Solr 8.11.1</code> or greater (when available), which
will include an updated version (<code>>= 2.16.0</code>) of the Log4J
dependency.</li>
-<li>If you are using Solr's official docker image, it has already been
mitigated in all versions listed as supported on Docker Hub: <a
href="https://hub.docker.com/_/solr";>https://hub.docker.com/_/solr</a>. You
may need to re-pull the image.</li>
-<li>Manually update the version of Log4J on your runtime classpath and restart
your Solr application.</li>
-<li>(Linux/MacOS) Edit your <code>solr.in.sh</code> file to include:
- <code>SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"</code></li>
-<li>(Windows) Edit your <code>solr.in.cmd</code> file to include:
- <code>set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true</code></li>
-<li>Follow any of the other mitgations listed at <a
href="https://logging.apache.org/log4j/2.x/security.html";>https://logging.apache.org/log4j/2.x/security.html</a></li>
-</ul>
-<p>The Log4J security page refers to setting
<code>log4j2.formatMsgNoLookups=true</code> as a "discredited" mitigation. In
reality, it depends.
-We've looked at the root cause and audited the code paths that lead to the
vulnerability, and we feel confident in this mitigation being sufficient for
Solr.
-See <a
href="https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz";>https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz</a>
for discussion.</p>
-<p><strong>References:</strong>
-<a
href="https://logging.apache.org/log4j/2.x/security.html";>https://logging.apache.org/log4j/2.x/security.html</a></p>
- <hr/>
- <h2
id="cve-2021-27905-ssrf-vulnerability-with-the-replication-handler">2021-04-12,
CVE-2021-27905: SSRF vulnerability with the Replication handler
- <a class="headerlink"
href="#cve-2021-27905-ssrf-vulnerability-with-the-replication-handler"
title="Permanent link">¶</a>
- </h2>
- <p><strong>Severity:</strong>
-High</p>
-<p><strong>Versions Affected:</strong>
-7.0.0 to 7.7.3
-8.0.0 to 8.8.1</p>
-<p><strong>Description:</strong>
-The ReplicationHandler (normally registered at "/replication" under a Solr
core) has a "masterUrl" (also "leaderUrl" alias) parameter that is used to
designate another ReplicationHandler on another Solr core to replicate index
data into the local core.
-To prevent a SSRF vulnerability, Solr ought to check these parameters against
a similar configuration it uses for the "shards" parameter. Prior to this bug
getting fixed, it did not.</p>
-<p><strong>Mitigation:</strong>
-Any of the following are enough to prevent this vulnerability:</p>
-<ul>
-<li>Upgrade to <code>Solr 8.8.2</code> or greater.</li>
-<li>If upgrading is not an option, consider applying the patch in <a
href="https://issues.apache.org/jira/browse/SOLR-15217";>SOLR-15217</a></li>
-<li>Ensure that any access to the replication handler is purely internal to
Solr. Typically, it's only accessed externally for diagnostic/informational
purposes.</li>
-</ul>
-<p><strong>Credit:</strong>
-Reported by Caolinhong(Skay) from QI-ANXIN Cert (QI-ANXIN Technology Group
Inc.)</p>
-<p><strong>References:</strong>
-<a href="https://issues.apache.org/jira/browse/SOLR-15217";>SOLR-15217</a>:
CVE-2021-27905: SSRF vulnerability with the Replication handler</p>
<hr/>
<h1 id="cve-reports-for-apache-solr-dependencies">CVE reports for Apache
Solr dependencies</h1>
<p>Below is a list of CVE vulnerabilities in Apache Solr dependencies, and
the state of their applicability to Solr.</p>
