This is an automated email from the ASF dual-hosted git repository.
github-actions[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 a736aa5e9 Commit build products
a736aa5e9 is described below
commit a736aa5e924e56db17b613a6e72eab8822a9396a
Author: Build Pelican (action) <[email protected]>
AuthorDate: Wed Jul 15 11:25:31 2026 +0000
Commit build products
---
output/feeds/all.atom.xml | 147 +++++++++++++++++--------
output/feeds/solr/vex.atom.xml | 99 ++++++++++++++++-
output/security-dependency-cves.html | 27 +++++
output/solr.vex.json | 208 ++++++++++++++++++++++-------------
output/vex.html | 148 +++++++++++++++++++++++++
5 files changed, 503 insertions(+), 126 deletions(-)
diff --git a/output/feeds/all.atom.xml b/output/feeds/all.atom.xml
index 6a10f3e46..8c8be4e08 100644
--- a/output/feeds/all.atom.xml
+++ b/output/feeds/all.atom.xml
@@ -1,5 +1,102 @@
<?xml version="1.0" encoding="utf-8"?>
-<feed xmlns="http://www.w3.org/2005/Atom"><title>Apache Solr</title><link
href="/" rel="alternate"/><link href="/feeds/all.atom.xml"
rel="self"/><id>/</id><updated>2026-05-19T00:00:00+00:00</updated><entry><title>JWT
Authentication: blockUnknown default allows unauthenticated access contrary to
documentation</title><link
href="/jwt-authentication-blockunknown-default-allows-unauthenticated-access-contrary-to-documentation.html"
rel="alternate"/><published>2026-05-19T00:00:00+00:00</publi [...]
+<feed xmlns="http://www.w3.org/2005/Atom"><title>Apache Solr</title><link
href="/" rel="alternate"/><link href="/feeds/all.atom.xml"
rel="self"/><id>/</id><updated>2026-06-18T00:00:00+00:00</updated><entry><title>Eclipse
Jetty: differential URI parsing can bypass front-end URI controls</title><link
href="/cve-2025-11143.html"
rel="alternate"/><published>2026-06-18T00:00:00+00:00</published><updated>2026-06-18T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:No [...]
+(CWE-20) in Eclipse Jetty's URI parser (<code>HttpURI</code>): it
interprets some invalid or unusual URIs
+differently from other common HTTP parsers. When a component in front of Jetty
parses the same URI
+differently, an attacker can craft …</p></summary><content
type="html"><p>CVE-2025-11143 (CVSS 6.5; 3.7 per the Eclipse Foundation)
is an improper-input-validation issue
+(CWE-20) in Eclipse Jetty's URI parser (<code>HttpURI</code>): it
interprets some invalid or unusual URIs
+differently from other common HTTP parsers. When a component in front of Jetty
parses the same URI
+differently, an attacker can craft a malformed URI to bypass URI-based
security controls (such as
+path allow/deny lists) or to reveal implementation details. It affects Jetty
9.4.0–9.4.58,
+10.0.0–10.0.26, 11.0.0–11.0.26, 12.0.0–12.0.30 and 12.1.0–12.1.4; it is fixed
in 9.4.59, 10.0.27,
+11.0.27, 12.0.31 and 12.1.5.</p>
+<p>CVE-2025-11143 is <strong>not</strong> considered
exploitable in production deployments of Apache Solr.
+Successful exploitation requires a specific, non-recommended configuration —
all of the following
+conditions must be true:</p>
+<ul>
+<li>Solr must be deployed behind an HTTP intermediary (reverse proxy,
load balancer, or API gateway)
+ that enforces <strong>URI-based</strong> access rules (for
example, blocking <code>/solr/admin/*</code> at the proxy
layer).</li>
+<li>That intermediary must be the <strong>sole</strong>
security gate — Solr's own <strong>authentication and
+ authorization must not be enabled</strong>.</li>
+</ul>
+<h4 id="why-solr-auth-is-a-complete-fix">Why Solr auth is a complete
fix<a class="headerlink" href="#why-solr-auth-is-a-complete-fix"
title="Permanent link">&para;</a></h4>
+<p>This is a <strong>differential-parsing</strong> issue: it
only has security impact when a front-end proxy makes an
+access-control decision based on its own URI interpretation and Solr has no
independent access control
+of its own. Solr enforces access control in its own servlet filter
(<code>SolrDispatchFilter</code> /
+the <code>AuthenticationPlugin</code> framework)
<strong>after</strong> Jetty has parsed the URI. Because Solr's
auth layer
+operates on the same already-resolved path that Jetty produced, it cannot be
confused by differential
+proxy/Jetty parsing — the bypass that the proxy grants does not help an
attacker get past Solr's own
+auth. Enabling Solr auth provides <strong>complete</strong>
protection, not merely a mitigating control. (This
+distinguishes CVE-2025-11143 from request-smuggling issues such as
CVE-2026-2332, where Solr auth
+reduces impact but does not eliminate all cross-connection effects.)</p>
+<p>The Apache Solr project considers authentication and authorization a
prerequisite for any
+production-secure deployment and explicitly warns against relying on
network-perimeter controls as the
+sole access mechanism. A deployment without Solr auth that relies on a proxy's
URI rules as its only
+security boundary is therefore outside the project's supported production
configuration.</p>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p></content><category
term="solr/vex"/></entry><entry><title>Eclipse Jetty: HTTP/1.1 request
smuggling via chunk-extension parsing</title><link href="/cve-2026-2332.html"
rel="alternate"/><published>2026-06-18T00:00:00+00:00</published><updated>2026-06-18T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-06-18:/cve-2026-2332.html</id><summary
type="html"><p>CVE-2026-2332 (CVSS 9.1) is an H [...]
+parser: the chunk-extension parser stops at a <code>\r\n</code>
inside a quoted string instead of treating it
+as an error, so a crafted chunk extension can desynchronize request boundaries
between Jetty and a
+front-end …</p></summary><content type="html"><p>CVE-2026-2332
(CVSS 9.1) is an HTTP request-smuggling issue (CWE-444) in Eclipse Jetty's
HTTP/1.1
+parser: the chunk-extension parser stops at a <code>\r\n</code>
inside a quoted string instead of treating it
+as an error, so a crafted chunk extension can desynchronize request boundaries
between Jetty and a
+front-end HTTP intermediary. It affects Jetty 9.4.0–9.4.59, 10.0.0–10.0.27,
11.0.0–11.0.27,
+12.0.0–12.0.32 and 12.1.0–12.1.6; it is fixed in 9.4.60, 10.0.28, 11.0.28,
12.0.33 and 12.1.7.</p>
+<p>Unlike optional Jetty features (for example the JASPI authenticator),
this is <strong>core request-parsing
+code</strong>. Solr embeds Jetty as its HTTP server and bundles the
vulnerable <code>jetty-http</code> module
+(<code>HttpParser</code>) —
<code>jetty-http-10.0.26.jar</code> in the Solr 9.x line, and Jetty
9.4.44 in earlier 9.x
+releases. Solr does not replace Jetty's wire-level HTTP parser, and it accepts
chunked request
+bodies, so the vulnerable parser handles incoming requests and the code path
is reachable.</p>
+<h4 id="exploitability-depends-on-a-fronting-proxy">Exploitability
depends on a fronting proxy<a class="headerlink"
href="#exploitability-depends-on-a-fronting-proxy" title="Permanent
link">&para;</a></h4>
+<p>Request smuggling is a <strong>desynchronization</strong>
attack: it requires a second HTTP processor in front of
+Jetty that parses the crafted chunk extension differently. It is therefore
only exploitable when Solr
+is deployed <strong>behind an HTTP intermediary</strong> — a
reverse proxy, load balancer, TLS terminator, or API
+gateway — that disagrees with Jetty on request boundaries. This is a common
Solr deployment, because
+operators frequently front Solr with such a proxy to add TLS and
authentication. A Solr instance that
+is <strong>not</strong> fronted by a mis-parsing intermediary has
no second parser to desync against, so this
+particular attack does not apply to it.</p>
+<p>The most damaging scenario is when that fronting proxy is the
<em>only</em> security boundary (it enforces
+authentication or restricts which Solr paths are reachable): a smuggled
request rides past the proxy
+and reaches Solr's APIs directly, bypassing those controls.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<ul>
+<li><strong>Use a re-encoding reverse proxy.</strong> A
reverse proxy that fully parses and re-encodes the HTTP/1.1
+ request body before forwarding to Jetty eliminates the attack at the network
boundary: the proxy
+ reads the attacker's malformed chunk extensions, then emits a clean,
standards-conformant chunked
+ (or <code>Content-Length</code>) request to Solr. No
attacker-controlled chunk extension survives the trip, so
+ Jetty never sees the malformed framing that triggers the desynchronization.
<strong>nginx</strong> (<code>proxy_pass</code>
+ in HTTP mode) and <strong>HAProxy</strong> (in
<code>http</code> mode) both re-encode by default. Proxies
configured in
+ TCP pass-through or tunnel mode (e.g., HAProxy <code>tcp</code>
mode, nginx <code>stream</code>) do <em>not</em>
re-encode and
+ do not mitigate this CVE.</li>
+<li><strong>Enable Solr's built-in authentication and
authorization.</strong> Solr enforces access control in its
+ own servlet filter (<code>SolrDispatchFilter</code> / the
<code>AuthenticationPlugin</code> framework),
<em>not</em> at the
+ Jetty layer, so a request smuggled past a front-end proxy still has to pass
Solr's own
+ authentication and authorization. Enabling them removes the "proxy is the
only gate" exposure that
+ makes this attack most severe. (This is a mitigating control, not a complete
fix — it does not
+ eliminate cross-connection effects such as request hijacking or response
desync.)</li>
+<li><strong>Upgrade the bundled Jetty</strong> to a patched
release (≥ 10.0.28 on the 10.0.x line), which is the
+ full fix, however that requires commercial support. See
https://webtide.com/end-of-life/ for options.</li>
+</ul>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p></content><category
term="solr/vex"/></entry><entry><title>Eclipse Jetty: privilege escalation via
uncleared JASPI ThreadLocals</title><link href="/cve-2026-5795.html"
rel="alternate"/><published>2026-06-18T00:00:00+00:00</published><updated>2026-06-18T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-06-18:/cve-2026-5795.html</id><summary
type="html"><p>CVE-2026-5795 (CVSS 7.4) is a bro [...]
+<code>JASPIAuthenticator</code> (the JSR-196 / Jakarta
Authentication "JASPI" integration). During an
+authentication check it sets thread-local state and, on an early return, fails
to clear it, so a
+subsequent request served by the same pooled thread can inherit that
authentication …</p></summary><content type="html"><p>CVE-2026-5795
(CVSS 7.4) is a broken-access-control / privilege-escalation issue in Eclipse
Jetty's
+<code>JASPIAuthenticator</code> (the JSR-196 / Jakarta
Authentication "JASPI" integration). During an
+authentication check it sets thread-local state and, on an early return, fails
to clear it, so a
+subsequent request served by the same pooled thread can inherit that
authentication state. It
+affects Jetty 9.4.0–9.4.60, 10.0.0–10.0.28, 11.0.0–11.0.28, 12.0.0–12.0.33 and
12.1.0–12.1.7; it is
+fixed in 9.4.61, 10.0.29, 11.0.29, 12.0.34 and 12.1.8.</p>
+<p>Apache Solr 9.x bundles an affected Jetty
(<code>jetty-server-10.0.26.jar</code> in the current 9.x line, and
+Jetty 9.4.44 in earlier 9.x releases), so dependency scanners flag this CVE.
Solr is <strong>not affected</strong>:</p>
+<ul>
+<li><strong>The vulnerable code is not shipped.</strong>
<code>JASPIAuthenticator</code> lives in Jetty's
<code>jetty-jaspi</code>
+ module. Solr does not depend on <code>jetty-jaspi</code> — it is
absent from Solr's dependency set (the build
+ pulls in <code>jetty-server</code>,
<code>jetty-security</code>,
<code>jetty-servlet</code>, etc., but not
<code>jetty-jaspi</code>), so the
+ vulnerable class is not on the classpath.</li>
+<li><strong>Solr does not use JASPI.</strong> Solr
authenticates requests in a servlet filter
+ (<code>SolrDispatchFilter</code>) through its own
<code>AuthenticationPlugin</code> framework (Basic, JWT, Kerberos,
+ PKI, etc.). It never installs a Jetty
<code>SecurityHandler</code>/<code>Authenticator</code>,
and never the JASPI
+ mechanism, so the vulnerable code path is unreachable even if the module
were present.</li>
+</ul>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p></content><category
term="solr/vex"/></entry><entry><title>JWT Authentication: blockUnknown default
allows unauthenticated access contrary to documentation</title><link
href="/jwt-authentication-blockunknown-default-allows-unauthenticated-access-contrary-to-documentation.html"
rel="alternate"/><published>2026-05-19T00:00:00+00:00</published><updated>2026-05-19T00:00:00+00:00</updated><author><name>Solr
Developers</name></author>< [...]
moderate</p>
<p><strong>Versions Affected</strong></p>
<ul>
@@ -1553,50 +1650,4 @@ See <a
href="https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz
<p><a
href="https://solr.apache.org/guide/operator/latest/upgrade-notes/upgrade-notes.html">https://solr.apache.org/guide/operator/latest/upgrade-notes/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.5.0">https://github.com/apache/solr-operator/releases/tag/v0.5.0</a></p></content><category
term="solr/operator/news"/></entry><entry><title>Apache Solr™ 8.11.0
available</title><link href="/apache-solrtm-8110-available.html"
rel="alternate"/><published>2021-11-16T00:00:00+00:00</published><updated>2021-11-16T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2021-11 [...]
-<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.11.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.11.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-8110-release-highlights">Solr 8.11.0 Release
Highlights:<a class="headerlink" href="#solr-8110-release-highlights"
title="Permanent link">&para;</a></h3>
-<h4 id="security">Security<a class="headerlink" href="#security"
title="Permanent link">&para;</a></h4>
-<p>MultiAuthPlugin (for authentication) and
MultiAuthRuleBasedAuthorizationPlugin (for authorization) classes to support
multiple authentication schemes, such as Bearer and Basic. This allows the
Admin UI to use OIDC (JWTAuthPlugin) to authenticate users while still
supporting Basic authentication for command-line tools and the Prometheus
exporter.</p>
-<p>A summary of important changes is published in the Solr Reference
Guide at <a
href="https://solr.apache.org/guide/8_11/solr-upgrade-notes.html">https://solr.apache.org/guide/8_11/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_11_0/changes/Changes.html">https://solr.apache.org/8_11_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_11_0/changes/Changes.html">https://lucene.apache.org/core/8_11_0/changes/Changes.html</a></p></content><category
term="solr/news"/></entry><entry><title>Apache Solr™ 8.10.1
available</title><link href="/apache-solrtm-8101-available.html"
rel="alternate"/><published>2021-10-18T00:00:00+00:00</published><updated>2021-10-18T00:0
[...]
-<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.10.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, 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.10.1 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-8101-release-highlights">Solr 8.10.1 Release
Highlights:<a class="headerlink" href="#solr-8101-release-highlights"
title="Permanent link">&para;</a></h3>
-<h4 id="dependencies-upgrades">Dependencies upgrades<a
class="headerlink" href="#dependencies-upgrades" title="Permanent
link">&para;</a></h4>
-<ul>
-<li>Upgrade httpclient and httpmime to 4.5.13 (SOLR-15269)</li>
-<li>Upgrade the following dependencies with vulnerabilities
(SOLR-15677)</li>
-<li>jetty: 9.4.44.v20210927</li>
-<li>tika: 1.27</li>
-<li>commons-compress: 1.21</li>
-<li>netty: 4.1.68.Final</li>
-<li>fasterxml.jackson: 2.12.3</li>
-<li>errorprone: 2.9.0</li>
-<li>gcp-client: 1.32.1</li>
-</ul>
-<p>A summary of important changes is published in the Solr Reference
Guide at <a
href="https://solr.apache.org/guide/8_10_1/solr-upgrade-notes.html">https://solr.apache.org/guide/8_10_1/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_10_1/changes/Changes.html">https://solr.apache.org/8_10_1/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_10_1/changes/Changes.html">https://lucene.apache.org/core/8_10_1/changes/Changes.html</a></p></content><category
term="solr/news"/></entry><entry><title>Apache Solr™ 8.10.0
available</title><link href="/apache-solrtm-8100-available.html"
rel="alternate"/><published>2021-09-27T00:00:00+00:00</published><updated>2021-09-27T00:0
[...]
-<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.10.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.10.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-8100-release-highlights">Solr 8.10.0 Release
Highlights:<a class="headerlink" href="#solr-8100-release-highlights"
title="Permanent link">&para;</a></h3>
-<h4 id="backup-restore">Backup / Restore<a class="headerlink"
href="#backup-restore" title="Permanent link">&para;</a></h4>
-<p>Backup / restore to / from Amazon S3 (SOLR-15089); included upgrading
the AWS SDK to v2 (SOLR-15599)</p>
-<h4 id="schema-designer-ui">Schema Designer UI<a class="headerlink"
href="#schema-designer-ui" title="Permanent
link">&para;</a></h4>
-<p>A new Admin UI screen to interactively design your Solr schema and
supporting ConfigSet files from sample data (SOLR-15277)</p>
-<h4 id="security-ui">Security UI<a class="headerlink"
href="#security-ui" title="Permanent link">&para;</a></h4>
-<p>A new Admin UI screen to manage users, roles, and permissions
(SOLR-15527)</p>
-<h4 id="sql-improvements">SQL Improvements<a class="headerlink"
href="#sql-improvements" title="Permanent
link">&para;</a></h4>
-<p>Several enhancements and bug fixes for Solr's Parallel SQL interface,
included upgrading Apache Calcite to 1.27.0 (SOLR-15460, SOLR-15451,
SOLR-15456, SOLR-15461, SOLR-15489, SOLR-15475, SOLR-15499, SOLR-15570,
SOLR-15576, SOLR-9853, SOLR-15579, SOLR-15566)</p>
-<p>A summary of important changes is published in the Solr Reference
Guide at <a
href="https://solr.apache.org/guide/8_10/solr-upgrade-notes.html">https://solr.apache.org/guide/8_10/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_10_0/changes/Changes.html">https://solr.apache.org/8_10_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_10_0/changes/Changes.html">https://lucene.apache.org/core/8_10_0/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.5.0">https://github.com/apache/solr-operator/releases/tag/v0.5.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 bd5618645..4eb616614 100644
--- a/output/feeds/solr/vex.atom.xml
+++ b/output/feeds/solr/vex.atom.xml
@@ -1,5 +1,102 @@
<?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-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 [...]
+<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-06-18T00:00:00+00:00</updated><entry><title>Eclipse
Jetty: differential URI parsing can bypass front-end URI controls</title><link
href="/cve-2025-11143.html"
rel="alternate"/><published>2026-06-18T00:00:00+00:00</published><updated>2026-06-18T00:00:00+00:00</updated><author><name>Solr
Developers</name></a [...]
+(CWE-20) in Eclipse Jetty's URI parser (<code>HttpURI</code>): it
interprets some invalid or unusual URIs
+differently from other common HTTP parsers. When a component in front of Jetty
parses the same URI
+differently, an attacker can craft …</p></summary><content
type="html"><p>CVE-2025-11143 (CVSS 6.5; 3.7 per the Eclipse Foundation)
is an improper-input-validation issue
+(CWE-20) in Eclipse Jetty's URI parser (<code>HttpURI</code>): it
interprets some invalid or unusual URIs
+differently from other common HTTP parsers. When a component in front of Jetty
parses the same URI
+differently, an attacker can craft a malformed URI to bypass URI-based
security controls (such as
+path allow/deny lists) or to reveal implementation details. It affects Jetty
9.4.0–9.4.58,
+10.0.0–10.0.26, 11.0.0–11.0.26, 12.0.0–12.0.30 and 12.1.0–12.1.4; it is fixed
in 9.4.59, 10.0.27,
+11.0.27, 12.0.31 and 12.1.5.</p>
+<p>CVE-2025-11143 is <strong>not</strong> considered
exploitable in production deployments of Apache Solr.
+Successful exploitation requires a specific, non-recommended configuration —
all of the following
+conditions must be true:</p>
+<ul>
+<li>Solr must be deployed behind an HTTP intermediary (reverse proxy,
load balancer, or API gateway)
+ that enforces <strong>URI-based</strong> access rules (for
example, blocking <code>/solr/admin/*</code> at the proxy
layer).</li>
+<li>That intermediary must be the <strong>sole</strong>
security gate — Solr's own <strong>authentication and
+ authorization must not be enabled</strong>.</li>
+</ul>
+<h4 id="why-solr-auth-is-a-complete-fix">Why Solr auth is a complete
fix<a class="headerlink" href="#why-solr-auth-is-a-complete-fix"
title="Permanent link">&para;</a></h4>
+<p>This is a <strong>differential-parsing</strong> issue: it
only has security impact when a front-end proxy makes an
+access-control decision based on its own URI interpretation and Solr has no
independent access control
+of its own. Solr enforces access control in its own servlet filter
(<code>SolrDispatchFilter</code> /
+the <code>AuthenticationPlugin</code> framework)
<strong>after</strong> Jetty has parsed the URI. Because Solr's
auth layer
+operates on the same already-resolved path that Jetty produced, it cannot be
confused by differential
+proxy/Jetty parsing — the bypass that the proxy grants does not help an
attacker get past Solr's own
+auth. Enabling Solr auth provides <strong>complete</strong>
protection, not merely a mitigating control. (This
+distinguishes CVE-2025-11143 from request-smuggling issues such as
CVE-2026-2332, where Solr auth
+reduces impact but does not eliminate all cross-connection effects.)</p>
+<p>The Apache Solr project considers authentication and authorization a
prerequisite for any
+production-secure deployment and explicitly warns against relying on
network-perimeter controls as the
+sole access mechanism. A deployment without Solr auth that relies on a proxy's
URI rules as its only
+security boundary is therefore outside the project's supported production
configuration.</p>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p></content><category
term="solr/vex"/></entry><entry><title>Eclipse Jetty: HTTP/1.1 request
smuggling via chunk-extension parsing</title><link href="/cve-2026-2332.html"
rel="alternate"/><published>2026-06-18T00:00:00+00:00</published><updated>2026-06-18T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-06-18:/cve-2026-2332.html</id><summary
type="html"><p>CVE-2026-2332 (CVSS 9.1) is an H [...]
+parser: the chunk-extension parser stops at a <code>\r\n</code>
inside a quoted string instead of treating it
+as an error, so a crafted chunk extension can desynchronize request boundaries
between Jetty and a
+front-end …</p></summary><content type="html"><p>CVE-2026-2332
(CVSS 9.1) is an HTTP request-smuggling issue (CWE-444) in Eclipse Jetty's
HTTP/1.1
+parser: the chunk-extension parser stops at a <code>\r\n</code>
inside a quoted string instead of treating it
+as an error, so a crafted chunk extension can desynchronize request boundaries
between Jetty and a
+front-end HTTP intermediary. It affects Jetty 9.4.0–9.4.59, 10.0.0–10.0.27,
11.0.0–11.0.27,
+12.0.0–12.0.32 and 12.1.0–12.1.6; it is fixed in 9.4.60, 10.0.28, 11.0.28,
12.0.33 and 12.1.7.</p>
+<p>Unlike optional Jetty features (for example the JASPI authenticator),
this is <strong>core request-parsing
+code</strong>. Solr embeds Jetty as its HTTP server and bundles the
vulnerable <code>jetty-http</code> module
+(<code>HttpParser</code>) —
<code>jetty-http-10.0.26.jar</code> in the Solr 9.x line, and Jetty
9.4.44 in earlier 9.x
+releases. Solr does not replace Jetty's wire-level HTTP parser, and it accepts
chunked request
+bodies, so the vulnerable parser handles incoming requests and the code path
is reachable.</p>
+<h4 id="exploitability-depends-on-a-fronting-proxy">Exploitability
depends on a fronting proxy<a class="headerlink"
href="#exploitability-depends-on-a-fronting-proxy" title="Permanent
link">&para;</a></h4>
+<p>Request smuggling is a <strong>desynchronization</strong>
attack: it requires a second HTTP processor in front of
+Jetty that parses the crafted chunk extension differently. It is therefore
only exploitable when Solr
+is deployed <strong>behind an HTTP intermediary</strong> — a
reverse proxy, load balancer, TLS terminator, or API
+gateway — that disagrees with Jetty on request boundaries. This is a common
Solr deployment, because
+operators frequently front Solr with such a proxy to add TLS and
authentication. A Solr instance that
+is <strong>not</strong> fronted by a mis-parsing intermediary has
no second parser to desync against, so this
+particular attack does not apply to it.</p>
+<p>The most damaging scenario is when that fronting proxy is the
<em>only</em> security boundary (it enforces
+authentication or restricts which Solr paths are reachable): a smuggled
request rides past the proxy
+and reaches Solr's APIs directly, bypassing those controls.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink"
href="#mitigation" title="Permanent link">&para;</a></h4>
+<ul>
+<li><strong>Use a re-encoding reverse proxy.</strong> A
reverse proxy that fully parses and re-encodes the HTTP/1.1
+ request body before forwarding to Jetty eliminates the attack at the network
boundary: the proxy
+ reads the attacker's malformed chunk extensions, then emits a clean,
standards-conformant chunked
+ (or <code>Content-Length</code>) request to Solr. No
attacker-controlled chunk extension survives the trip, so
+ Jetty never sees the malformed framing that triggers the desynchronization.
<strong>nginx</strong> (<code>proxy_pass</code>
+ in HTTP mode) and <strong>HAProxy</strong> (in
<code>http</code> mode) both re-encode by default. Proxies
configured in
+ TCP pass-through or tunnel mode (e.g., HAProxy <code>tcp</code>
mode, nginx <code>stream</code>) do <em>not</em>
re-encode and
+ do not mitigate this CVE.</li>
+<li><strong>Enable Solr's built-in authentication and
authorization.</strong> Solr enforces access control in its
+ own servlet filter (<code>SolrDispatchFilter</code> / the
<code>AuthenticationPlugin</code> framework),
<em>not</em> at the
+ Jetty layer, so a request smuggled past a front-end proxy still has to pass
Solr's own
+ authentication and authorization. Enabling them removes the "proxy is the
only gate" exposure that
+ makes this attack most severe. (This is a mitigating control, not a complete
fix — it does not
+ eliminate cross-connection effects such as request hijacking or response
desync.)</li>
+<li><strong>Upgrade the bundled Jetty</strong> to a patched
release (≥ 10.0.28 on the 10.0.x line), which is the
+ full fix, however that requires commercial support. See
https://webtide.com/end-of-life/ for options.</li>
+</ul>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p></content><category
term="solr/vex"/></entry><entry><title>Eclipse Jetty: privilege escalation via
uncleared JASPI ThreadLocals</title><link href="/cve-2026-5795.html"
rel="alternate"/><published>2026-06-18T00:00:00+00:00</published><updated>2026-06-18T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2026-06-18:/cve-2026-5795.html</id><summary
type="html"><p>CVE-2026-5795 (CVSS 7.4) is a bro [...]
+<code>JASPIAuthenticator</code> (the JSR-196 / Jakarta
Authentication "JASPI" integration). During an
+authentication check it sets thread-local state and, on an early return, fails
to clear it, so a
+subsequent request served by the same pooled thread can inherit that
authentication …</p></summary><content type="html"><p>CVE-2026-5795
(CVSS 7.4) is a broken-access-control / privilege-escalation issue in Eclipse
Jetty's
+<code>JASPIAuthenticator</code> (the JSR-196 / Jakarta
Authentication "JASPI" integration). During an
+authentication check it sets thread-local state and, on an early return, fails
to clear it, so a
+subsequent request served by the same pooled thread can inherit that
authentication state. It
+affects Jetty 9.4.0–9.4.60, 10.0.0–10.0.28, 11.0.0–11.0.28, 12.0.0–12.0.33 and
12.1.0–12.1.7; it is
+fixed in 9.4.61, 10.0.29, 11.0.29, 12.0.34 and 12.1.8.</p>
+<p>Apache Solr 9.x bundles an affected Jetty
(<code>jetty-server-10.0.26.jar</code> in the current 9.x line, and
+Jetty 9.4.44 in earlier 9.x releases), so dependency scanners flag this CVE.
Solr is <strong>not affected</strong>:</p>
+<ul>
+<li><strong>The vulnerable code is not shipped.</strong>
<code>JASPIAuthenticator</code> lives in Jetty's
<code>jetty-jaspi</code>
+ module. Solr does not depend on <code>jetty-jaspi</code> — it is
absent from Solr's dependency set (the build
+ pulls in <code>jetty-server</code>,
<code>jetty-security</code>,
<code>jetty-servlet</code>, etc., but not
<code>jetty-jaspi</code>), so the
+ vulnerable class is not on the classpath.</li>
+<li><strong>Solr does not use JASPI.</strong> Solr
authenticates requests in a servlet filter
+ (<code>SolrDispatchFilter</code>) through its own
<code>AuthenticationPlugin</code> framework (Basic, JWT, Kerberos,
+ PKI, etc.). It never installs a Jetty
<code>SecurityHandler</code>/<code>Authenticator</code>,
and never the JASPI
+ mechanism, so the vulnerable code path is unreachable even if the module
were present.</li>
+</ul>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p></content><category
term="solr/vex"/></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)
[...]
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
diff --git a/output/security-dependency-cves.html
b/output/security-dependency-cves.html
index 734a009ed..2f1fff7d6 100644
--- a/output/security-dependency-cves.html
+++ b/output/security-dependency-cves.html
@@ -180,6 +180,33 @@ or contact <a
href="mailto:[email protected]">[email protected]</a>.</p>
</tr>
<tr>
<td>
+<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-5795">CVE-2026-5795</a>
</td>
+ <td>≤ 9.x</td>
+ <td>
+ jetty-server-10.0.26.jar </td>
+ <td><span class="cdx-not-affected">not affected</span></td>
+ <td><a href="/vex.html#cve-2026-5795">Eclipse Jetty: privilege
escalation via uncleared JASPI ThreadLocals</a></td>
+ </tr>
+ <tr>
+ <td>
+<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-2332">CVE-2026-2332</a>
</td>
+ <td>≤ 9.x</td>
+ <td>
+ jetty-http-10.0.26.jar </td>
+ <td><span class="cdx-exploitable">exploitable</span></td>
+ <td><a href="/vex.html#cve-2026-2332">Eclipse Jetty: HTTP/1.1 request
smuggling via chunk-extension parsing</a></td>
+ </tr>
+ <tr>
+ <td>
+<a href="https://nvd.nist.gov/vuln/detail/CVE-2025-11143">CVE-2025-11143</a>
</td>
+ <td>≤ 9.x</td>
+ <td>
+ jetty-http-10.0.26.jar </td>
+ <td><span class="cdx-not-affected">not affected</span></td>
+ <td><a href="/vex.html#cve-2025-11143">Eclipse Jetty: differential URI
parsing can bypass front-end URI controls</a></td>
+ </tr>
+ <tr>
+ <td>
<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-42440">CVE-2026-42440</a>
</td>
<td>< 10.1.0</td>
<td>
diff --git a/output/solr.vex.json b/output/solr.vex.json
index c01cda8ff..74d2b50dc 100644
--- a/output/solr.vex.json
+++ b/output/solr.vex.json
@@ -7,7 +7,7 @@
"name": "solr",
"version": "SNAPSHOT",
"type": "application",
- "bom-ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "bom-ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
},
"vulnerabilities": [
@@ -23,7 +23,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -39,7 +39,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -55,7 +55,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -71,7 +71,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -87,7 +87,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -103,7 +103,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -119,7 +119,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -135,7 +135,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -151,7 +151,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -167,7 +167,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -183,7 +183,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -199,7 +199,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -215,7 +215,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -231,7 +231,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -247,7 +247,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -263,7 +263,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -279,7 +279,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -295,7 +295,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -311,7 +311,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -327,7 +327,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -343,7 +343,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -359,7 +359,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -375,7 +375,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -391,7 +391,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -407,7 +407,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -423,7 +423,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -439,7 +439,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -455,7 +455,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -471,7 +471,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -487,7 +487,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -503,7 +503,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -519,7 +519,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -535,7 +535,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -551,7 +551,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -567,7 +567,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -583,7 +583,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -599,7 +599,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -615,7 +615,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -631,7 +631,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -647,7 +647,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -663,7 +663,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -679,7 +679,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -695,7 +695,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -711,7 +711,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -727,7 +727,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -743,7 +743,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -759,7 +759,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -775,7 +775,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -791,7 +791,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -807,7 +807,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -823,7 +823,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -839,7 +839,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -855,7 +855,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -871,7 +871,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -887,7 +887,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -903,7 +903,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -919,7 +919,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -935,7 +935,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -951,7 +951,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -970,7 +970,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -986,7 +986,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1002,7 +1002,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1018,7 +1018,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1037,7 +1037,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1053,7 +1053,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1070,7 +1070,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1086,7 +1086,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1103,7 +1103,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1120,7 +1120,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1137,7 +1137,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1154,7 +1154,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1171,7 +1171,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1188,7 +1188,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1208,7 +1208,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1228,7 +1228,7 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
},
@@ -1248,7 +1248,61 @@
},
"affects": [
{
- "ref": "87b0825f-3532-5af7-be6b-bfda783d5759"
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2025-11143",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11143"
+ },
+ "analysis": {
+ "state": "not_affected",
+ "justification": "requires_configuration",
+ "detail": "CVE-2025-11143 (CVSS 6.5; 3.7 per the Eclipse Foundation)
is an improper-input-validation issue\n(CWE-20) in Eclipse Jetty's URI parser
(`HttpURI`): it interprets some invalid or unusual URIs\ndifferently from other
common HTTP parsers. When a component in front of Jetty parses the same
URI\ndifferently, an attacker can craft a malformed URI to bypass URI-based
security controls (such as\npath allow/deny lists) or to reveal implementation
details. It affects Jetty 9.4. [...]
+ },
+ "affects": [
+ {
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-2332",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2332"
+ },
+ "analysis": {
+ "state": "exploitable",
+ "response": [
+ "update",
+ "workaround_available"
+ ],
+ "detail": "CVE-2026-2332 (CVSS 9.1) is an HTTP request-smuggling issue
(CWE-444) in Eclipse Jetty's HTTP/1.1\nparser: the chunk-extension parser stops
at a `\\r\\n` inside a quoted string instead of treating it\nas an error, so a
crafted chunk extension can desynchronize request boundaries between Jetty and
a\nfront-end HTTP intermediary. It affects Jetty 9.4.0\u20139.4.59,
10.0.0\u201310.0.27, 11.0.0\u201311.0.27,\n12.0.0\u201312.0.32 and
12.1.0\u201312.1.6; it is fixed in 9.4.6 [...]
+ },
+ "affects": [
+ {
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-5795",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5795"
+ },
+ "analysis": {
+ "state": "not_affected",
+ "justification": "code_not_present",
+ "detail": "CVE-2026-5795 (CVSS 7.4) is a broken-access-control /
privilege-escalation issue in Eclipse Jetty's\n`JASPIAuthenticator` (the
JSR-196 / Jakarta Authentication \"JASPI\" integration). During
an\nauthentication check it sets thread-local state and, on an early return,
fails to clear it, so a\nsubsequent request served by the same pooled thread
can inherit that authentication state. It\naffects Jetty 9.4.0\u20139.4.60,
10.0.0\u201310.0.28, 11.0.0\u201311.0.28, 12.0.0\u20 [...]
+ },
+ "affects": [
+ {
+ "ref": "6328c22c-7278-5120-8827-4eedaee48107"
}
]
}
diff --git a/output/vex.html b/output/vex.html
index 3be5d20be..67facc358 100644
--- a/output/vex.html
+++ b/output/vex.html
@@ -142,6 +142,154 @@
<h1>Apache Solr VEX</h1>
<p><a href="/security-dependency-cves.html">← Back to the dependency
CVE table</a></p>
+ <article id="cve-2026-5795" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-5795">CVE-2026-5795</a>,
Eclipse Jetty: privilege escalation via uncleared JASPI ThreadLocals</h3>
+ <div class="panel callout">
+ <p class="subheader">
+ <strong>Status:</strong>
+ <span class="cdx-not-affected">not_affected</span>
+ </p>
+ <p class="subheader"><strong>Affected Solr
versions:</strong> ≤ 9.x</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-5795 (CVSS 7.4) is a broken-access-control /
privilege-escalation issue in Eclipse Jetty's
+<code>JASPIAuthenticator</code> (the JSR-196 / Jakarta Authentication "JASPI"
integration). During an
+authentication check it sets thread-local state and, on an early return, fails
to clear it, so a
+subsequent request served by the same pooled thread can inherit that
authentication state. It
+affects Jetty 9.4.0–9.4.60, 10.0.0–10.0.28, 11.0.0–11.0.28, 12.0.0–12.0.33 and
12.1.0–12.1.7; it is
+fixed in 9.4.61, 10.0.29, 11.0.29, 12.0.34 and 12.1.8.</p>
+<p>Apache Solr 9.x bundles an affected Jetty
(<code>jetty-server-10.0.26.jar</code> in the current 9.x line, and
+Jetty 9.4.44 in earlier 9.x releases), so dependency scanners flag this CVE.
Solr is <strong>not affected</strong>:</p>
+<ul>
+<li><strong>The vulnerable code is not shipped.</strong>
<code>JASPIAuthenticator</code> lives in Jetty's <code>jetty-jaspi</code>
+ module. Solr does not depend on <code>jetty-jaspi</code> — it is absent from
Solr's dependency set (the build
+ pulls in <code>jetty-server</code>, <code>jetty-security</code>,
<code>jetty-servlet</code>, etc., but not <code>jetty-jaspi</code>), so the
+ vulnerable class is not on the classpath.</li>
+<li><strong>Solr does not use JASPI.</strong> Solr authenticates requests in a
servlet filter
+ (<code>SolrDispatchFilter</code>) through its own
<code>AuthenticationPlugin</code> framework (Basic, JWT, Kerberos,
+ PKI, etc.). It never installs a Jetty
<code>SecurityHandler</code>/<code>Authenticator</code>, and never the JASPI
+ mechanism, so the vulnerable code path is unreachable even if the module
were present.</li>
+</ul>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-5795">CVE-2026-5795</a></li>
+ </ul>
+ </article>
+ <article id="cve-2026-2332" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-2332">CVE-2026-2332</a>,
Eclipse Jetty: HTTP/1.1 request smuggling via chunk-extension 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> ≤ 9.x</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-2332 (CVSS 9.1) is an HTTP request-smuggling issue
(CWE-444) in Eclipse Jetty's HTTP/1.1
+parser: the chunk-extension parser stops at a <code>\r\n</code> inside a
quoted string instead of treating it
+as an error, so a crafted chunk extension can desynchronize request boundaries
between Jetty and a
+front-end HTTP intermediary. It affects Jetty 9.4.0–9.4.59, 10.0.0–10.0.27,
11.0.0–11.0.27,
+12.0.0–12.0.32 and 12.1.0–12.1.6; it is fixed in 9.4.60, 10.0.28, 11.0.28,
12.0.33 and 12.1.7.</p>
+<p>Unlike optional Jetty features (for example the JASPI authenticator), this
is <strong>core request-parsing
+code</strong>. Solr embeds Jetty as its HTTP server and bundles the vulnerable
<code>jetty-http</code> module
+(<code>HttpParser</code>) — <code>jetty-http-10.0.26.jar</code> in the Solr
9.x line, and Jetty 9.4.44 in earlier 9.x
+releases. Solr does not replace Jetty's wire-level HTTP parser, and it accepts
chunked request
+bodies, so the vulnerable parser handles incoming requests and the code path
is reachable.</p>
+<h4 id="exploitability-depends-on-a-fronting-proxy">Exploitability depends on
a fronting proxy<a class="headerlink"
href="#exploitability-depends-on-a-fronting-proxy" title="Permanent
link">¶</a></h4>
+<p>Request smuggling is a <strong>desynchronization</strong> attack: it
requires a second HTTP processor in front of
+Jetty that parses the crafted chunk extension differently. It is therefore
only exploitable when Solr
+is deployed <strong>behind an HTTP intermediary</strong> — a reverse proxy,
load balancer, TLS terminator, or API
+gateway — that disagrees with Jetty on request boundaries. This is a common
Solr deployment, because
+operators frequently front Solr with such a proxy to add TLS and
authentication. A Solr instance that
+is <strong>not</strong> fronted by a mis-parsing intermediary has no second
parser to desync against, so this
+particular attack does not apply to it.</p>
+<p>The most damaging scenario is when that fronting proxy is the <em>only</em>
security boundary (it enforces
+authentication or restricts which Solr paths are reachable): a smuggled
request rides past the proxy
+and reaches Solr's APIs directly, bypassing those controls.</p>
+<h4 id="mitigation">Mitigation<a class="headerlink" href="#mitigation"
title="Permanent link">¶</a></h4>
+<ul>
+<li><strong>Use a re-encoding reverse proxy.</strong> A reverse proxy that
fully parses and re-encodes the HTTP/1.1
+ request body before forwarding to Jetty eliminates the attack at the network
boundary: the proxy
+ reads the attacker's malformed chunk extensions, then emits a clean,
standards-conformant chunked
+ (or <code>Content-Length</code>) request to Solr. No attacker-controlled
chunk extension survives the trip, so
+ Jetty never sees the malformed framing that triggers the desynchronization.
<strong>nginx</strong> (<code>proxy_pass</code>
+ in HTTP mode) and <strong>HAProxy</strong> (in <code>http</code> mode) both
re-encode by default. Proxies configured in
+ TCP pass-through or tunnel mode (e.g., HAProxy <code>tcp</code> mode, nginx
<code>stream</code>) do <em>not</em> re-encode and
+ do not mitigate this CVE.</li>
+<li><strong>Enable Solr's built-in authentication and authorization.</strong>
Solr enforces access control in its
+ own servlet filter (<code>SolrDispatchFilter</code> / the
<code>AuthenticationPlugin</code> framework), <em>not</em> at the
+ Jetty layer, so a request smuggled past a front-end proxy still has to pass
Solr's own
+ authentication and authorization. Enabling them removes the "proxy is the
only gate" exposure that
+ makes this attack most severe. (This is a mitigating control, not a complete
fix — it does not
+ eliminate cross-connection effects such as request hijacking or response
desync.)</li>
+<li><strong>Upgrade the bundled Jetty</strong> to a patched release (≥ 10.0.28
on the 10.0.x line), which is the
+ full fix, however that requires commercial support. See
https://webtide.com/end-of-life/ for options.</li>
+</ul>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a
href="https://nvd.nist.gov/vuln/detail/CVE-2026-2332">CVE-2026-2332</a></li>
+ </ul>
+ </article>
+ <article id="cve-2025-11143" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a
href="https://nvd.nist.gov/vuln/detail/CVE-2025-11143">CVE-2025-11143</a>,
Eclipse Jetty: differential URI parsing can bypass front-end URI controls</h3>
+ <div class="panel callout">
+ <p class="subheader">
+ <strong>Status:</strong>
+ <span class="cdx-not-affected">not_affected</span>
+ </p>
+ <p class="subheader"><strong>Affected Solr
versions:</strong> ≤ 9.x</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2025-11143 (CVSS 6.5; 3.7 per the Eclipse Foundation)
is an improper-input-validation issue
+(CWE-20) in Eclipse Jetty's URI parser (<code>HttpURI</code>): it interprets
some invalid or unusual URIs
+differently from other common HTTP parsers. When a component in front of Jetty
parses the same URI
+differently, an attacker can craft a malformed URI to bypass URI-based
security controls (such as
+path allow/deny lists) or to reveal implementation details. It affects Jetty
9.4.0–9.4.58,
+10.0.0–10.0.26, 11.0.0–11.0.26, 12.0.0–12.0.30 and 12.1.0–12.1.4; it is fixed
in 9.4.59, 10.0.27,
+11.0.27, 12.0.31 and 12.1.5.</p>
+<p>CVE-2025-11143 is <strong>not</strong> considered exploitable in production
deployments of Apache Solr.
+Successful exploitation requires a specific, non-recommended configuration —
all of the following
+conditions must be true:</p>
+<ul>
+<li>Solr must be deployed behind an HTTP intermediary (reverse proxy, load
balancer, or API gateway)
+ that enforces <strong>URI-based</strong> access rules (for example, blocking
<code>/solr/admin/*</code> at the proxy layer).</li>
+<li>That intermediary must be the <strong>sole</strong> security gate — Solr's
own <strong>authentication and
+ authorization must not be enabled</strong>.</li>
+</ul>
+<h4 id="why-solr-auth-is-a-complete-fix">Why Solr auth is a complete fix<a
class="headerlink" href="#why-solr-auth-is-a-complete-fix" title="Permanent
link">¶</a></h4>
+<p>This is a <strong>differential-parsing</strong> issue: it only has security
impact when a front-end proxy makes an
+access-control decision based on its own URI interpretation and Solr has no
independent access control
+of its own. Solr enforces access control in its own servlet filter
(<code>SolrDispatchFilter</code> /
+the <code>AuthenticationPlugin</code> framework) <strong>after</strong> Jetty
has parsed the URI. Because Solr's auth layer
+operates on the same already-resolved path that Jetty produced, it cannot be
confused by differential
+proxy/Jetty parsing — the bypass that the proxy grants does not help an
attacker get past Solr's own
+auth. Enabling Solr auth provides <strong>complete</strong> protection, not
merely a mitigating control. (This
+distinguishes CVE-2025-11143 from request-smuggling issues such as
CVE-2026-2332, where Solr auth
+reduces impact but does not eliminate all cross-connection effects.)</p>
+<p>The Apache Solr project considers authentication and authorization a
prerequisite for any
+production-secure deployment and explicitly warns against relying on
network-perimeter controls as the
+sole access mechanism. A deployment without Solr auth that relies on a proxy's
URI rules as its only
+security boundary is therefore outside the project's supported production
configuration.</p>
+<p>Solr 10.0 ships the fixed Jetty 12.0.34.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a
href="https://nvd.nist.gov/vuln/detail/CVE-2025-11143">CVE-2025-11143</a></li>
+ </ul>
+ </article>
<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>