You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@solr.apache.org by gi...@apache.org on 2026/07/13 11:44:48 UTC
(solr-site) branch asf-staging updated: Commit build products
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 0744f649b Commit build products
0744f649b is described below
commit 0744f649bc791203283dae17c3eb05bd2804219b
Author: Build Pelican (action) <pr...@infra.apache.org>
AuthorDate: Mon Jul 13 11:44:43 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:security@apache.org">security@apache.org</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>