This is an automated email from the ASF dual-hosted git repository.
github-actions[bot] pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/solr-site.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new f29482d12 Commit build products
f29482d12 is described below
commit f29482d125f4c6e458b9fb94ed2905c05245bad2
Author: Build Pelican (action) <[email protected]>
AuthorDate: Sun Jun 21 18:52:49 2026 +0000
Commit build products
---
output/feeds/all.atom.xml | 182 ++++++++++++++++++++++--------------
output/feeds/solr/vex.atom.xml | 114 ++++++++++++++++++++++-
output/solr.vex.json | 206 ++++++++++++++++++++++++++---------------
output/vex.html | 161 ++++++++++++++++++++++++++++++++
4 files changed, 521 insertions(+), 142 deletions(-)
diff --git a/output/feeds/all.atom.xml b/output/feeds/all.atom.xml
index d9c1aadd6..85d68a7a1 100644
--- a/output/feeds/all.atom.xml
+++ b/output/feeds/all.atom.xml
@@ -42,7 +42,119 @@ Explicitly setting <code>blockUnknown</code> to
<code>true<
<p><strong>References</strong></p>
<ul>
<li><a
href="https://solr.apache.org/guide/solr/latest/deployment-guide/jwt-authentication-plugin.html">JWT
Authentication Plugin documentation</a></li>
-</ul></content><category
term="solr/security"/></entry><entry><title>Apache Log4j Core: TLS hostname
verification silently ignored in Socket, SMTP and Syslog appenders</title><link
href="/cve-2026-34477.html"
rel="alternate"/><published>2026-04-10T00:00:00+00:00</published><updated>2026-04-10T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-04-10:/cve-2026-34477.html</id><summary
type="html"><p>CVE-2026-34477 is <strong>not</stro [...]
+</ul></content><category
term="solr/security"/></entry><entry><title>Apache OpenNLP: XXE in dictionary
parsing</title><link href="/cve-2026-40682.html"
rel="alternate"/><published>2026-05-04T00:00:00+00:00</published><updated>2026-05-04T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-05-04:/cve-2026-40682.html</id><summary
type="html"><p>CVE-2026-40682 (CVSS 9.1) is an XML External Entity (XXE)
vulnerability in Apache OpenNLP's
+dictionary parsing. The <code>DictionaryEntryPersistor</code>
class and the public <code>Dictionary(InputStream)</code>
+constructor create a SAX parser without enabling
<code>FEATURE_SECURE_PROCESSING</code> or disabling DTD
+processing, so external entity resolution and DOCTYPE declarations remain
fully enabled. An attacker
+who can …</p></summary><content type="html"><p>CVE-2026-40682
(CVSS 9.1) is an XML External Entity (XXE) vulnerability in Apache OpenNLP's
+dictionary parsing. The <code>DictionaryEntryPersistor</code>
class and the public <code>Dictionary(InputStream)</code>
+constructor create a SAX parser without enabling
<code>FEATURE_SECURE_PROCESSING</code> or disabling DTD
+processing, so external entity resolution and DOCTYPE declarations remain
fully enabled. An attacker
+who can supply a crafted dictionary file — either directly or embedded in a
model archive that
+OpenNLP deserializes — can therefore read local files from the server or
trigger outbound requests
+(server-side request forgery). Other OpenNLP XML parsing paths route through
the hardened
+<code>XmlUtil.createSaxParser()</code> helper, but this code path
does not.</p>
+<p>The vulnerable code is present in the
<code>opennlp-tools-1.9.4.jar</code> that Solr pulls in
transitively via
+<code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is a
<code>opennlp-tools-1.9.5</code> release happening, but it hasn't
finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9
(and 3.0.0-M3), which parse dictionaries with secure
+XML processing that rejects DOCTYPE declarations and external
entities.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a
class="headerlink" href="#when-solr-is-exposed" title="Permanent
link">&para;</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is
exploitable once the OpenNLP-backed
+modules are enabled. The vulnerable dictionary-parsing code path becomes
reachable when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or
<code>langid</code> modules are enabled — they are not loaded by
default.</li>
+<li>OpenNLP analysis components or update processors are configured to
load OpenNLP model or
+ dictionary files (the schema-configured OpenNLP analyzers — tokenizer, POS,
chunker, lemmatizer,
+ name-finder — or the <code>langid</code> /
<code>analysis-extras</code> update processors).</li>
+</ul>
+<p>Any deployment that enables these modules and parses an OpenNLP model
or dictionary an attacker can
+influence is exploitable. A deployment that does not enable them never parses
an OpenNLP dictionary
+and is not exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the
OpenNLP-backed <code>analysis-extras</code> or
<code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load
model and dictionary files only from
+locations you fully control, since the bundled OpenNLP 1.9.4 does not disable
external entities when
+parsing dictionaries.</p>
+<p>Every OpenNLP model and dictionary is loaded as a resource through
Solr's resource loaders, so the
+archive passes through a single chokepoint before OpenNLP is allowed to
deserialize it. This applies
+to both standalone (filesystem configset) and SolrCloud (ZooKeeper)
deployments, and whether the
+dictionary is loaded by the <code>langid</code> /
<code>analysis-extras</code> update processors or by the
+schema-configured OpenNLP analyzers.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to
2.5.9.</p></content><category
term="solr/vex"/></entry><entry><title>Apache OpenNLP: Arbitrary class
instantiation via model manifest</title><link href="/cve-2026-42027.html"
rel="alternate"/><published>2026-05-04T00:00:00+00:00</published><updated>2026-05-04T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-05-04:/cve- [...]
+<code>ExtensionLoader</code>. The
<code>instantiateExtension(Class, String)</code> method loads a
class named in a
+model archive's <code>manifest.properties</code> via
<code>Class.forName()</code> and only performs its
+<code>isAssignableFrom</code> type check
<em>after</em> the class has been loaded. Because
<code>Class.forName()</code>
+runs the …</p></summary><content type="html"><p>CVE-2026-42027
(CVSS 9.8) is an arbitrary class instantiation issue in Apache OpenNLP's
+<code>ExtensionLoader</code>. The
<code>instantiateExtension(Class, String)</code> method loads a
class named in a
+model archive's <code>manifest.properties</code> via
<code>Class.forName()</code> and only performs its
+<code>isAssignableFrom</code> type check
<em>after</em> the class has been loaded. Because
<code>Class.forName()</code>
+runs the target class's static initializer at load time, an attacker who can
supply a crafted
+model archive can trigger the static initializer of any class on the classpath
(e.g. one that
+performs a JNDI lookup, outbound network I/O, or filesystem access),
regardless of the
+type check that follows.</p>
+<p>The vulnerable code is present in the
<code>opennlp-tools-1.9.4.jar</code> that Solr pulls in transitively
+via <code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is
a <code>opennlp-tools-1.9.5</code> release happening, but it hasn't
finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9
(and 3.0.0-M3), which consults a
+package-prefix allowlist <em>before</em> calling
<code>Class.forName()</code>.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a
class="headerlink" href="#when-solr-is-exposed" title="Permanent
link">&para;</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is
exploitable once the OpenNLP-backed
+modules are enabled. The vulnerable code path becomes reachable when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or
<code>langid</code> modules are enabled — they are not loaded by
default.</li>
+<li>OpenNLP analysis components or update processors are configured to
load model files.</li>
+</ul>
+<p>Any deployment that enables these modules and loads an OpenNLP model
an attacker can influence is
+exploitable. A deployment that does not enable them never invokes
<code>ExtensionLoader</code> and is not
+exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the
OpenNLP-backed <code>analysis-extras</code> or
<code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load
model files only from locations you
+fully control and never from untrusted or user-supplied sources.</p>
+<p>In Solr 9.11.0 the upstream allowlist defense is backfilled at the
application layer, since the
+vulnerable jar cannot yet be upgraded (Solr must track the OpenNLP version
used by
+<code>lucene-analysis-opennlp</code>). Every OpenNLP model is
loaded as a resource through Solr's resource
+loaders, so the archive is validated at that single chokepoint before OpenNLP
is allowed to
+deserialize it:</p>
+<ul>
+<li>The archive is opened as a ZIP and every class name it declares —
the <code>manifest.properties</code>
+ <code>factory</code> entry and any class referenced from
embedded feature-generator XML descriptors — must
+ resolve under the <code>opennlp.</code> package
prefix.</li>
+<li>A model that names a class outside that prefix is rejected and never
reaches <code>ExtensionLoader</code>,
+ so no attacker-controlled static initializer can run.</li>
+<li>Validation covers both standalone (filesystem configset) and
SolrCloud (ZooKeeper) deployments,
+ and applies whether the model is loaded by the
<code>langid</code> / <code>analysis-extras</code>
update processors or
+ by the schema-configured OpenNLP analyzers (tokenizer, POS, chunker,
lemmatizer, name-finder).</li>
+</ul>
+<p>Solr's own usage only ever references built-in
<code>opennlp.*</code> factories, so legitimate models load
+unchanged; only crafted models that try to instantiate arbitrary classes are
blocked.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to
2.5.9.</p></content><category
term="solr/vex"/></entry><entry><title>Apache OpenNLP: Out-of-memory denial of
service via crafted model file</title><link href="/cve-2026-42440.html"
rel="alternate"/><published>2026-05-04T00:00:00+00:00</published><updated>2026-05-04T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-05-04 [...]
+model reader. The <code>AbstractModelReader</code> methods
<code>getOutcomes()</code>,
<code>getOutcomePatterns()</code> and
+<code>getPredicates()</code> read a 32-bit signed integer count
field from a binary model stream and pass it
+directly to an array allocation without validating it. An attacker who can
supply …</p></summary><content type="html"><p>CVE-2026-42440 (CVSS
7.5) is an out-of-memory denial-of-service issue in Apache OpenNLP's binary
+model reader. The <code>AbstractModelReader</code> methods
<code>getOutcomes()</code>,
<code>getOutcomePatterns()</code> and
+<code>getPredicates()</code> read a 32-bit signed integer count
field from a binary model stream and pass it
+directly to an array allocation without validating it. An attacker who can
supply a crafted <code>.bin</code>
+model file with a count set to <code>Integer.MAX_VALUE</code>
triggers an immediate <code>OutOfMemoryError</code> during
+model deserialization, before any substantial data is consumed.</p>
+<p>The vulnerable code is present in the
<code>opennlp-tools-1.9.4.jar</code> that Solr pulls in
transitively via
+<code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is a
<code>opennlp-tools-1.9.5</code> release happening, but it hasn't
finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9
(and 3.0.0-M3), which validate the count against an
+upper bound (default 10,000,000, configurable via the
<code>OPENNLP_MAX_ENTRIES</code> system property) before
+allocating.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a
class="headerlink" href="#when-solr-is-exposed" title="Permanent
link">&para;</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is
exploitable once the OpenNLP-backed
+modules are enabled. The vulnerable model-loading code path becomes reachable
when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or
<code>langid</code> modules are enabled — they are not loaded by
default.</li>
+<li>OpenNLP analysis components or update processors are configured to
load OpenNLP model files (the
+ schema-configured OpenNLP analyzers — tokenizer, POS, chunker, lemmatizer,
name-finder — or the
+ <code>langid</code> / <code>analysis-extras</code>
update processors).</li>
+</ul>
+<p>Any deployment that enables these modules and loads an OpenNLP model
an attacker can influence is
+exploitable. A deployment that does not enable them never deserializes an
OpenNLP model and is not
+exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the
OpenNLP-backed <code>analysis-extras</code> or
<code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load
model files only from locations you
+fully control and never from untrusted or user-supplied sources.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to
2.5.9.</p></content><category
term="solr/vex"/></entry><entry><title>Apache Log4j Core: TLS hostname
verification silently ignored in Socket, SMTP and Syslog appenders</title><link
href="/cve-2026-34477.html"
rel="alternate"/><published>2026-04-10T00:00:00+00:00</published><updated>2026-04-10T00:00:00+00:00</updated><author><name>Solr
Developers</name></au [...]
Successful exploitation requires a specific, non-default logging configuration
together with a privileged network position.
The following conditions <strong>must all be
met</strong>:</p>
<ul>
@@ -1517,70 +1629,4 @@ See <a
href="https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz
<p><a
href="https://apache.github.io/solr-operator/docs/upgrade-notes.html">https://apache.github.io/solr-operator/docs/upgrade-notes.html</a></p>
<p>For the most exhaustive list, see the change log on ArtifactHub or
view the git history in the solr-operator repo.</p>
<p><a
href="https://artifacthub.io/packages/helm/apache-solr/solr-operator?modal=changelog">https://artifacthub.io/packages/helm/apache-solr/solr-operator?modal=changelog</a></p>
-<p><a
href="https://github.com/apache/solr-operator/releases/tag/v0.4.0">https://github.com/apache/solr-operator/releases/tag/v0.4.0</a></p></content><category
term="solr/operator/news"/></entry><entry><title>Apache Solr™ 8.9.0
available</title><link href="/apache-solrtm-890-available.html"
rel="alternate"/><published>2021-06-16T00:00:00+00:00</published><updated>2021-06-16T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2021-06-1 [...]
-<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, dynamic clustering, database
integration, rich document handling, and …</p></summary><content
type="html"><p>The Solr PMC is pleased to announce the release of Apache
Solr 8.9.0.</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, dynamic clustering, database
integration, rich document handling, and geospatial search. Solr is 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>Solr 8.9.0 is available for immediate download at:</p>
-<p><a
href="https://solr.apache.org/downloads.html">https://solr.apache.org/downloads.html</a></p>
-<h3 id="solr-890-release-highlights">Solr 8.9.0 Release Highlights:<a
class="headerlink" href="#solr-890-release-highlights" title="Permanent
link">&para;</a></h3>
-<ul>
-<li>
-<p>Backup/Restore: Support for incremental backups, support for storing
backups in Google Cloud Storage (GCS), ability to restore on top of an existing
collection. Improved v2 API. Please see CHANGES.txt for details. (SOLR-15087,
SOLR-15090, SOLR-13608, SOLR-15101)</p>
-</li>
-<li>
-<p>Monitoring: New "Solr Cluster" row in Grafana dashboard, improved
Zookeeper monitoring, new shard health info in CLUSTERSTATUS and more. Please
see CHANGES.txt for details. (SOLR-15365, SOLR-15397, SOLR-15300, SOLR-15081,
SOLR-15383)</p>
-</li>
-<li>
-<p>Deprecations: The Metrics history feature has been deprecated and
will be removed in 9.0 (SOLR-15416)</p>
-</li>
-<li>
-<p>Admin UI: Query page now stores state in URL and can easily be shared
(SOLR-6152)</p>
-</li>
-<li>
-<p>Security: Jetty server upgraded to 9.4.41 which fixes some known
vulnerabilities (SOLR-15316)</p>
-</li>
-</ul>
-<p>A summary of important changes is published in the Solr Reference
Guide at <a
href="https://solr.apache.org/guide/8_9/solr-upgrade-notes.html">https://solr.apache.org/guide/8_9/solr-upgrade-notes.html</a>.</p>
-<p>For the most exhaustive list, see the full release notes at <a
href="https://solr.apache.org/8_9_0/changes/Changes.html">https://solr.apache.org/8_9_0/changes/Changes.html</a>
or by viewing the CHANGES.txt file accompanying the distribution.</p>
-<p>Solr's release notes usually don't include Lucene layer changes.
Lucene's release notes are at <a
href="https://lucene.apache.org/core/8_9_0/changes/Changes.html">https://lucene.apache.org/core/8_9_0/changes/Changes.html</a></p></content><category
term="solr/news"/></entry><entry><title>Apache Solr Operator™ v0.3.0
available</title><link href="/apache-solr-operatortm-v030-available.html"
rel="alternate"/><published>2021-04-29T00:00:00+00:00</published><updated [...]
-<p>The Apache Solr Operator is a safe and easy way of managing a Solr
ecosystem in Kubernetes.</p>
-<p>This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The
…</p></summary><content type="html"><p>The Solr PMC is pleased to
announce the release of the Apache Solr Operator v0.3.0.</p>
-<p>The Apache Solr Operator is a safe and easy way of managing a Solr
ecosystem in Kubernetes.</p>
-<p>This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is available for
immediate download at:</p>
-<p><a
href="https://solr.apache.org/operator/artifacts.html">https://solr.apache.org/operator/artifacts.html</a></p>
-<h3 id="solr-operator-v030-release-highlights">Solr Operator v0.3.0
Release Highlights:<a class="headerlink"
href="#solr-operator-v030-release-highlights" title="Permanent
link">&para;</a></h3>
-<ul>
-<li>The Solr Operator is now an Apache project managed by the Apache
Solr PMC.</li>
-<li>The CRDs are now under the solr.apache.org group instead of
solr.bloomberg.com.</li>
-<li>The Solr Operator now fully supports running Solr in a secure and
locked down way:</li>
-<li>Basic Auth support is now built in when requested in the SolrCloud
CRD</li>
-<li>Solr can be run with TLS (optional mTLS, if provided to the
operator)</li>
-<li>More helm chart options are provided to customize running the Solr
Operator</li>
-<li>The Zookeeper Operator is now up-to-date with the most recent
release, v0.2.9.</li>
-<li>It can now be installed as a helm-chart dependency with the Solr
Operator.</li>
-<li>Users can now provide custom Solr log4j.xml and Prometheus Exporter
config xml configMaps</li>
-<li>Fixed a bug in custom probes for Solr pods</li>
-<li>Solr pod shutdown is more graceful, has better coordination between
Kubernetes and Solr.</li>
-<li>SolrCloud can now be used with the Kubernetes HPA to autoscale Solr
Cloud pods.</li>
-</ul>
-<p>A summary of important changes is published in the documentation
at:</p>
-<p><a
href="https://apache.github.io/solr-operator/docs/upgrade-notes.html">https://apache.github.io/solr-operator/docs/upgrade-notes.html</a></p>
-<p>For the most exhaustive list, see the full release notes in the
Github Releases or by viewing the git history in the solr-operator
repo.</p>
-<p><a
href="https://github.com/apache/solr-operator/releases/tag/v0.3.0">https://github.com/apache/solr-operator/releases/tag/v0.3.0</a></p></content><category
term="solr/operator/news"/></entry><entry><title>Apache Solr™ 8.8.2
available</title><link href="/apache-solrtm-882-available.html"
rel="alternate"/><published>2021-04-12T00:00:00+00:00</published><updated>2021-04-12T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2021-04-1 [...]
-<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, dynamic clustering, database
integration, rich document handling, and …</p></summary><content
type="html"><p>The Solr PMC is pleased to announce the release of Apache
Solr 8.8.2.</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, dynamic clustering, database
integration, rich document handling, and geospatial search. Solr is 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>Solr 8.8.2 is available for immediate download at:</p>
-<p><a
href="https://solr.apache.org/downloads.html">https://solr.apache.org/downloads.html</a></p>
-<h3 id="solr-882-release-highlights">Solr 8.8.2 Release Highlights:<a
class="headerlink" href="#solr-882-release-highlights" title="Permanent
link">&para;</a></h3>
-<ul>
-<li>SOLR-15249: Properly set ZK ACLs on /security.json</li>
-<li>SOLR-15233: Set doAs param in
ConfigurableInternodeAuthHadoopPlugin</li>
-<li>SOLR-15217: Use shardsWhitelist in ReplicationHandler</li>
-<li>SOLR-15288: Hardening NODEDOWN event in collections using
PerReplicaStates</li>
-</ul>
-<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/8_8/solr-upgrade-notes.html">https://solr.apache.org/guide/8_8/solr-upgrade-notes.html</a></p>
-<p>Please read CHANGES.txt for a full list of bugfixes:</p>
-<p><a
href="https://solr.apache.org/8_8_2/changes/Changes.html">https://solr.apache.org/8_8_2/changes/Changes.html</a></p>
-<p>Solr 8.8.2 also includes bugfixes in the corresponding Apache Lucene
release:</p>
-<p><a
href="https://lucene.apache.org/core/8_8_2/changes/Changes.html">https://lucene.apache.org/core/8_8_2/changes/Changes.html</a></p></content><category
term="solr/news"/></entry></feed>
\ No newline at end of file
+<p><a
href="https://github.com/apache/solr-operator/releases/tag/v0.4.0">https://github.com/apache/solr-operator/releases/tag/v0.4.0</a></p></content><category
term="solr/operator/news"/></entry></feed>
\ No newline at end of file
diff --git a/output/feeds/solr/vex.atom.xml b/output/feeds/solr/vex.atom.xml
index 15ca522e1..cd8910192 100644
--- a/output/feeds/solr/vex.atom.xml
+++ b/output/feeds/solr/vex.atom.xml
@@ -1,5 +1,117 @@
<?xml version="1.0" encoding="utf-8"?>
-<feed xmlns="http://www.w3.org/2005/Atom";><title>Apache Solr -
solr/vex</title><link href="/" rel="alternate"/><link
href="/feeds/solr/vex.atom.xml"
rel="self"/><id>/</id><updated>2026-04-10T00:00:00+00:00</updated><entry><title>Apache
Log4j Core: TLS hostname verification silently ignored in Socket, SMTP and
Syslog appenders</title><link href="/cve-2026-34477.html"
rel="alternate"/><published>2026-04-10T00:00:00+00:00</published><updated>2026-04-10T00:00:00+00:00</updated><author><name>
[...]
+<feed xmlns="http://www.w3.org/2005/Atom";><title>Apache Solr -
solr/vex</title><link href="/" rel="alternate"/><link
href="/feeds/solr/vex.atom.xml"
rel="self"/><id>/</id><updated>2026-05-04T00:00:00+00:00</updated><entry><title>Apache
OpenNLP: XXE in dictionary parsing</title><link href="/cve-2026-40682.html"
rel="alternate"/><published>2026-05-04T00:00:00+00:00</published><updated>2026-05-04T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-05-04:/c [...]
+dictionary parsing. The <code>DictionaryEntryPersistor</code>
class and the public <code>Dictionary(InputStream)</code>
+constructor create a SAX parser without enabling
<code>FEATURE_SECURE_PROCESSING</code> or disabling DTD
+processing, so external entity resolution and DOCTYPE declarations remain
fully enabled. An attacker
+who can …</p></summary><content type="html"><p>CVE-2026-40682
(CVSS 9.1) is an XML External Entity (XXE) vulnerability in Apache OpenNLP's
+dictionary parsing. The <code>DictionaryEntryPersistor</code>
class and the public <code>Dictionary(InputStream)</code>
+constructor create a SAX parser without enabling
<code>FEATURE_SECURE_PROCESSING</code> or disabling DTD
+processing, so external entity resolution and DOCTYPE declarations remain
fully enabled. An attacker
+who can supply a crafted dictionary file — either directly or embedded in a
model archive that
+OpenNLP deserializes — can therefore read local files from the server or
trigger outbound requests
+(server-side request forgery). Other OpenNLP XML parsing paths route through
the hardened
+<code>XmlUtil.createSaxParser()</code> helper, but this code path
does not.</p>
+<p>The vulnerable code is present in the
<code>opennlp-tools-1.9.4.jar</code> that Solr pulls in
transitively via
+<code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is a
<code>opennlp-tools-1.9.5</code> release happening, but it hasn't
finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9
(and 3.0.0-M3), which parse dictionaries with secure
+XML processing that rejects DOCTYPE declarations and external
entities.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a
class="headerlink" href="#when-solr-is-exposed" title="Permanent
link">&para;</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is
exploitable once the OpenNLP-backed
+modules are enabled. The vulnerable dictionary-parsing code path becomes
reachable when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or
<code>langid</code> modules are enabled — they are not loaded by
default.</li>
+<li>OpenNLP analysis components or update processors are configured to
load OpenNLP model or
+ dictionary files (the schema-configured OpenNLP analyzers — tokenizer, POS,
chunker, lemmatizer,
+ name-finder — or the <code>langid</code> /
<code>analysis-extras</code> update processors).</li>
+</ul>
+<p>Any deployment that enables these modules and parses an OpenNLP model
or dictionary an attacker can
+influence is exploitable. A deployment that does not enable them never parses
an OpenNLP dictionary
+and is not exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the
OpenNLP-backed <code>analysis-extras</code> or
<code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load
model and dictionary files only from
+locations you fully control, since the bundled OpenNLP 1.9.4 does not disable
external entities when
+parsing dictionaries.</p>
+<p>Every OpenNLP model and dictionary is loaded as a resource through
Solr's resource loaders, so the
+archive passes through a single chokepoint before OpenNLP is allowed to
deserialize it. This applies
+to both standalone (filesystem configset) and SolrCloud (ZooKeeper)
deployments, and whether the
+dictionary is loaded by the <code>langid</code> /
<code>analysis-extras</code> update processors or by the
+schema-configured OpenNLP analyzers.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to
2.5.9.</p></content><category
term="solr/vex"/></entry><entry><title>Apache OpenNLP: Arbitrary class
instantiation via model manifest</title><link href="/cve-2026-42027.html"
rel="alternate"/><published>2026-05-04T00:00:00+00:00</published><updated>2026-05-04T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-05-04:/cve- [...]
+<code>ExtensionLoader</code>. The
<code>instantiateExtension(Class, String)</code> method loads a
class named in a
+model archive's <code>manifest.properties</code> via
<code>Class.forName()</code> and only performs its
+<code>isAssignableFrom</code> type check
<em>after</em> the class has been loaded. Because
<code>Class.forName()</code>
+runs the …</p></summary><content type="html"><p>CVE-2026-42027
(CVSS 9.8) is an arbitrary class instantiation issue in Apache OpenNLP's
+<code>ExtensionLoader</code>. The
<code>instantiateExtension(Class, String)</code> method loads a
class named in a
+model archive's <code>manifest.properties</code> via
<code>Class.forName()</code> and only performs its
+<code>isAssignableFrom</code> type check
<em>after</em> the class has been loaded. Because
<code>Class.forName()</code>
+runs the target class's static initializer at load time, an attacker who can
supply a crafted
+model archive can trigger the static initializer of any class on the classpath
(e.g. one that
+performs a JNDI lookup, outbound network I/O, or filesystem access),
regardless of the
+type check that follows.</p>
+<p>The vulnerable code is present in the
<code>opennlp-tools-1.9.4.jar</code> that Solr pulls in transitively
+via <code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is
a <code>opennlp-tools-1.9.5</code> release happening, but it hasn't
finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9
(and 3.0.0-M3), which consults a
+package-prefix allowlist <em>before</em> calling
<code>Class.forName()</code>.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a
class="headerlink" href="#when-solr-is-exposed" title="Permanent
link">&para;</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is
exploitable once the OpenNLP-backed
+modules are enabled. The vulnerable code path becomes reachable when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or
<code>langid</code> modules are enabled — they are not loaded by
default.</li>
+<li>OpenNLP analysis components or update processors are configured to
load model files.</li>
+</ul>
+<p>Any deployment that enables these modules and loads an OpenNLP model
an attacker can influence is
+exploitable. A deployment that does not enable them never invokes
<code>ExtensionLoader</code> and is not
+exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the
OpenNLP-backed <code>analysis-extras</code> or
<code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load
model files only from locations you
+fully control and never from untrusted or user-supplied sources.</p>
+<p>In Solr 9.11.0 the upstream allowlist defense is backfilled at the
application layer, since the
+vulnerable jar cannot yet be upgraded (Solr must track the OpenNLP version
used by
+<code>lucene-analysis-opennlp</code>). Every OpenNLP model is
loaded as a resource through Solr's resource
+loaders, so the archive is validated at that single chokepoint before OpenNLP
is allowed to
+deserialize it:</p>
+<ul>
+<li>The archive is opened as a ZIP and every class name it declares —
the <code>manifest.properties</code>
+ <code>factory</code> entry and any class referenced from
embedded feature-generator XML descriptors — must
+ resolve under the <code>opennlp.</code> package
prefix.</li>
+<li>A model that names a class outside that prefix is rejected and never
reaches <code>ExtensionLoader</code>,
+ so no attacker-controlled static initializer can run.</li>
+<li>Validation covers both standalone (filesystem configset) and
SolrCloud (ZooKeeper) deployments,
+ and applies whether the model is loaded by the
<code>langid</code> / <code>analysis-extras</code>
update processors or
+ by the schema-configured OpenNLP analyzers (tokenizer, POS, chunker,
lemmatizer, name-finder).</li>
+</ul>
+<p>Solr's own usage only ever references built-in
<code>opennlp.*</code> factories, so legitimate models load
+unchanged; only crafted models that try to instantiate arbitrary classes are
blocked.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to
2.5.9.</p></content><category
term="solr/vex"/></entry><entry><title>Apache OpenNLP: Out-of-memory denial of
service via crafted model file</title><link href="/cve-2026-42440.html"
rel="alternate"/><published>2026-05-04T00:00:00+00:00</published><updated>2026-05-04T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-05-04 [...]
+model reader. The <code>AbstractModelReader</code> methods
<code>getOutcomes()</code>,
<code>getOutcomePatterns()</code> and
+<code>getPredicates()</code> read a 32-bit signed integer count
field from a binary model stream and pass it
+directly to an array allocation without validating it. An attacker who can
supply …</p></summary><content type="html"><p>CVE-2026-42440 (CVSS
7.5) is an out-of-memory denial-of-service issue in Apache OpenNLP's binary
+model reader. The <code>AbstractModelReader</code> methods
<code>getOutcomes()</code>,
<code>getOutcomePatterns()</code> and
+<code>getPredicates()</code> read a 32-bit signed integer count
field from a binary model stream and pass it
+directly to an array allocation without validating it. An attacker who can
supply a crafted <code>.bin</code>
+model file with a count set to <code>Integer.MAX_VALUE</code>
triggers an immediate <code>OutOfMemoryError</code> during
+model deserialization, before any substantial data is consumed.</p>
+<p>The vulnerable code is present in the
<code>opennlp-tools-1.9.4.jar</code> that Solr pulls in
transitively via
+<code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is a
<code>opennlp-tools-1.9.5</code> release happening, but it hasn't
finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9
(and 3.0.0-M3), which validate the count against an
+upper bound (default 10,000,000, configurable via the
<code>OPENNLP_MAX_ENTRIES</code> system property) before
+allocating.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a
class="headerlink" href="#when-solr-is-exposed" title="Permanent
link">&para;</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is
exploitable once the OpenNLP-backed
+modules are enabled. The vulnerable model-loading code path becomes reachable
when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or
<code>langid</code> modules are enabled — they are not loaded by
default.</li>
+<li>OpenNLP analysis components or update processors are configured to
load OpenNLP model files (the
+ schema-configured OpenNLP analyzers — tokenizer, POS, chunker, lemmatizer,
name-finder — or the
+ <code>langid</code> / <code>analysis-extras</code>
update processors).</li>
+</ul>
+<p>Any deployment that enables these modules and loads an OpenNLP model
an attacker can influence is
+exploitable. A deployment that does not enable them never deserializes an
OpenNLP model and is not
+exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the
OpenNLP-backed <code>analysis-extras</code> or
<code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load
model files only from locations you
+fully control and never from untrusted or user-supplied sources.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to
2.5.9.</p></content><category
term="solr/vex"/></entry><entry><title>Apache Log4j Core: TLS hostname
verification silently ignored in Socket, SMTP and Syslog appenders</title><link
href="/cve-2026-34477.html"
rel="alternate"/><published>2026-04-10T00:00:00+00:00</published><updated>2026-04-10T00:00:00+00:00</updated><author><name>Solr
Developers</name></au [...]
Successful exploitation requires a specific, non-default logging configuration
together with a privileged network position.
The following conditions <strong>must all be
met</strong>:</p>
<ul>
diff --git a/output/solr.vex.json b/output/solr.vex.json
index fc3be49c6..bd2c632e8 100644
--- a/output/solr.vex.json
+++ b/output/solr.vex.json
@@ -7,7 +7,7 @@
"name": "solr",
"version": "SNAPSHOT",
"type": "application",
- "bom-ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "bom-ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
},
"vulnerabilities": [
@@ -23,7 +23,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -39,7 +39,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -55,7 +55,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -71,7 +71,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -87,7 +87,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -103,7 +103,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -119,7 +119,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -135,7 +135,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -151,7 +151,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -167,7 +167,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -183,7 +183,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -199,7 +199,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -215,7 +215,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -231,7 +231,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -247,7 +247,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -263,7 +263,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -279,7 +279,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -295,7 +295,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -311,7 +311,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -327,7 +327,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -343,7 +343,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -359,7 +359,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -375,7 +375,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -391,7 +391,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -407,7 +407,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -423,7 +423,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -439,7 +439,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -455,7 +455,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -471,7 +471,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -487,7 +487,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -503,7 +503,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -519,7 +519,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -535,7 +535,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -551,7 +551,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -567,7 +567,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -583,7 +583,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -599,7 +599,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -615,7 +615,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -631,7 +631,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -647,7 +647,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -663,7 +663,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -679,7 +679,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -695,7 +695,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -711,7 +711,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -727,7 +727,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -743,7 +743,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -759,7 +759,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -775,7 +775,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -791,7 +791,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -807,7 +807,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -823,7 +823,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -839,7 +839,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -855,7 +855,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -871,7 +871,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -887,7 +887,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -903,7 +903,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -919,7 +919,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -935,7 +935,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -951,7 +951,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -970,7 +970,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -986,7 +986,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1002,7 +1002,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1018,7 +1018,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1037,7 +1037,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1053,7 +1053,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1070,7 +1070,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1086,7 +1086,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1103,7 +1103,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1120,7 +1120,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1137,7 +1137,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1154,7 +1154,7 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
},
@@ -1171,7 +1171,67 @@
},
"affects": [
{
- "ref": "5236b97f-6aa9-5b4c-91b4-400c65345c60"
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-40682",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40682";
+ },
+ "analysis": {
+ "state": "exploitable",
+ "response": [
+ "workaround_available",
+ "update"
+ ],
+ "detail": "CVE-2026-40682 (CVSS 9.1) is an XML External Entity (XXE)
vulnerability in Apache OpenNLP's\ndictionary parsing. The
`DictionaryEntryPersistor` class and the public
`Dictionary(InputStream)`\nconstructor create a SAX parser without enabling
`FEATURE_SECURE_PROCESSING` or disabling DTD\nprocessing, so external entity
resolution and DOCTYPE declarations remain fully enabled. An attacker\nwho can
supply a crafted dictionary file \u2014 either directly or embedded in a mod
[...]
+ },
+ "affects": [
+ {
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-42027",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42027";
+ },
+ "analysis": {
+ "state": "exploitable",
+ "response": [
+ "workaround_available",
+ "update"
+ ],
+ "detail": "CVE-2026-42027 (CVSS 9.8) is an arbitrary class
instantiation issue in Apache OpenNLP's\n`ExtensionLoader`. The
`instantiateExtension(Class, String)` method loads a class named in a\nmodel
archive's `manifest.properties` via `Class.forName()` and only performs
its\n`isAssignableFrom` type check *after* the class has been loaded. Because
`Class.forName()`\nruns the target class's static initializer at load time, an
attacker who can supply a crafted\nmodel archive can tr [...]
+ },
+ "affects": [
+ {
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-42440",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42440";
+ },
+ "analysis": {
+ "state": "exploitable",
+ "response": [
+ "workaround_available",
+ "update"
+ ],
+ "detail": "CVE-2026-42440 (CVSS 7.5) is an out-of-memory
denial-of-service issue in Apache OpenNLP's binary\nmodel reader. The
`AbstractModelReader` methods `getOutcomes()`, `getOutcomePatterns()`
and\n`getPredicates()` read a 32-bit signed integer count field from a binary
model stream and pass it\ndirectly to an array allocation without validating
it. An attacker who can supply a crafted `.bin`\nmodel file with a count set to
`Integer.MAX_VALUE` triggers an immediate `OutOfMemo [...]
+ },
+ "affects": [
+ {
+ "ref": "0edd6956-499a-5872-92f9-1e68ba9c16b9"
}
]
}
diff --git a/output/vex.html b/output/vex.html
index a350724fd..0a37107b4 100644
--- a/output/vex.html
+++ b/output/vex.html
@@ -139,6 +139,167 @@
<h1>Apache Solr VEX</h1>
<p><a href="/security-dependency-cves.html">← Back to the dependency
CVE table</a></p>
+ <article id="cve-2026-42440" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-42440";>CVE-2026-42440</a>,
Apache OpenNLP: Out-of-memory denial of service via crafted model file</h3>
+ <div class="panel callout">
+ <p class="subheader">
+ <strong>Status:</strong>
+ <span class="cdx-exploitable">exploitable</span>
+ </p>
+ <p class="subheader"><strong>Affected Solr
versions:</strong> < 10.1.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-42440 (CVSS 7.5) is an out-of-memory
denial-of-service issue in Apache OpenNLP's binary
+model reader. The <code>AbstractModelReader</code> methods
<code>getOutcomes()</code>, <code>getOutcomePatterns()</code> and
+<code>getPredicates()</code> read a 32-bit signed integer count field from a
binary model stream and pass it
+directly to an array allocation without validating it. An attacker who can
supply a crafted <code>.bin</code>
+model file with a count set to <code>Integer.MAX_VALUE</code> triggers an
immediate <code>OutOfMemoryError</code> during
+model deserialization, before any substantial data is consumed.</p>
+<p>The vulnerable code is present in the <code>opennlp-tools-1.9.4.jar</code>
that Solr pulls in transitively via
+<code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is a
<code>opennlp-tools-1.9.5</code> release happening, but it hasn't finished or
been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9 (and
3.0.0-M3), which validate the count against an
+upper bound (default 10,000,000, configurable via the
<code>OPENNLP_MAX_ENTRIES</code> system property) before
+allocating.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a class="headerlink"
href="#when-solr-is-exposed" title="Permanent link">¶</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is exploitable
once the OpenNLP-backed
+modules are enabled. The vulnerable model-loading code path becomes reachable
when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or <code>langid</code> modules are
enabled — they are not loaded by default.</li>
+<li>OpenNLP analysis components or update processors are configured to load
OpenNLP model files (the
+ schema-configured OpenNLP analyzers — tokenizer, POS, chunker, lemmatizer,
name-finder — or the
+ <code>langid</code> / <code>analysis-extras</code> update processors).</li>
+</ul>
+<p>Any deployment that enables these modules and loads an OpenNLP model an
attacker can influence is
+exploitable. A deployment that does not enable them never deserializes an
OpenNLP model and is not
+exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink" href="#mitigation"
title="Permanent link">¶</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the OpenNLP-backed
<code>analysis-extras</code> or <code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load model
files only from locations you
+fully control and never from untrusted or user-supplied sources.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to 2.5.9.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-42440";>CVE-2026-42440</a></li>
+ </ul>
+ </article>
+ <article id="cve-2026-42027" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-42027";>CVE-2026-42027</a>,
Apache OpenNLP: Arbitrary class instantiation via model manifest</h3>
+ <div class="panel callout">
+ <p class="subheader">
+ <strong>Status:</strong>
+ <span class="cdx-exploitable">exploitable</span>
+ </p>
+ <p class="subheader"><strong>Affected Solr
versions:</strong> < 10.1.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-42027 (CVSS 9.8) is an arbitrary class
instantiation issue in Apache OpenNLP's
+<code>ExtensionLoader</code>. The <code>instantiateExtension(Class,
String)</code> method loads a class named in a
+model archive's <code>manifest.properties</code> via
<code>Class.forName()</code> and only performs its
+<code>isAssignableFrom</code> type check <em>after</em> the class has been
loaded. Because <code>Class.forName()</code>
+runs the target class's static initializer at load time, an attacker who can
supply a crafted
+model archive can trigger the static initializer of any class on the classpath
(e.g. one that
+performs a JNDI lookup, outbound network I/O, or filesystem access),
regardless of the
+type check that follows.</p>
+<p>The vulnerable code is present in the <code>opennlp-tools-1.9.4.jar</code>
that Solr pulls in transitively
+via <code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is a
<code>opennlp-tools-1.9.5</code> release happening, but it hasn't finished or
been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9 (and
3.0.0-M3), which consults a
+package-prefix allowlist <em>before</em> calling
<code>Class.forName()</code>.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a class="headerlink"
href="#when-solr-is-exposed" title="Permanent link">¶</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is exploitable
once the OpenNLP-backed
+modules are enabled. The vulnerable code path becomes reachable when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or <code>langid</code> modules are
enabled — they are not loaded by default.</li>
+<li>OpenNLP analysis components or update processors are configured to load
model files.</li>
+</ul>
+<p>Any deployment that enables these modules and loads an OpenNLP model an
attacker can influence is
+exploitable. A deployment that does not enable them never invokes
<code>ExtensionLoader</code> and is not
+exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink" href="#mitigation"
title="Permanent link">¶</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the OpenNLP-backed
<code>analysis-extras</code> or <code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load model
files only from locations you
+fully control and never from untrusted or user-supplied sources.</p>
+<p>In Solr 9.11.0 the upstream allowlist defense is backfilled at the
application layer, since the
+vulnerable jar cannot yet be upgraded (Solr must track the OpenNLP version
used by
+<code>lucene-analysis-opennlp</code>). Every OpenNLP model is loaded as a
resource through Solr's resource
+loaders, so the archive is validated at that single chokepoint before OpenNLP
is allowed to
+deserialize it:</p>
+<ul>
+<li>The archive is opened as a ZIP and every class name it declares — the
<code>manifest.properties</code>
+ <code>factory</code> entry and any class referenced from embedded
feature-generator XML descriptors — must
+ resolve under the <code>opennlp.</code> package prefix.</li>
+<li>A model that names a class outside that prefix is rejected and never
reaches <code>ExtensionLoader</code>,
+ so no attacker-controlled static initializer can run.</li>
+<li>Validation covers both standalone (filesystem configset) and SolrCloud
(ZooKeeper) deployments,
+ and applies whether the model is loaded by the <code>langid</code> /
<code>analysis-extras</code> update processors or
+ by the schema-configured OpenNLP analyzers (tokenizer, POS, chunker,
lemmatizer, name-finder).</li>
+</ul>
+<p>Solr's own usage only ever references built-in <code>opennlp.*</code>
factories, so legitimate models load
+unchanged; only crafted models that try to instantiate arbitrary classes are
blocked.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to 2.5.9.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-42027";>CVE-2026-42027</a></li>
+ </ul>
+ </article>
+ <article id="cve-2026-40682" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-40682";>CVE-2026-40682</a>,
Apache OpenNLP: XXE in dictionary parsing</h3>
+ <div class="panel callout">
+ <p class="subheader">
+ <strong>Status:</strong>
+ <span class="cdx-exploitable">exploitable</span>
+ </p>
+ <p class="subheader"><strong>Affected Solr
versions:</strong> < 10.1.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-40682 (CVSS 9.1) is an XML External Entity (XXE)
vulnerability in Apache OpenNLP's
+dictionary parsing. The <code>DictionaryEntryPersistor</code> class and the
public <code>Dictionary(InputStream)</code>
+constructor create a SAX parser without enabling
<code>FEATURE_SECURE_PROCESSING</code> or disabling DTD
+processing, so external entity resolution and DOCTYPE declarations remain
fully enabled. An attacker
+who can supply a crafted dictionary file — either directly or embedded in a
model archive that
+OpenNLP deserializes — can therefore read local files from the server or
trigger outbound requests
+(server-side request forgery). Other OpenNLP XML parsing paths route through
the hardened
+<code>XmlUtil.createSaxParser()</code> helper, but this code path does not.</p>
+<p>The vulnerable code is present in the <code>opennlp-tools-1.9.4.jar</code>
that Solr pulls in transitively via
+<code>lucene-analysis-opennlp</code> (Lucene 9.12.3). There is a
<code>opennlp-tools-1.9.5</code> release happening, but it hasn't finished or
been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9 (and
3.0.0-M3), which parse dictionaries with secure
+XML processing that rejects DOCTYPE declarations and external entities.</p>
+<h4 id="when-solr-is-exposed">When Solr is exposed<a class="headerlink"
href="#when-solr-is-exposed" title="Permanent link">¶</a></h4>
+<p>OpenNLP is not part of a default Solr installation, but it is exploitable
once the OpenNLP-backed
+modules are enabled. The vulnerable dictionary-parsing code path becomes
reachable when:</p>
+<ul>
+<li>The <code>analysis-extras</code> and/or <code>langid</code> modules are
enabled — they are not loaded by default.</li>
+<li>OpenNLP analysis components or update processors are configured to load
OpenNLP model or
+ dictionary files (the schema-configured OpenNLP analyzers — tokenizer, POS,
chunker, lemmatizer,
+ name-finder — or the <code>langid</code> / <code>analysis-extras</code>
update processors).</li>
+</ul>
+<p>Any deployment that enables these modules and parses an OpenNLP model or
dictionary an attacker can
+influence is exploitable. A deployment that does not enable them never parses
an OpenNLP dictionary
+and is not exposed.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink" href="#mitigation"
title="Permanent link">¶</a></h4>
+<p>The most reliable mitigation is to <strong>not enable the OpenNLP-backed
<code>analysis-extras</code> or <code>langid</code>
+modules</strong> unless they are required. If you do use OpenNLP, load model
and dictionary files only from
+locations you fully control, since the bundled OpenNLP 1.9.4 does not disable
external entities when
+parsing dictionaries.</p>
+<p>Every OpenNLP model and dictionary is loaded as a resource through Solr's
resource loaders, so the
+archive passes through a single chokepoint before OpenNLP is allowed to
deserialize it. This applies
+to both standalone (filesystem configset) and SolrCloud (ZooKeeper)
deployments, and whether the
+dictionary is loaded by the <code>langid</code> / <code>analysis-extras</code>
update processors or by the
+schema-configured OpenNLP analyzers.</p>
+<p>Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via
<code>lucene-analysis-opennlp</code>) to 2.5.9.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-40682";>CVE-2026-40682</a></li>
+ </ul>
+ </article>
<article id="cve-2026-34481" class="post panel radius">
<header class="post-header">
<h3 class="title"><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-34481";>CVE-2026-34481</a>,
Apache Log4j JSON Template Layout: Invalid JSON for non-finite floating-point
values</h3>
