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/09/16 16:38:18 UTC
(solr-site) branch asf-site 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-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 09e3a5973 Commit build products
09e3a5973 is described below
commit 09e3a5973206773ec5fcc54ff15f7be1050a3a96
Author: Build Pelican (action) <pr...@infra.apache.org>
AuthorDate: Wed Sep 16 16:38:14 2026 +0000
Commit build products
---
output/blog.html | 7 +
.../walking-document-graphs-in-apache-solr.html | 460 +++++++++++++++++++++
output/feeds/all.atom.xml | 253 ++++++------
output/feeds/solr/vex.atom.xml | 140 +++++--
output/posts.html | 22 +-
output/posts2.html | 26 +-
output/posts3.html | 26 +-
output/posts4.html | 26 +-
output/posts5.html | 26 +-
output/posts6.html | 26 +-
output/posts7.html | 26 +-
output/posts8.html | 26 +-
output/posts9.html | 13 +
output/security-dependency-cves.html | 45 ++
output/solr.openvex.json | 91 +++-
output/solr.vex.json | 393 +++++++++++-------
output/vex.html | 204 +++++++++
17 files changed, 1390 insertions(+), 420 deletions(-)
diff --git a/output/blog.html b/output/blog.html
index e422a979a..12b9aa4d6 100644
--- a/output/blog.html
+++ b/output/blog.html
@@ -153,6 +153,13 @@ If you have one you'd like to contribute, or would like to link out to an extern
<hr/>
+ <h2 id="walking-document-graphs-in-apache-solr">
+ <a href="blogposts/walking-document-graphs-in-apache-solr.html">
+ Walking Document Graphs in Apache Solr
+ </a>
+ </h2>
+ <h5>Published: 4 September 2026</h5>
+ <p><p>Solr can traverse multi-hop relationships already stored in the index — org charts, nested groups, product taxonomies — with the graph query parser. One hop is a join; the rest of the tree is a graph walk. Written by Prithvi S.</p></p>
<h2 id="solr-lucene-migration-correctness">
<a href="blogposts/solr-lucene-migration-correctness.html">
Validating Ranking Correctness During Solr/Lucene Migrations
diff --git a/output/blogposts/walking-document-graphs-in-apache-solr.html b/output/blogposts/walking-document-graphs-in-apache-solr.html
new file mode 100644
index 000000000..e3e36f70b
--- /dev/null
+++ b/output/blogposts/walking-document-graphs-in-apache-solr.html
@@ -0,0 +1,460 @@
+<!doctype html>
+<html>
+ <head>
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE- 2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<meta name="viewport" content="minimal-ui, initial-scale=1, maximum-scale=1, user-scalable=0">
+
+<link rel="stylesheet" href="/theme/css/google-fonts-raleway.css?v=501cdb3d" />
+<link rel="stylesheet" href="/theme/css/google-fonts-kalam.css?v=501cdb3d" />
+<link rel="stylesheet" href="/theme/css/font-awesome.min.css?v=501cdb3d" />
+<link rel="stylesheet" href="/theme/css/lib/foundation/normalize.css?v=501cdb3d" />
+<link rel="stylesheet" href="/theme/css/lib/foundation/foundation.min.css?v=501cdb3d"/>
+<link rel="stylesheet" href="/theme/css/lib/foundation/foundation-icons.css?v=501cdb3d"/>
+<link rel="stylesheet" href="/theme/css/base.css?v=501cdb3d" />
+<meta name="Distribution" content="Global"/>
+<meta name="Robots" content="index,follow"/>
+
+<script src="/theme/javascript/lib/jquery-2.1.1.min.js"></script>
+<script src="/theme/javascript/lib/foundation/modernizr.js?v=501cdb3d"></script>
+<script src="/theme/javascript/lib/angularjs/angular.min.js?v=501cdb3d"></script>
+<script src="/theme/javascript/lib/angularjs/angular-animate.min.js?v=501cdb3d"></script>
+<script src="/theme/javascript/lib/foundation/foundation.min.js?v=501cdb3d"></script>
+<script src="/theme/javascript/lib/jquery.smooth-scroll.min.js?v=501cdb3d"></script>
+<script src="/theme/javascript/main.js?v=501cdb3d"></script>
+<script src="https://www.apachecon.com/event-images/snippet.js"></script> <title>Walking Document Graphs in Apache Solr - Apache Solr</title>
+
+ <meta name="keywords"
+ content="apache, apache lucene, apache solr, solr, lucene,
+ search, information retrieval, spell checking, faceting, inverted index, open source"/>
+ <meta property="og:type" content="website" />
+ <meta property="og:url" content="https://solr.apache.org/blogposts/walking-document-graphs-in-apache-solr.html"/>
+ <meta property="og:title" content="Walking Document Graphs in Apache Solr"/>
+ <meta property="og:description" content="Walking Document Graphs in Apache Solr¶ Written by Prithvi S. A surprising number of Solr indexes already contain a graph. An..."/>
+ <meta property="og:image" content="https://solr.apache.org/theme/images/solr_og_image.png?v=501cdb3d"/>
+ <meta property="og:image:secure_url" content="https://solr.apache.org/theme/solr/solr_og_image.png?v=501cdb3d"/>
+
+ <link rel="icon" href="/theme/images/favicon.ico" type="image/x-icon">
+ <link rel="shortcut icon" href="/theme/images/favicon.ico" type="image/x-icon">
+<!-- Matomo -->
+<script>
+ var _paq = window._paq = window._paq || [];
+ /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
+ _paq.push(["setDoNotTrack", true]);
+ _paq.push(["disableCookies"]);
+ _paq.push(['trackPageView']);
+ _paq.push(['enableLinkTracking']);
+ (function() {
+ var u="https://analytics.apache.org/";
+ _paq.push(['setTrackerUrl', u+'matomo.php']);
+ _paq.push(['setSiteId', '76']);
+ var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
+ g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
+ })();
+</script>
+<!-- End Matomo Code --> </head>
+
+ <body class="page " x-ng-app="page" x-ng-controller="page.controllers.main">
+<div class="contain-to-grid">
+ <div class="header-section">
+ <nav class="top-bar" data-topbar role="navigation">
+ <ul class="title-area">
+ <li class="name">
+ <a href="/"><img class="logo" src="/theme/images/logo.svg" /></a>
+ </li>
+ <li class="toggle-topbar menu-icon"><a href="#"><span>Menu</span></a></li>
+ </ul>
+
+ <div class="top-bar-section">
+ <ul class="navigation right">
+ <li>
+ <a href="https://solr.apache.org/guide/solr/latest/">Docs</a>
+ </li>
+ <li class="has-dropdown">
+ <a href="/features.html">Learn</a>
+ <ul class="dropdown">
+ <li><a href="/features.html">Features</a></li>
+ <li><a href="/resources.html">Resources</a></li>
+ </ul>
+ </li>
+ <li>
+ <a href="/security.html">Security</a>
+ </li>
+ <li class="has-dropdown">
+ <a href="/community.html">About</a>
+ <ul class="dropdown">
+ <li><a href="/community.html">Community</a></li>
+ <li><a href="/whoweare.html">Project</a></li>
+ <li><a href="/posts.html">News</a></li>
+ </ul>
+ </li>
+ <li>
+ <a href="/operator/">Solr Operator</a>
+ </li>
+<!-- TODO Search not working as of feb 2021, disabling
+ <li class="toggle">
+ <a ng-hide="toggled" ng-click="toggle();" href="#">Search</a>
+ <div id="search">
+<form id="quick-search" method="GET" action="https://sematext.com/opensee/solr" name="searchform">
+ <fieldset>
+ <div ng-show="toggled" class="search-box ng-hide">
+ <input type="search" name="q" placeholder="Search..." accesskey="q"/>
+ <a class="search-button" type="submit" onclick="this.closest('form').submit();return false;"><img src="/theme/images/magnifying-glass.png"/></a>
+ </div>
+ </fieldset>
+</form> </div>
+ </li>
+-->
+ <li>
+ <a class="btn" href="/downloads.html">Download</a>
+ </li>
+ </ul>
+ </div>
+ </nav>
+ </div>
+</div>
+
+<div class="header-fill"></div>
+<div class="container">
+ <div class="row">
+<h1 id="walking-document-graphs-in-apache-solr">Walking Document Graphs in Apache Solr<a class="headerlink" href="#walking-document-graphs-in-apache-solr" title="Permanent link">¶</a></h1>
+<p>Written by <a href="https://github.com/iprithv">Prithvi S</a>.</p>
+<p>A surprising number of Solr indexes already contain a graph.</p>
+<p>An employee document points at a manager. A group lists the groups it belongs to. A category records its parent. Those pointers are ordinary string fields, so they are easy to index and easy to ignore. Then a product question shows up: <em>all engineers under this VP</em>, <em>every document this nested group can see</em>, <em>the full subtree of Electronics</em>. A <a href="https://solr.apache.org/guide/solr/latest/query-guide/join-query-parser.html">join</a> answers the one-hop vers [...]
+<p>This post is a worked example of that parser. It is not a rewrite of the reference guide. The goal is to show a realistic schema, the <code>from</code>/<code>to</code> footgun that catches people coming from <code>{!join}</code>, and the cases where you should pick a different tool.</p>
+<h2 id="one-hop-is-a-join-the-tree-is-a-graph">One hop is a join. The tree is a graph.<a class="headerlink" href="#one-hop-is-a-join-the-tree-is-a-graph" title="Permanent link">¶</a></h2>
+<p>Take a small org chart:</p>
+<div class="codehilite"><pre><span></span><code>alice (CEO)
+├── bob (Engineering Manager)
+│ ├── dave (Engineer)
+│ └── eve (Engineer, on leave)
+└── carol (Design Manager)
+ └── frank (Designer)
+</code></pre></div>
+
+<p>Each person is one Solr document. <code>id</code> is the person. <code>manager_id_s</code> is that person's pointer to their manager.</p>
+<div class="codehilite"><pre><span></span><code><span class="p">[</span>
+<span class="w"> </span><span class="p">{</span><span class="nt">"id"</span><span class="p">:</span><span class="s2">"alice"</span><span class="p">,</span><span class="w"> </span><span class="nt">"name_s"</span><span class="p">:</span><span class="s2">"Alice"</span><span class="p">,</span><span class="w"> </span><span class="nt">"title_s"</span><span class="p">:</span><span class="s2">"CEO"</span><span class="p">,</span><span c [...]
+<span class="w"> </span><span class="p">{</span><span class="nt">"id"</span><span class="p">:</span><span class="s2">"bob"</span><span class="p">,</span><span class="w"> </span><span class="nt">"name_s"</span><span class="p">:</span><span class="s2">"Bob"</span><span class="p">,</span><span class="w"> </span><span class="nt">"title_s"</span><span class="p">:</span><span class="s2">"Engineering Manager"</span><span class="p" [...]
+<span class="w"> </span><span class="p">{</span><span class="nt">"id"</span><span class="p">:</span><span class="s2">"carol"</span><span class="p">,</span><span class="w"> </span><span class="nt">"name_s"</span><span class="p">:</span><span class="s2">"Carol"</span><span class="p">,</span><span class="w"> </span><span class="nt">"title_s"</span><span class="p">:</span><span class="s2">"Design Manager"</span><span class="p">,</s [...]
+<span class="w"> </span><span class="p">{</span><span class="nt">"id"</span><span class="p">:</span><span class="s2">"dave"</span><span class="p">,</span><span class="w"> </span><span class="nt">"name_s"</span><span class="p">:</span><span class="s2">"Dave"</span><span class="p">,</span><span class="w"> </span><span class="nt">"title_s"</span><span class="p">:</span><span class="s2">"Engineer"</span><span class="p">,</span><s [...]
+<span class="w"> </span><span class="p">{</span><span class="nt">"id"</span><span class="p">:</span><span class="s2">"eve"</span><span class="p">,</span><span class="w"> </span><span class="nt">"name_s"</span><span class="p">:</span><span class="s2">"Eve"</span><span class="p">,</span><span class="w"> </span><span class="nt">"title_s"</span><span class="p">:</span><span class="s2">"Engineer"</span><span class="p">,</span><s [...]
+<span class="w"> </span><span class="p">{</span><span class="nt">"id"</span><span class="p">:</span><span class="s2">"frank"</span><span class="p">,</span><span class="w"> </span><span class="nt">"name_s"</span><span class="p">:</span><span class="s2">"Frank"</span><span class="p">,</span><span class="w"> </span><span class="nt">"title_s"</span><span class="p">:</span><span class="s2">"Designer"</span><span class="p">,</span><s [...]
+<span class="p">]</span>
+</code></pre></div>
+
+<p>A join finds Alice's <strong>direct</strong> reports — Bob and Carol, and nobody else:</p>
+<div class="codehilite"><pre><span></span><code>q={!join from=id to=manager_id_s}id:alice
+</code></pre></div>
+
+<p>Join semantics are: run the inner query, collect values from <code>from</code>, return documents whose <code>to</code> field contains those values. One hop. Dave and Frank never appear.</p>
+<p>The graph parser keeps walking until the frontier is empty.</p>
+<h2 id="index-the-org-chart">Index the org chart<a class="headerlink" href="#index-the-org-chart" title="Permanent link">¶</a></h2>
+<p>These examples use Solr 10's <code>_default</code> configset. The <code>_s</code> suffix gives you indexed string fields, which the graph parser accepts. Point fields with docValues also work; analyzed text fields do not.</p>
+<div class="codehilite"><pre><span></span><code>docker<span class="w"> </span>run<span class="w"> </span>--name<span class="w"> </span>solr-graph<span class="w"> </span>-d<span class="w"> </span>-p<span class="w"> </span><span class="m">8983</span>:8983<span class="w"> </span>solr:10.0.0<span class="w"> </span>solr-precreate<span class="w"> </span>orgchart
+<span class="k">until</span><span class="w"> </span>curl<span class="w"> </span>-sf<span class="w"> </span>http://localhost:8983/solr/orgchart/admin/ping<span class="w"> </span>>/dev/null<span class="p">;</span><span class="w"> </span><span class="k">do</span><span class="w"> </span>sleep<span class="w"> </span><span class="m">1</span><span class="p">;</span><span class="w"> </span><span class="k">done</span>
+
+curl<span class="w"> </span>-H<span class="w"> </span><span class="s1">'Content-Type: application/json'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span><span class="s1">'http://localhost:8983/solr/orgchart/update?commit=true'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-binary<span class="w"> </span><span class="s1">'[</span>
+<span class="s1"> {"id":"alice", "name_s":"Alice", "title_s":"CEO", "dept_s":"exec", "status_s":"active"},</span>
+<span class="s1"> {"id":"bob", "name_s":"Bob", "title_s":"Engineering Manager", "dept_s":"eng", "status_s":"active", "manager_id_s":"alice"},</span>
+<span class="s1"> {"id":"carol", "name_s":"Carol", "title_s":"Design Manager", "dept_s":"design", "status_s":"active", "manager_id_s":"alice"},</span>
+<span class="s1"> {"id":"dave", "name_s":"Dave", "title_s":"Engineer", "dept_s":"eng", "status_s":"active", "manager_id_s":"bob"},</span>
+<span class="s1"> {"id":"eve", "name_s":"Eve", "title_s":"Engineer", "dept_s":"eng", "status_s":"leave", "manager_id_s":"bob"},</span>
+<span class="s1"> {"id":"frank", "name_s":"Frank", "title_s":"Designer", "dept_s":"design", "status_s":"active", "manager_id_s":"carol"}</span>
+<span class="s1"> ]'</span>
+</code></pre></div>
+
+<h2 id="walk-down-everyone-under-alice">Walk down: everyone under Alice<a class="headerlink" href="#walk-down-everyone-under-alice" title="Permanent link">¶</a></h2>
+<div class="codehilite"><pre><span></span><code>curl<span class="w"> </span>-sG<span class="w"> </span><span class="s1">'http://localhost:8983/solr/orgchart/query'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'fl=id,name_s,title_s,manager_id_s'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'sort=id asc'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'q={!graph from=manager_id_s to=id}id:alice'</span>
+</code></pre></div>
+
+<p>That returns all six people. The parser:</p>
+<ol>
+<li>Runs the wrapped query <code>id:alice</code> to get the root set.</li>
+<li>Collects values from <code>to</code> (<code>id</code>) on the current frontier.</li>
+<li>Finds documents whose <code>from</code> field (<code>manager_id_s</code>) matches those values.</li>
+<li>Repeats until a hop discovers no new documents.</li>
+</ol>
+<p>So the walk is: Alice → {Bob, Carol} → {Dave, Eve, Frank}. Cycles are skipped; a document already in the result set is not expanded again.</p>
+<h3 id="from-and-to-are-reversed-from-join"><code>from</code> and <code>to</code> are reversed from <code>{!join}</code><a class="headerlink" href="#from-and-to-are-reversed-from-join" title="Permanent link">¶</a></h3>
+<p>This is the detail that costs people an afternoon.</p>
+<table>
+<thead>
+<tr>
+<th>Parser</th>
+<th>Collect values from</th>
+<th>Match those values on</th>
+<th>Recurses</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>{!join from=X to=Y}</code></td>
+<td><code>X</code></td>
+<td><code>Y</code></td>
+<td>no</td>
+</tr>
+<tr>
+<td><code>{!graph from=X to=Y}</code></td>
+<td><code>Y</code></td>
+<td><code>X</code></td>
+<td>yes</td>
+</tr>
+</tbody>
+</table>
+<p>For the org chart, the join that finds direct reports is <code>{!join from=id to=manager_id_s}id:alice</code>. The graph walk that finds the whole subtree is <code>{!graph from=manager_id_s to=id}id:alice</code>. Same two fields, opposite parameter names. The graph parser's defaults (<code>from=node_id</code>, <code>to=edge_ids</code>) match a "node identity / outgoing edges" model, which is why <code>to</code> is the field whose values you follow.</p>
+<p>If a graph query returns only the root document, swap <code>from</code> and <code>to</code> before you debug anything else.</p>
+<h2 id="walk-up-daves-management-chain">Walk up: Dave's management chain<a class="headerlink" href="#walk-up-daves-management-chain" title="Permanent link">¶</a></h2>
+<p>Follow <code>manager_id_s</code> instead of inverting it:</p>
+<div class="codehilite"><pre><span></span><code>curl<span class="w"> </span>-sG<span class="w"> </span><span class="s1">'http://localhost:8983/solr/orgchart/query'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'fl=id,name_s,title_s'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'sort=id asc'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'q={!graph from=id to=manager_id_s}id:dave'</span>
+</code></pre></div>
+
+<p>Result: Dave, Bob, Alice. Same parser, opposite edge direction.</p>
+<h2 id="use-it-as-a-filter-not-as-the-scoring-query">Use it as a filter, not as the scoring query<a class="headerlink" href="#use-it-as-a-filter-not-as-the-scoring-query" title="Permanent link">¶</a></h2>
+<p>Graph matches score as a constant <code>1.0</code>. That is the right behavior for "is this document in the subtree?" and the wrong behavior for "rank these people by title text." Production queries almost always belong in <code>fq</code>:</p>
+<div class="codehilite"><pre><span></span><code>curl<span class="w"> </span>-sG<span class="w"> </span><span class="s1">'http://localhost:8983/solr/orgchart/query'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'fl=id,name_s,title_s,score'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'q=title_s:Engineer'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>--data-urlencode<span class="w"> </span><span class="s1">'fq={!graph from=manager_id_s to=id}id:alice'</span>
+</code></pre></div>
+
+<p>Dave and Eve match. Bob does not: his title is "Engineering Manager", and the filter only restricts the domain. Swap in <code>edismax</code> or a vector query for <code>q</code> and the graph filter still applies. This is the same pattern as any other filter query; the graph parser is just a way to <em>compute</em> that filter from edges in the index.</p>
+<h2 id="parameters-worth-knowing">Parameters worth knowing<a class="headerlink" href="#parameters-worth-knowing" title="Permanent link">¶</a></h2>
+<p>The reference guide lists every parameter. These are the ones that change the org-chart queries above.</p>
+<p><strong><code>maxDepth</code></strong> — hop budget, counting the root as depth 0. <code>maxDepth=0</code> is only the root. <code>maxDepth=1</code> is the root plus one hop (Alice, Bob, Carol). Omit it, or leave the default <code>-1</code>, for an unbounded walk.</p>
+<div class="codehilite"><pre><span></span><code><span class="c1"># Direct reports of Alice, including Alice</span>
+<span class="nv">q</span><span class="o">={</span>!graph<span class="w"> </span><span class="nv">from</span><span class="o">=</span>manager_id_s<span class="w"> </span><span class="nv">to</span><span class="o">=</span>id<span class="w"> </span><span class="nv">maxDepth</span><span class="o">=</span><span class="m">1</span><span class="o">}</span>id:alice
+
+<span class="c1"># Direct reports only</span>
+<span class="nv">q</span><span class="o">={</span>!graph<span class="w"> </span><span class="nv">from</span><span class="o">=</span>manager_id_s<span class="w"> </span><span class="nv">to</span><span class="o">=</span>id<span class="w"> </span><span class="nv">maxDepth</span><span class="o">=</span><span class="m">1</span><span class="w"> </span><span class="nv">returnRoot</span><span class="o">=</span>false<span class="o">}</span>id:alice
+</code></pre></div>
+
+<p><strong><code>returnRoot</code></strong> — default <code>true</code>. Set <code>false</code> when the root is a container you do not want in the result (a VP, a parent category, a group). Combined with <code>maxDepth=1</code> this is the graph analogue of a join: one hop, same two fields, opposite <code>from</code>/<code>to</code>, root excluded.</p>
+<p><strong><code>traversalFilter</code></strong> — a query applied to <strong>subsequent</strong> hops, not to the root. To skip people on leave, and anyone reachable only through them:</p>
+<div class="codehilite"><pre><span></span><code><span class="nv">q</span><span class="o">={</span>!graph<span class="w"> </span><span class="nv">from</span><span class="o">=</span>manager_id_s<span class="w"> </span><span class="nv">to</span><span class="o">=</span>id<span class="w"> </span><span class="nv">traversalFilter</span><span class="o">=</span><span class="s1">'status_s:active'</span><span class="o">}</span>id:alice
+</code></pre></div>
+
+<p>Alice is still returned (the root query is unfiltered). Eve is not. If Bob were on leave, Dave and Eve would both disappear, because the walk never enters Bob.</p>
+<p><strong><code>returnOnlyLeaf</code></strong> — keeps documents that have <strong>no value in the <code>to</code> field</strong>. That is useful when <code>to</code> is an outgoing-edge field that leaf nodes leave empty. It is <em>not</em> useful in this org chart: <code>to=id</code> is populated on every document, so the intersection is empty. Model leaves as "no outgoing edges," not as "bottom of the tree."</p>
+<p><strong><code>useAutn</code></strong> — default <code>false</code>. Compiling an automaton per hop may be faster for some wide frontiers. Leave it off unless you measure a gain.</p>
+<h2 id="what-the-parser-will-not-do">What the parser will not do<a class="headerlink" href="#what-the-parser-will-not-do" title="Permanent link">¶</a></h2>
+<p><strong>It is not distributed.</strong> The graph parser runs against a single shard. Standalone Solr is fine. SolrCloud is fine only when the collection has exactly one shard. On a multi-shard collection the coordinator still fans the query out; each shard walks only its local documents, and the client gets the union of those incomplete walks. Cross-shard edges are dropped with no error, which can look plausible and still be wrong. If the data has to be sharded, use <a href="https:// [...]
+<p><strong>It does not rank along the path.</strong> There is no "closer to the root scores higher." If you need hop distance, walk with a few <code>maxDepth</code> queries, or use streaming <code>nodes()</code>, which emits a <code>level</code> field (root is 0). <code>scoreNodes</code> is a different tool: TF-IDF co-occurrence for recommendations, not path ranking.</p>
+<p><strong>It is not a substitute for nested documents.</strong> Parent/child block joins (<code>{!parent}</code> / <code>{!child}</code>) are the right tool when the relationship is physical adjacency in the index. Graph is the right tool when the relationship is <em>values in fields</em>, including cycles and variable depth.</p>
+<p><strong>Wide, deep graphs are search, not a graph database.</strong> Each hop is another query against <code>from</code>. That is fast on a subtree of tens or hundreds of thousands of nodes with a selective root. It is the wrong shape for "materialize the whole connected component of this 80-million-document corpus."</p>
+<h2 id="related-tools-same-edges">Related tools, same edges<a class="headerlink" href="#related-tools-same-edges" title="Permanent link">¶</a></h2>
+<p>Solr has four ways to follow field values from one document to another. They share a mental model and do not share an implementation.</p>
+<table>
+<thead>
+<tr>
+<th>Need</th>
+<th>Tool</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>One hop, possibly across collections (<code>fromIndex</code>, <code>crossCollection</code>)</td>
+<td><a href="https://solr.apache.org/guide/solr/latest/query-guide/join-query-parser.html"><code>{!join}</code></a></td>
+</tr>
+<tr>
+<td>Multi-hop filter or query, single shard</td>
+<td><a href="https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#graph-query-parser"><code>{!graph}</code></a></td>
+</tr>
+<tr>
+<td>Multi-hop domain for a JSON facet</td>
+<td><a href="https://solr.apache.org/guide/solr/latest/query-guide/json-faceting-domain-changes.html#graph-traversal-domain-changes"><code>domain: { graph: { ... } }</code></a></td>
+</tr>
+<tr>
+<td>Distributed walk, aggregations, recommendations</td>
+<td><a href="https://solr.apache.org/guide/solr/latest/query-guide/graph-traversal.html">streaming <code>nodes()</code></a></td>
+</tr>
+</tbody>
+</table>
+<p>JSON faceting's graph domain takes the same <code>from</code>/<code>to</code> parameters as the query parser, including the one-shard limitation. The walk starts from the facet's current domain — here, the main query <code>id:alice</code> — and expands it before the terms facet runs:</p>
+<div class="codehilite"><pre><span></span><code>curl<span class="w"> </span>-sS<span class="w"> </span>http://localhost:8983/solr/orgchart/query<span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>-H<span class="w"> </span><span class="s1">'Content-Type: application/json'</span><span class="w"> </span><span class="se">\</span>
+<span class="w"> </span>-d<span class="w"> </span><span class="s1">'{</span>
+<span class="s1"> "query": "id:alice",</span>
+<span class="s1"> "facet": {</span>
+<span class="s1"> "dept": {</span>
+<span class="s1"> "type": "terms",</span>
+<span class="s1"> "field": "dept_s",</span>
+<span class="s1"> "domain": {</span>
+<span class="s1"> "graph": {</span>
+<span class="s1"> "from": "manager_id_s",</span>
+<span class="s1"> "to": "id"</span>
+<span class="s1"> }</span>
+<span class="s1"> }</span>
+<span class="s1"> }</span>
+<span class="s1"> }</span>
+<span class="s1"> }'</span>
+</code></pre></div>
+
+<h2 id="other-graphs-hiding-in-ordinary-schemas">Other graphs hiding in ordinary schemas<a class="headerlink" href="#other-graphs-hiding-in-ordinary-schemas" title="Permanent link">¶</a></h2>
+<p>The org chart is one picture. The same parser covers:</p>
+<ul>
+<li><strong>Nested groups.</strong> User → group → parent group. Walk <code>member_of</code> to compute the full set of groups a user inherits, then join that set against an ACL field on documents.</li>
+<li><strong>Product taxonomies.</strong> Category → parent category. Filter a product search to "this node and every descendant."</li>
+<li><strong>Ticket / issue links.</strong> <code>blocks_ss</code> / <code>depends_on_ss</code> with <code>maxDepth</code> to keep the walk in a neighborhood.</li>
+<li><strong>Document series.</strong> <code>replaces_s</code> / <code>superseded_by_s</code> to find the current version or the full history.</li>
+</ul>
+<p>If you can write the one-hop join, you can almost certainly write the graph walk. The extra cost is modeling the edge direction correctly and respecting the single-shard limit.</p>
+<h2 id="see-also">See also<a class="headerlink" href="#see-also" title="Permanent link">¶</a></h2>
+<ul>
+<li><a href="https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#graph-query-parser">Graph Query Parser</a> in the Solr Reference Guide</li>
+<li><a href="https://solr.apache.org/guide/solr/latest/query-guide/join-query-parser.html">Join Query Parser</a></li>
+<li><a href="https://solr.apache.org/guide/solr/latest/query-guide/graph-traversal.html">Graph Traversal with streaming expressions</a></li>
+<li><a href="https://solr.apache.org/guide/solr/latest/query-guide/json-faceting-domain-changes.html#graph-traversal-domain-changes">JSON Faceting: graph domain changes</a></li>
+</ul> </div>
+</div>
+ <footer>
+<div class="row">
+ <div class="small-6 medium-3 columns">
+ <h4>Features</h4>
+ <ul>
+ <li><a href="/features.html">Overview</a></li>
+ <li><a href="/features.html#data-handling">Data Handling</a></li>
+ <li><a href="/features.html#query">Querying</a></li>
+ <li><a href="/features.html#facets">Faceting</a></li>
+ <li><a href="/features.html#discovery">Discovery</a></li>
+ <li><a href="/features.html#plugins">Plugins and Extensions</a></li>
+ <li><a href="/features.html#stats">Statistics and Aggregations</a></li>
+ <li><a href="/features.html#spatial">Spatial</a></li>
+ <li><a href="/features.html#rich-content">Rich Content</a></li>
+ <li><a href="/features.html#performance">Performance</a></li>
+ <li><a href="/features.html#solrcloud">Scaling with SolrCloud</a></li>
+ <li><a href="/features.html#admin-ui">User Interface</a></li>
+ </ul>
+ </div>
+ <div class="small-6 medium-3 columns">
+ <h4>Resources</h4>
+ <ul>
+ <li><a href="/resources.html#tutorials">Tutorial</a></li>
+ <li><a href="https://solr.apache.org/guide/solr/latest/">Docs</a></li>
+ <li><a href="/resources.html#solr-books">Books</a></li>
+ <li><a href="/resources.html#presentations">Presentations</a></li>
+ <li><a href="/resources.html#videos">Videos</a></li>
+ <li><a href="/logos-and-assets.html">Solr Logos and Assets</a></li>
+ <li><a href="/editing-website.html">Editing this Website</a></li>
+ <br/>
+ <li><a href="https://www.apache.org/">Apache Software Foundation</a></li>
+ <li><a href="https://www.apache.org/foundation/thanks.html">Thanks</a></li>
+ <li><a href="https://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+ <li><a href="https://www.apache.org/security/">Security</a></li>
+ <li><a href="https://www.apache.org/licenses/">License</a></li>
+ </ul>
+ </div>
+ <div class="small-6 medium-3 columns">
+ <h4>Get Started</h4>
+ <ul>
+ <li><a href="/downloads.html">Download</a></li>
+ <li><a href="/guide/solr-tutorial.html">Run Through the Tutorial</a></li>
+ <li><a href="/resources.html">Level Up</a></li>
+ </ul>
+ <br/>
+ <h4>Community</h4>
+ <ul>
+ <li><a href="/community.html#support">Support</a></li>
+ <li><a href="/community.html#mailing-lists-irc">Mailing Lists</a></li>
+ <li><a href="/community.html#issue-tracker">Issues (JIRA)</a></li>
+ <li><a href="/community.html#how-to-contribute">Contribute</a></li>
+ <li><a href="/community.html#version-control">Version control (GIT)</a></li>
+ </ul>
+ </div>
+ <div class="small-6 medium-3 columns">
+ <h4>Related Projects</h4>
+ <ul>
+ <li><a href="http://lucene.apache.org/">Apache Lucene</a></li>
+ <li><a href="http://zookeeper.apache.org/">Apache Zookeeper</a></li>
+ <li><a href="http://tika.apache.org/">Apache Tika</a></li>
+ <li><a href="http://manifoldcf.apache.org/">Apache ManifoldCF</a></li>
+ <li><a href="http://spark.apache.org/">Apache Spark</a></li>
+ <li><a href="http://nutch.apache.org/">Apache Nutch</a></li>
+ <li><a href="http://zeppelin.apache.org/">Apache Zeppelin</a></li>
+ <li><a href="http://opennlp.apache.org/">Apache OpenNLP</a></li>
+ </ul>
+ </div>
+</div>
+<div class="row copyright">
+<div class="large-centered columns">
+ <p>Copyright © 2026 The Apache Software Foundation, Licensed under the
+ <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>. <a href="https://privacy.apache.org/policies/privacy-policy-public.html">Privacy Policy</a><br/>
+ Apache and the Apache logo are trademarks of The Apache Software Foundation. Apache Lucene,
+ Apache Solr and their respective logos are trademarks of the Apache Software Foundation.
+ Please see the <a href="https://www.apache.org/foundation/marks/">Apache Trademark Policy</a> for more information.
+ All non-Apache logos are the trademarks of their respective owners.</p>
+</div></div> </footer>
+
+<script>
+ $(document).foundation();
+</script>
+<!-- TODO: This script is commented out because we do not use slick slider.
+<script>
+ $(document).ready(function(){
+ $('.slider').slick({
+ infinite: false,
+ speed: 300,
+ slidesToShow: 6,
+ slidesToScroll: 6,
+ responsive: [
+ {
+ breakpoint: 1024,
+ settings: {
+ slidesToShow: 4,
+ slidesToScroll: 4,
+ infinite: true
+ }
+ },
+ {
+ breakpoint: 600,
+ settings: {
+ slidesToShow: 3,
+ slidesToScroll: 3
+ }
+ },
+ {
+ breakpoint: 480,
+ settings: {
+ slidesToShow: 2,
+ slidesToScroll: 2
+ }
+ },
+ {
+ breakpoint: 320,
+ settings: {
+ slidesToShow: 1,
+ slidesToScroll: 1
+ }
+ }
+ ],
+ prevArrow: '<i class="fa fa-angle-left fa-2x slider-prev"></i>',
+ nextArrow: '<i class="fa fa-angle-right fa-2x slider-next"></i>'
+ });
+ });
+</script>
+-->
+ </body>
+</html>
\ No newline at end of file
diff --git a/output/feeds/all.atom.xml b/output/feeds/all.atom.xml
index 585a8ad15..6a05abb78 100644
--- a/output/feeds/all.atom.xml
+++ b/output/feeds/all.atom.xml
@@ -1,5 +1,119 @@
<?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-08-13T00:00:00+00:00</updated><entry><title>lz4-java: out-of-bounds memory access and insufficient buffer clearing in compression/decompression</title><link href="/cve-2025-12183.html" rel="alternate"/><published>2026-08-13T00:00:00+00:00</published><updated>2026-08-13T00:00:00+00:00</updated><author><name>Solr Developers [...]
+<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-08-25T00:00:00+00:00</updated><entry><title>ws: memory exhaustion denial of service from tiny WebSocket fragments</title><link href="/cve-2026-48779.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2 [...]
+a peer that sends a high volume of exceptionally small message fragments can force the receiving side
+to allocate and retain structural wrappers far larger than the documented message-size limit,
+eventually exhausting memory. It affects <code>ws</code> 8 …</p></summary><content type="html"><p>CVE-2026-48779 is a memory-exhaustion denial-of-service issue in the Node.js <code>ws</code> WebSocket library:
+a peer that sends a high volume of exceptionally small message fragments can force the receiving side
+to allocate and retain structural wrappers far larger than the documented message-size limit,
+eventually exhausting memory. It affects <code>ws</code> 8.0.0 through 8.20.x; fixed in 8.21.0 (with backports
+to the 5.x/6.x/7.x lines for older major versions).</p>
+<p>Solr is <strong>not affected</strong>. <code>ws</code> is pinned in <code>kotlin-js-store/wasm/yarn.lock</code>, an auto-generated
+lockfile for the Kotlin/Wasm build toolchain that compiles the new Compose-based Admin UI
+(<code>solr/ui</code>). It is a transitive dependency of that toolchain's Node.js-based dev-server/test-runner
+tooling, not of Solr's own code. <code>ws</code> depends on Node.js's native TCP socket APIs, which don't exist
+in a browser sandbox -- it is therefore not possible for it to be bundled into the actual
+browser-executable Wasm/JS output that ships to end users and runs in their browser. This isn't a
+case of unreachable-but-present code; the vulnerable component is never part of the shipped product
+artifact at all, only of the build/test pipeline that produces it.</p>
+<p><code>ws</code> has been present in <code>solr/ui</code>'s build tooling since it was first introduced (shipped in the
+10.0.0 release at <code>ws@8.18.0</code>/<code>ws@8.18.3</code>, both within the affected range). <code>branch_9x</code> doesn't have
+this module at all. Since this dependency never reaches a shipped artifact, no application-level fix
+is required; bumping it is worth doing as routine build-tooling hygiene regardless, since a compromised
+or misbehaving local/CI dev-server dependency is still worth avoiding even without direct product
+exposure.</p></content><category term="solr/vex"/></entry><entry><title>Apache HttpComponents Core: HTTP/1 header parsing memory-exhaustion denial of service</title><link href="/cve-2026-54399.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026-08-25:/cve-2026-54399.html</id><summary type="html"><p>CVE-2026-54399 is an uncontrolled-resource-consumption [...]
+message parser: a remote peer can send messages with an excessive number of headers or excessive
+header length, exhausting memory and causing a denial of service. It affects <code>httpcore5</code> 5.4.2 and
+earlier (and 5.5-beta1 and …</p></summary><content type="html"><p>CVE-2026-54399 is an uncontrolled-resource-consumption issue in Apache HttpComponents Core's HTTP/1.1
+message parser: a remote peer can send messages with an excessive number of headers or excessive
+header length, exhausting memory and causing a denial of service. It affects <code>httpcore5</code> 5.4.2 and
+earlier (and 5.5-beta1 and earlier); fixed in 5.4.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpcore5</code> is bundled transitively by
+<code>org.apache.calcite.avatica:avatica-core</code>, which uses it to support Avatica's <em>optional remote-JDBC</em>
+HTTP transport -- see the companion VEX entry for CVE-2026-64607 (<code>httpclient5</code>) for the full
+reachability analysis, which applies identically here: Solr's <code>/sql</code> handler never uses Avatica's
+remote HTTP transport, only the local embedded <code>CalciteConnection</code>, so <code>httpcore5</code>'s HTTP/1.1 message
+parser is never invoked to process any inbound message, trusted or otherwise. The dependency is
+<code>permitUnusedDeclared</code> in Solr's own build and shipped only via the optional <code>solr:modules:sql</code>
+module.</p>
+<p>Solr has shipped an affected <code>httpcore5</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.3.5). <code>branch_9x</code> has since moved to 5.4.3, exactly the fix version --
+picked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the
+code path is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p></content><category term="solr/vex"/></entry><entry><title>Apache HttpComponents Core: HPACK decoder unlimited header list size before SETTINGS ACK</title><link href="/cve-2026-54428.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag [...]
+decoder: before an HTTP/2 peer's <code>SETTINGS</code> frame is acknowledged, the configured header list size
+limit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust
+memory, causing a denial of service. It …</p></summary><content type="html"><p>CVE-2026-54428 is an allocation-without-limits issue in Apache HttpComponents Core's HTTP/2 HPACK
+decoder: before an HTTP/2 peer's <code>SETTINGS</code> frame is acknowledged, the configured header list size
+limit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust
+memory, causing a denial of service. It affects <code>httpcore5-h2</code> 5.4.2 and earlier (and 5.5-beta1 and
+earlier); fixed in 5.4.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpcore5-h2</code> is bundled transitively by
+<code>org.apache.calcite.avatica:avatica-core</code>, which uses it to support Avatica's <em>optional remote-JDBC</em>
+HTTP/2 transport -- see the companion VEX entry for CVE-2026-64607 (<code>httpclient5</code>) for the full
+reachability analysis, which applies identically here: Solr's <code>/sql</code> handler never uses Avatica's
+remote HTTP transport, only the local embedded <code>CalciteConnection</code>, so the HPACK decoder this CVE
+concerns -- which only runs when HttpComponents is actually acting as an HTTP/2 endpoint -- is never
+invoked. The dependency is <code>permitUnusedDeclared</code> in Solr's own build and shipped only via the
+optional <code>solr:modules:sql</code> module.</p>
+<p>Solr has shipped an affected <code>httpcore5-h2</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.3.4). <code>branch_9x</code> has since moved to 5.4.3, exactly the fix version --
+picked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the
+code path is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p></content><category term="solr/vex"/></entry><entry><title>Apache HttpComponents Client: connection leak on Content-Encoding decode error</title><link href="/cve-2026-64607.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026 [...]
+(blocking) I/O model: if a response has an invalid or unsupported <code>Content-Encoding</code> header, the
+client fails to release the underlying connection back to the connection manager, eventually
+exhausting the pool and causing a denial of service. It …</p></summary><content type="html"><p>CVE-2026-64607 (medium severity) is a connection-leak bug in Apache HttpComponents Client's classic
+(blocking) I/O model: if a response has an invalid or unsupported <code>Content-Encoding</code> header, the
+client fails to release the underlying connection back to the connection manager, eventually
+exhausting the pool and causing a denial of service. It does not affect HttpClient's async I/O model.
+It affects <code>httpclient5</code> from 5.0-alpha1 through 5.6.2; fixed in 5.6.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpclient5</code> (along with <code>httpcore5</code> and <code>httpcore5-h2</code>, covered in
+separate VEX entries for their own CVEs) is bundled transitively by <code>org.apache.calcite.avatica:avatica-core</code>,
+which uses it to support Avatica's <em>optional remote-JDBC</em> transport -- connecting to a remote Avatica
+server over HTTP. Solr's own <code>/sql</code> handler (<code>CalciteSolrDriver</code>) only ever opens a local, in-process
+<code>org.apache.calcite.jdbc.CalciteConnection</code>; there is no <code>org.apache.hc.client5</code>/<code>org.apache.hc.core5</code>
+usage anywhere in <code>solr/modules/sql</code>'s source, and Solr never acts as an Avatica HTTP client or server.
+The dependency has in fact been marked <code>permitUnusedDeclared</code> in Solr's own build since at least the
+10.0.0 release, confirming the build's own dependency-analysis tooling already recognized it as
+present-but-unused. It's also shipped only via the optional <code>solr:modules:sql</code> module -- every other
+place it appears (<code>solrj-streaming</code>, <code>solr-ref-guide</code>, <code>webapp</code>) is test-scope only, not shipped.</p>
+<p>Solr has shipped an affected <code>httpclient5</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.5). <code>branch_9x</code> has since moved to 5.6.4, past the fix -- picked up
+incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the code path
+is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p></content><category term="solr/vex"/></entry><entry><title>Netty: SslHandler native crash on crafted packets</title><link href="/cve-2025-24970.html" rel="alternate"/><published>2026-08-23T00:00:00+00:00</published><updated>2026-08-23T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026-08-23:/cve-2025-24970.html</id><summar [...]
+<code>netty-tcnative</code>) TLS engine is in use, a specially crafted packet received during TLS
+processing is not properly validated, which can trigger a native crash (JVM segfault) rather
+than a clean exception. It affects Netty <code>netty-handler</code> versions 4 …</p></summary><content type="html"><p>CVE-2025-24970 is a flaw in Netty's <code>SslHandler</code>: when the native (OpenSSL/BoringSSL, via
+<code>netty-tcnative</code>) TLS engine is in use, a specially crafted packet received during TLS
+processing is not properly validated, which can trigger a native crash (JVM segfault) rather
+than a clean exception. It affects Netty <code>netty-handler</code> versions 4.1.91.Final through
+4.1.117.Final; fixed in 4.1.118.Final. The 4.2.x release line is not in the affected range at
+all — 4.2.0.Final was cut after the fix had already landed upstream.</p>
+<p>Solr shipped an affected <code>netty-handler</code> from 9.3.0 (4.1.93.Final) through 9.9.0
+(4.1.114.Final), arriving as a transitive runtime dependency of <code>io.grpc:grpc-netty</code>, used only
+by the optional <strong>opentelemetry</strong> module's OTLP gRPC trace exporter. Solr 9.10.0 onward already
+ships Netty 4.2.6.Final or later — outside the affected range — so no currently released Solr
+version bundles a vulnerable <code>netty-handler</code>. Solr is <strong>not affected</strong> even on the older,
+already-released 9.3.0–9.9.0 line:</p>
+<ul>
+<li><strong>The opentelemetry module is optional and disabled by default.</strong> It must be explicitly
+ enabled (e.g. via <code>-Dsolr.modules=opentelemetry</code>) before <code>grpc-netty</code>, and therefore
+ <code>netty-handler</code>, is even loaded.</li>
+<li><strong>Netty is used only as an outbound gRPC client dialing the operator's own configured OTLP
+ collector</strong>, not as a listener accepting arbitrary inbound connections. <code>SslHandler</code>'s
+ crafted-packet validation only matters for TLS data arriving from the remote peer on that
+ connection — here, the operator-designated collector endpoint, not an attacker-facing socket.</li>
+<li><strong>Solr's own request-handling surface is Jetty, not Netty.</strong> Every attacker-facing API call
+ Solr accepts is parsed and served by Jetty; <code>io.netty</code> code is never invoked to process
+ inbound requests to Solr itself.</li>
+<li>Exploitation would additionally require the operator to have pointed OTLP export at a
+ compromised or malicious collector (or accepted an on-path attacker on that egress route) —
+ a threat model outside standard use of this optional telemetry feature.</li>
+</ul>
+<p>No released Solr version ships a fix for this specific line, because none currently needs one:
+9.10.0+ already carries a post-fix Netty. The <code>branch_9x</code> (→ 9.11.0) and <code>main</code>/<code>branch_10x</code>
+(→ 10.x) development branches have since moved further still, to Netty 4.2.15.Final and
+4.2.17.Final respectively — picked up incidentally through routine dependency updates rather
+than a targeted SOLR-17826 fix commit. SOLR-17826 remains open upstream and should be closed
+out to reflect that no supported or in-development Solr line is exposed.</p></content><category term="solr/vex"/></entry><entry><title>lz4-java: out-of-bounds memory access and insufficient buffer clearing in compression/decompression</title><link href="/cve-2025-12183.html" rel="alternate"/><published>2026-08-13T00:00:00+00:00</published><updated>2026-08-13T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026-08-13:/cve-2025-12183.html</id><summar [...]
<ul>
<li><strong>CVE-2025-12183</strong> — several lz4-java compression/decompression implementations do not guard against
out-of-bounds memory access (fixed in <code>lz4-java</code> 1.8.1).</li>
@@ -2265,139 +2379,4 @@ CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-31391">CVE-2024-3
<p>Please read CHANGES.txt for a full list of bugfixes:</p>
<p><a href="https://solr.apache.org/docs/8_11_3/changes/Changes.html">https://solr.apache.org/docs/8_11_3/changes/Changes.html</a></p>
<p>Solr 8.11.3 also includes bugfixes in the corresponding Apache Lucene release:</p>
-<p><a href="https://lucene.apache.org/core/8_11_3/changes/Changes.html">https://lucene.apache.org/core/8_11_3/changes/Changes.html</a></p></content><category term="solr/news"/></entry><entry><title>CVE-2023-50291: Apache Solr can leak certain passwords due to System Property redaction logic inconsistencies</title><link href="/cve-2023-50291-apache-solr-can-leak-certain-passwords-due-to-system-property-redaction-logic-inconsistencies.html" rel="alternate"/><publish [...]
-Moderate</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.3.0</li>
-</ul>
-<p><strong>Description:</strong><br>
-Insufficiently Protected Credentials vulnerability in Apache Solr.</p>
-<p>This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3 …</p></summary><content type="html"><p><strong>Severity:</strong><br>
-Moderate</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.3.0</li>
-</ul>
-<p><strong>Description:</strong><br>
-Insufficiently Protected Credentials vulnerability in Apache Solr.</p>
-<p>This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0.
-One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name.
-There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint.
-This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI.</p>
-<p>This /admin/info/properties endpoint is protected under the "config-read" permission.
-Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission.
-Users are recommended to upgrade to version 9.3.0 or 8.11.3, which fixes the issue.
-A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps".
-By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password".</p>
-<p>Users who cannot upgrade can also use the following Java system property to fix the issue:<br>
-<code>-Dsolr.redaction.system.pattern=".*(password|secret|basicauth).*"</code></p>
-<p><strong>Mitigation:</strong><br>
-Users are recommended to upgrade to version 8.11.3, 9.3.0 or later, which has consistent systemProperty redaction logic.</p>
-<p><strong>Credit:</strong>
-Michael Taggart (reporter)</p>
-<p><strong>References:</strong><br>
-JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16809">SOLR-16809</a><br>
-CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50291">CVE-2023-50291</a></p></content><category term="solr/security"/></entry><entry><title>CVE-2023-50292: Apache Solr Schema Designer blindly "trusts" all configsets, possibly leading to RCE by unauthenticated users</title><link href="/cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users.html" rel="alternate"/><published>2024-02-08T00:00:00+00 [...]
-Moderate</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.3.0</li>
-</ul>
-<p><strong>Description:</strong><br>
-Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr.</p>
-<p>This issue affects Apache Solr: from 8.10.0 through 8 …</p></summary><content type="html"><p><strong>Severity:</strong><br>
-Moderate</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.3.0</li>
-</ul>
-<p><strong>Description:</strong><br>
-Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr.</p>
-<p>This issue affects Apache Solr: from 8.10.0 through 8.11.2, from 9.0.0 before 9.3.0.</p>
-<p>The Schema Designer was introduced to allow users to more easily configure and test new Schemas and configSets.
-However, when the feature was created, the "trust" (authentication) of these configSets was not considered.
-External library loading is only available to configSets that are "trusted" (created by authenticated users), thus non-authenticated users are unable to perform Remote Code Execution.
-Since the Schema Designer loaded configSets without taking their "trust" into account, configSets that were created by unauthenticated users were allowed to load external libraries when used in the Schema Designer.</p>
-<p><strong>Mitigation:</strong><br>
-Users are recommended to upgrade to version 8.11.3, 9.3.0 or later.</p>
-<p><strong>Credit:</strong>
-Skay (reporter)</p>
-<p><strong>References:</strong><br>
-JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16777">SOLR-16777</a><br>
-CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50292">CVE-2023-50292</a></p></content><category term="solr/security"/></entry><entry><title>CVE-2023-50298: Apache Solr can expose ZooKeeper credentials via Streaming Expressions</title><link href="/cve-2023-50298-apache-solr-can-expose-zookeeper-credentials-via-streaming-expressions.html" rel="alternate"/><published>2024-02-08T00:00:00+00:00</published><updated>2024-02-08T00:00:00+00:00</updated><author><name>So [...]
-Low</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.4.1</li>
-</ul>
-<p><strong>Description:</strong><br>
-Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9 …</p></summary><content type="html"><p><strong>Severity:</strong><br>
-Low</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.4.1</li>
-</ul>
-<p><strong>Description:</strong><br>
-Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.</p>
-<p>Solr Streaming Expressions allows users to extract data from other Solr Clouds, using a "zkHost" parameter.
-When original SolrCloud is setup to use ZooKeeper credentials and ACLs, they will be sent to whatever "zkHost" the user provides.
-An attacker could setup a server to mock ZooKeeper, that accepts ZooKeeper requests with credentials and ACLs and extracts the sensitive information,
-then send a streaming expression using the mock server's address in "zkHost".
-Streaming Expressions are exposed via the "/streaming" handler, with "read" permissions.</p>
-<p><strong>Mitigation:</strong><br>
-Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.
-From these versions on, only zkHost values that have the same server address (regardless of chroot), will use the given ZooKeeper credentials and ACLs when connecting.</p>
-<p><strong>Credit:</strong>
-Qing Xu (reporter)</p>
-<p><strong>References:</strong><br>
-JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-17098">SOLR-17098</a><br>
-CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50298">CVE-2023-50298</a></p></content><category term="solr/security"/></entry><entry><title>CVE-2023-50386: Apache Solr: Backup/Restore APIs allow for deployment of executables in malicious ConfigSets</title><link href="/cve-2023-50386-apache-solr-backuprestore-apis-allow-for-deployment-of-executables-in-malicious-configsets.html" rel="alternate"/><published>2024-02-08T00:00:00+00:00</published><updated>2024-02-0 [...]
-Moderate</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.4.1</li>
-</ul>
-<p><strong>Description:</strong><br>
-Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects …</p></summary><content type="html"><p><strong>Severity:</strong><br>
-Moderate</p>
-<p><strong>Versions Affected:</strong></p>
-<ul>
-<li>Apache Solr 6.0.0 through 8.11.2</li>
-<li>Apache Solr 9.0.0 before 9.4.1</li>
-</ul>
-<p><strong>Description:</strong><br>
-Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.</p>
-<p>In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API.
-When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups).
-If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted.</p>
-<p>When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries.</p>
-<p><strong>Mitigation:</strong><br>
-Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.
-In these versions, the following protections have been added:</p>
-<ul>
-<li>Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader.</li>
-<li>The Backup API restricts saving backups to directories that are used in the ClassLoader.</li>
-</ul>
-<p><strong>Credit:</strong>
-L3yx (reporter)</p>
-<p><strong>References:</strong><br>
-JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16949">SOLR-16949</a><br>
-CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50386">CVE-2023-50386</a></p></content><category term="solr/security"/></entry><entry><title>Apache Solr™ 9.4.1 available</title><link href="/apache-solrtm-941-available.html" rel="alternate"/><published>2024-01-18T00:00:00+00:00</published><updated>2024-01-18T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2024-01-18:/apache-solrtm-941-available.html</id><summary type="html">< [...]
-<p>Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Solr 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 9.4.1.</p>
-<p>Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Solr 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 9.4.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-941-release-highlights">Solr 9.4.1 Release Highlights:<a class="headerlink" href="#solr-941-release-highlights" title="Permanent link">&para;</a></h3>
-<p>A big regression to the JSON Query API in 9.4 is primarily what prompted this release. Additionally, some security oriented improvements/fixes have been added, and many transitive dependencies have been upgraded.</p>
-<p>Please refer to the Upgrade Notes in the Solr Ref Guide for information on upgrading from previous Solr versions:</p>
-<p><a href="https://solr.apache.org/guide/solr/9_4/upgrade-notes/solr-upgrade-notes.html">https://solr.apache.org/guide/solr/9_4/upgrade-notes/solr-upgrade-notes.html</a></p>
-<p>Please read CHANGES.txt for a full list of bugfixes:</p>
-<p><a href="https://solr.apache.org/9_4_1/changes/Changes.html">https://solr.apache.org/9_4_1/changes/Changes.html</a></p></content><category term="solr/news"/></entry></feed>
\ No newline at end of file
+<p><a href="https://lucene.apache.org/core/8_11_3/changes/Changes.html">https://lucene.apache.org/core/8_11_3/changes/Changes.html</a></p></content><category term="solr/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 dfec1c86b..59d97caf8 100644
--- a/output/feeds/solr/vex.atom.xml
+++ b/output/feeds/solr/vex.atom.xml
@@ -1,5 +1,119 @@
<?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-08-13T00:00:00+00:00</updated><entry><title>lz4-java: out-of-bounds memory access and insufficient buffer clearing in compression/decompression</title><link href="/cve-2025-12183.html" rel="alternate"/><published>2026-08-13T00:00:00+00:00</published><updated>2026-08-13T00:00:00+00:00</updated><author><name [...]
+<feed xmlns="http://www.w3.org/2005/Atom"><title>Apache Solr - solr/vex</title><link href="/" rel="alternate"/><link href="/feeds/solr/vex.atom.xml" rel="self"/><id>/</id><updated>2026-08-25T00:00:00+00:00</updated><entry><title>ws: memory exhaustion denial of service from tiny WebSocket fragments</title><link href="/cve-2026-48779.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></autho [...]
+a peer that sends a high volume of exceptionally small message fragments can force the receiving side
+to allocate and retain structural wrappers far larger than the documented message-size limit,
+eventually exhausting memory. It affects <code>ws</code> 8 …</p></summary><content type="html"><p>CVE-2026-48779 is a memory-exhaustion denial-of-service issue in the Node.js <code>ws</code> WebSocket library:
+a peer that sends a high volume of exceptionally small message fragments can force the receiving side
+to allocate and retain structural wrappers far larger than the documented message-size limit,
+eventually exhausting memory. It affects <code>ws</code> 8.0.0 through 8.20.x; fixed in 8.21.0 (with backports
+to the 5.x/6.x/7.x lines for older major versions).</p>
+<p>Solr is <strong>not affected</strong>. <code>ws</code> is pinned in <code>kotlin-js-store/wasm/yarn.lock</code>, an auto-generated
+lockfile for the Kotlin/Wasm build toolchain that compiles the new Compose-based Admin UI
+(<code>solr/ui</code>). It is a transitive dependency of that toolchain's Node.js-based dev-server/test-runner
+tooling, not of Solr's own code. <code>ws</code> depends on Node.js's native TCP socket APIs, which don't exist
+in a browser sandbox -- it is therefore not possible for it to be bundled into the actual
+browser-executable Wasm/JS output that ships to end users and runs in their browser. This isn't a
+case of unreachable-but-present code; the vulnerable component is never part of the shipped product
+artifact at all, only of the build/test pipeline that produces it.</p>
+<p><code>ws</code> has been present in <code>solr/ui</code>'s build tooling since it was first introduced (shipped in the
+10.0.0 release at <code>ws@8.18.0</code>/<code>ws@8.18.3</code>, both within the affected range). <code>branch_9x</code> doesn't have
+this module at all. Since this dependency never reaches a shipped artifact, no application-level fix
+is required; bumping it is worth doing as routine build-tooling hygiene regardless, since a compromised
+or misbehaving local/CI dev-server dependency is still worth avoiding even without direct product
+exposure.</p></content><category term="solr/vex"/></entry><entry><title>Apache HttpComponents Core: HTTP/1 header parsing memory-exhaustion denial of service</title><link href="/cve-2026-54399.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026-08-25:/cve-2026-54399.html</id><summary type="html"><p>CVE-2026-54399 is an uncontrolled-resource-consumption [...]
+message parser: a remote peer can send messages with an excessive number of headers or excessive
+header length, exhausting memory and causing a denial of service. It affects <code>httpcore5</code> 5.4.2 and
+earlier (and 5.5-beta1 and …</p></summary><content type="html"><p>CVE-2026-54399 is an uncontrolled-resource-consumption issue in Apache HttpComponents Core's HTTP/1.1
+message parser: a remote peer can send messages with an excessive number of headers or excessive
+header length, exhausting memory and causing a denial of service. It affects <code>httpcore5</code> 5.4.2 and
+earlier (and 5.5-beta1 and earlier); fixed in 5.4.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpcore5</code> is bundled transitively by
+<code>org.apache.calcite.avatica:avatica-core</code>, which uses it to support Avatica's <em>optional remote-JDBC</em>
+HTTP transport -- see the companion VEX entry for CVE-2026-64607 (<code>httpclient5</code>) for the full
+reachability analysis, which applies identically here: Solr's <code>/sql</code> handler never uses Avatica's
+remote HTTP transport, only the local embedded <code>CalciteConnection</code>, so <code>httpcore5</code>'s HTTP/1.1 message
+parser is never invoked to process any inbound message, trusted or otherwise. The dependency is
+<code>permitUnusedDeclared</code> in Solr's own build and shipped only via the optional <code>solr:modules:sql</code>
+module.</p>
+<p>Solr has shipped an affected <code>httpcore5</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.3.5). <code>branch_9x</code> has since moved to 5.4.3, exactly the fix version --
+picked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the
+code path is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p></content><category term="solr/vex"/></entry><entry><title>Apache HttpComponents Core: HPACK decoder unlimited header list size before SETTINGS ACK</title><link href="/cve-2026-54428.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag [...]
+decoder: before an HTTP/2 peer's <code>SETTINGS</code> frame is acknowledged, the configured header list size
+limit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust
+memory, causing a denial of service. It …</p></summary><content type="html"><p>CVE-2026-54428 is an allocation-without-limits issue in Apache HttpComponents Core's HTTP/2 HPACK
+decoder: before an HTTP/2 peer's <code>SETTINGS</code> frame is acknowledged, the configured header list size
+limit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust
+memory, causing a denial of service. It affects <code>httpcore5-h2</code> 5.4.2 and earlier (and 5.5-beta1 and
+earlier); fixed in 5.4.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpcore5-h2</code> is bundled transitively by
+<code>org.apache.calcite.avatica:avatica-core</code>, which uses it to support Avatica's <em>optional remote-JDBC</em>
+HTTP/2 transport -- see the companion VEX entry for CVE-2026-64607 (<code>httpclient5</code>) for the full
+reachability analysis, which applies identically here: Solr's <code>/sql</code> handler never uses Avatica's
+remote HTTP transport, only the local embedded <code>CalciteConnection</code>, so the HPACK decoder this CVE
+concerns -- which only runs when HttpComponents is actually acting as an HTTP/2 endpoint -- is never
+invoked. The dependency is <code>permitUnusedDeclared</code> in Solr's own build and shipped only via the
+optional <code>solr:modules:sql</code> module.</p>
+<p>Solr has shipped an affected <code>httpcore5-h2</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.3.4). <code>branch_9x</code> has since moved to 5.4.3, exactly the fix version --
+picked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the
+code path is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p></content><category term="solr/vex"/></entry><entry><title>Apache HttpComponents Client: connection leak on Content-Encoding decode error</title><link href="/cve-2026-64607.html" rel="alternate"/><published>2026-08-25T00:00:00+00:00</published><updated>2026-08-25T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026 [...]
+(blocking) I/O model: if a response has an invalid or unsupported <code>Content-Encoding</code> header, the
+client fails to release the underlying connection back to the connection manager, eventually
+exhausting the pool and causing a denial of service. It …</p></summary><content type="html"><p>CVE-2026-64607 (medium severity) is a connection-leak bug in Apache HttpComponents Client's classic
+(blocking) I/O model: if a response has an invalid or unsupported <code>Content-Encoding</code> header, the
+client fails to release the underlying connection back to the connection manager, eventually
+exhausting the pool and causing a denial of service. It does not affect HttpClient's async I/O model.
+It affects <code>httpclient5</code> from 5.0-alpha1 through 5.6.2; fixed in 5.6.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpclient5</code> (along with <code>httpcore5</code> and <code>httpcore5-h2</code>, covered in
+separate VEX entries for their own CVEs) is bundled transitively by <code>org.apache.calcite.avatica:avatica-core</code>,
+which uses it to support Avatica's <em>optional remote-JDBC</em> transport -- connecting to a remote Avatica
+server over HTTP. Solr's own <code>/sql</code> handler (<code>CalciteSolrDriver</code>) only ever opens a local, in-process
+<code>org.apache.calcite.jdbc.CalciteConnection</code>; there is no <code>org.apache.hc.client5</code>/<code>org.apache.hc.core5</code>
+usage anywhere in <code>solr/modules/sql</code>'s source, and Solr never acts as an Avatica HTTP client or server.
+The dependency has in fact been marked <code>permitUnusedDeclared</code> in Solr's own build since at least the
+10.0.0 release, confirming the build's own dependency-analysis tooling already recognized it as
+present-but-unused. It's also shipped only via the optional <code>solr:modules:sql</code> module -- every other
+place it appears (<code>solrj-streaming</code>, <code>solr-ref-guide</code>, <code>webapp</code>) is test-scope only, not shipped.</p>
+<p>Solr has shipped an affected <code>httpclient5</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.5). <code>branch_9x</code> has since moved to 5.6.4, past the fix -- picked up
+incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the code path
+is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p></content><category term="solr/vex"/></entry><entry><title>Netty: SslHandler native crash on crafted packets</title><link href="/cve-2025-24970.html" rel="alternate"/><published>2026-08-23T00:00:00+00:00</published><updated>2026-08-23T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026-08-23:/cve-2025-24970.html</id><summar [...]
+<code>netty-tcnative</code>) TLS engine is in use, a specially crafted packet received during TLS
+processing is not properly validated, which can trigger a native crash (JVM segfault) rather
+than a clean exception. It affects Netty <code>netty-handler</code> versions 4 …</p></summary><content type="html"><p>CVE-2025-24970 is a flaw in Netty's <code>SslHandler</code>: when the native (OpenSSL/BoringSSL, via
+<code>netty-tcnative</code>) TLS engine is in use, a specially crafted packet received during TLS
+processing is not properly validated, which can trigger a native crash (JVM segfault) rather
+than a clean exception. It affects Netty <code>netty-handler</code> versions 4.1.91.Final through
+4.1.117.Final; fixed in 4.1.118.Final. The 4.2.x release line is not in the affected range at
+all — 4.2.0.Final was cut after the fix had already landed upstream.</p>
+<p>Solr shipped an affected <code>netty-handler</code> from 9.3.0 (4.1.93.Final) through 9.9.0
+(4.1.114.Final), arriving as a transitive runtime dependency of <code>io.grpc:grpc-netty</code>, used only
+by the optional <strong>opentelemetry</strong> module's OTLP gRPC trace exporter. Solr 9.10.0 onward already
+ships Netty 4.2.6.Final or later — outside the affected range — so no currently released Solr
+version bundles a vulnerable <code>netty-handler</code>. Solr is <strong>not affected</strong> even on the older,
+already-released 9.3.0–9.9.0 line:</p>
+<ul>
+<li><strong>The opentelemetry module is optional and disabled by default.</strong> It must be explicitly
+ enabled (e.g. via <code>-Dsolr.modules=opentelemetry</code>) before <code>grpc-netty</code>, and therefore
+ <code>netty-handler</code>, is even loaded.</li>
+<li><strong>Netty is used only as an outbound gRPC client dialing the operator's own configured OTLP
+ collector</strong>, not as a listener accepting arbitrary inbound connections. <code>SslHandler</code>'s
+ crafted-packet validation only matters for TLS data arriving from the remote peer on that
+ connection — here, the operator-designated collector endpoint, not an attacker-facing socket.</li>
+<li><strong>Solr's own request-handling surface is Jetty, not Netty.</strong> Every attacker-facing API call
+ Solr accepts is parsed and served by Jetty; <code>io.netty</code> code is never invoked to process
+ inbound requests to Solr itself.</li>
+<li>Exploitation would additionally require the operator to have pointed OTLP export at a
+ compromised or malicious collector (or accepted an on-path attacker on that egress route) —
+ a threat model outside standard use of this optional telemetry feature.</li>
+</ul>
+<p>No released Solr version ships a fix for this specific line, because none currently needs one:
+9.10.0+ already carries a post-fix Netty. The <code>branch_9x</code> (→ 9.11.0) and <code>main</code>/<code>branch_10x</code>
+(→ 10.x) development branches have since moved further still, to Netty 4.2.15.Final and
+4.2.17.Final respectively — picked up incidentally through routine dependency updates rather
+than a targeted SOLR-17826 fix commit. SOLR-17826 remains open upstream and should be closed
+out to reflect that no supported or in-development Solr line is exposed.</p></content><category term="solr/vex"/></entry><entry><title>lz4-java: out-of-bounds memory access and insufficient buffer clearing in compression/decompression</title><link href="/cve-2025-12183.html" rel="alternate"/><published>2026-08-13T00:00:00+00:00</published><updated>2026-08-13T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2026-08-13:/cve-2025-12183.html</id><summar [...]
<ul>
<li><strong>CVE-2025-12183</strong> — several lz4-java compression/decompression implementations do not guard against
out-of-bounds memory access (fixed in <code>lz4-java</code> 1.8.1).</li>
@@ -1670,26 +1784,4 @@ ship any Struts jar — the dependency is excluded and only appears as a transit
(see SOLR-2849) — so these Struts vulnerabilities are not present in, or exploitable through, Solr.</p></content><category term="solr/vex"/></entry><entry><title>vorbis-java-tika</title><link href="/cve-2016-6809.html" rel="alternate"/><published>2022-12-14T00:00:00+00:00</published><updated>2022-12-14T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2022-12-14:/cve-2016-6809.html</id><content type="html"><p>See https://github.com/Gagravarr/Vo [...]
<p>Tika as an in-process component was removed in Solr 9.11.</p></content><category term="solr/vex"/></entry><entry><title>org.restlet</title><link href="/cve-2017-14868.html" rel="alternate"/><published>2022-12-14T00:00:00+00:00</published><updated>2022-12-14T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2022-12-14:/cve-2017-14868.html</id><content type="html"><p>Solr should not be exposed outside a firewall where bad actors can send [...]
<p>All 15 are pre-block-list "individual gadget" CVEs, fixed in jackson-databind ≤ 2.9.10.7 / ≤ 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's <strong>standalone</strong> <code>jackson-databind</code> — the <code>jackson-databind-*.jar</code> this statement covers — was within that range from 4.7.0 through Solr <strong>8.6.3</strong>: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all &lt; 2.10.5.1). Solr 8.7.0 [...]
-<p>SOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's <code>htrace-core4</code> jar in the 8.x line; the same reasoning applies, and <code>htrace-core4</code> (with its bundled jackson-databind) was removed in Solr 9.x.</p></content><category term="solr/vex"/></entry><entry><title>hadoop-auth</title><link href="/cve-2017-15718.html" rel="alternate"/><published>2022-12-14T00:00:00+00:00 [...]
-releases up to and including 2.0.6 (fixed in 2.0.6.1). Solr has bundled JDOM (transitively, via
-Apache Tika / Solr Cell) since Solr 3.6.0 — <code>jdom</code> 1.0, then <code>jdom</code> 2.0 …</p></summary><content type="html"><p>CVE-2021-33813 is an XML external entity (XXE) issue in JDOM's <code>SAXBuilder</code>, affecting all JDOM
-releases up to and including 2.0.6 (fixed in 2.0.6.1). Solr has bundled JDOM (transitively, via
-Apache Tika / Solr Cell) since Solr 3.6.0 — <code>jdom</code> 1.0, then <code>jdom</code> 2.0.2, then <code>jdom2</code> 2.0.6 —
-through the last 8.x release; Solr 9.0.0 upgraded to the fixed <code>jdom2</code> 2.0.6.1. The affected range is
-therefore 3.6.0 – 8.8.1.</p>
-<p>JDOM is only used in Solr Cell, which should not be used in production which makes the vulnerability unexploitable. It is a dependency of Apache Tika, which has analyzed the issue and determined the vulnerability is limited to two libraries not commonly used in search applications, see TIKA-3488 for details. Since Tika should be used outside of Solr, use a version of Tika which updates the affected libraries if concerned about exposure to this issue.</p></content><category [...]
-escape the input filename before passing it to a shell. It affects <code>hadoop-common</code> 2.0.0–2.10.1,
-3.0.0-alpha–3.2.3 and 3.3.0–3.3.2 (fixed in 2.10.2 …</p></summary><content type="html"><p>CVE-2022-25168 is a command-injection flaw in Apache Hadoop's <code>FileUtil.unTar(...)</code>, which fails to
-escape the input filename before passing it to a shell. It affects <code>hadoop-common</code> 2.0.0–2.10.1,
-3.0.0-alpha–3.2.3 and 3.3.0–3.3.2 (fixed in 2.10.2, 3.2.4 and 3.3.3). Solr has bundled an affected
-<code>hadoop-common</code> (transitively, for HDFS support) since Solr 4.4.0, through Solr 9.0.0 (which ships
-3.3.2); Solr 9.1.0 upgraded to the fixed 3.3.4. The affected range is therefore 4.4.0 – 9.0.0.</p>
-<p>The vulnerable code won't be used by Solr because Solr only is only using HDFS as a client.</p></content><category term="solr/vex"/></entry><entry><title>commons-configuration2</title><link href="/cve-2022-33980.html" rel="alternate"/><published>2022-12-14T00:00:00+00:00</published><updated>2022-12-14T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2022-12-14:/cve-2022-33980.html</id><summary type="html"><p>CVE-2022-33980 is a code-e [...]
-performed variable interpolation with <code>script</code>, <code>dns</code> and <code>url</code> lookups enabled by default (fixed in
-2.8.0). Only Solr 9.0.0 shipped an affected version (<code>commons-configuration2</code> 2.7); Solr 8.x shipped
-2.1 …</p></summary><content type="html"><p>CVE-2022-33980 is a code-execution issue in Apache Commons Configuration: versions 2.4 through 2.7
-performed variable interpolation with <code>script</code>, <code>dns</code> and <code>url</code> lookups enabled by default (fixed in
-2.8.0). Only Solr 9.0.0 shipped an affected version (<code>commons-configuration2</code> 2.7); Solr 8.x shipped
-2.1.1 (before the flaw was introduced) and Solr 9.1.0 upgraded to the fixed 2.8.0. The affected
-version is therefore 9.0.0 only.</p>
-<p>Solr uses commons-configuration2 for "hadoop-auth" only (for Kerberos). It is only used for loading Hadoop configuration files that would only ever be provided by trusted administrators, not externally (untrusted).</p></content><category term="solr/vex"/></entry></feed>
\ No newline at end of file
+<p>SOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's <code>htrace-core4</code> jar in the 8.x line; the same reasoning applies, and <code>htrace-core4</code> (with its bundled jackson-databind) was removed in Solr 9.x.</p></content><category term="solr/vex"/></entry><entry><title>hadoop-auth</title><link href="/cve-2017-15718.html" rel="alternate"/><published>2022-12-14T00:00:00+00:00 [...]
\ No newline at end of file
diff --git a/output/posts.html b/output/posts.html
index 715176d70..7009e2c4d 100644
--- a/output/posts.html
+++ b/output/posts.html
@@ -155,6 +155,15 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="walking-document-graphs-in-apache-solr" class="post-item-title">
+ <a href="blogposts/walking-document-graphs-in-apache-solr.html">Walking Document Graphs in Apache Solr</a>
+ <a class="headerlink" href="#walking-document-graphs-in-apache-solr" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ 4 September 2026
+ </h5>
+ <p>Solr can traverse multi-hop relationships already stored in the index — org charts, nested groups, product taxonomies — with the graph query parser. One hop is a join; the rest of the tree is a graph walk. Written by Prithvi S.</p>
+ <hr/>
<h2 id="jwt-authentication-blockunknown-default-allows-unauthenticated-access-contrary-to-documentation" class="post-item-title">
<a href="/news.html#jwt-authentication-blockunknown-default-allows-unauthenticated-access-contrary-to-documentation">JWT Authentication: blockUnknown default allows unauthenticated access contrary to documentation</a>
<a class="headerlink" href="#jwt-authentication-blockunknown-default-allows-unauthenticated-access-contrary-to-documentation" title="Permanent link">¶</a>
@@ -382,19 +391,6 @@
<a href="/news.html#cve-2024-45216-apache-solr-authentication-bypass-possible-using-a-fake-url-path-ending">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly" class="post-item-title">
- <a href="/news.html#cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly">CVE-2024-45217: Apache Solr: ConfigSets created during a backup restore command are trusted implicitly</a>
- <a class="headerlink" href="#cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>Security:</strong>
- 14 October 2024
- </h5>
- <p>Severity: Moderate Versions Affected: Apache Solr 6.6.0 before 8.11.4 Apache Solr 9.0.0 before 9.7.0 Description: Insecure Default Initialization of Resource vulnerability in Apache Solr. New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give …</p>
- <div class="read-more">
- <a href="/news.html#cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<span class="pagination-info">
diff --git a/output/posts2.html b/output/posts2.html
index ed00849d5..053165f35 100644
--- a/output/posts2.html
+++ b/output/posts2.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly" class="post-item-title">
+ <a href="/news.html#cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly">CVE-2024-45217: Apache Solr: ConfigSets created during a backup restore command are trusted implicitly</a>
+ <a class="headerlink" href="#cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>Security:</strong>
+ 14 October 2024
+ </h5>
+ <p>Severity: Moderate Versions Affected: Apache Solr 6.6.0 before 8.11.4 Apache Solr 9.0.0 before 9.7.0 Description: Insecure Default Initialization of Resource vulnerability in Apache Solr. New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give …</p>
+ <div class="read-more">
+ <a href="/news.html#cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="community-over-code-na-2024-birds-of-a-feather" class="post-item-title">
<a href="blogposts/community-over-code-na-2024-birds-of-a-feather.html">Community Over Code NA 2024 Apache Lucene/Solr Birds Of A Feather</a>
<a class="headerlink" href="#community-over-code-na-2024-birds-of-a-feather" title="Permanent link">¶</a>
@@ -358,19 +371,6 @@
<a href="/news.html#cve-2023-50291-apache-solr-can-leak-certain-passwords-due-to-system-property-redaction-logic-inconsistencies">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users" class="post-item-title">
- <a href="/news.html#cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users">CVE-2023-50292: Apache Solr Schema Designer blindly "trusts" all configsets, possibly leading to RCE by unauthenticated users</a>
- <a class="headerlink" href="#cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>Security:</strong>
- 8 February 2024
- </h5>
- <p>Severity: Moderate Versions Affected: Apache Solr 6.0.0 through 8.11.2 Apache Solr 9.0.0 before 9.3.0 Description: Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr. This issue affects Apache Solr: from 8.10.0 through 8 …</p>
- <div class="read-more">
- <a href="/news.html#cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<a href="/posts.html">← Previous</a>
diff --git a/output/posts3.html b/output/posts3.html
index 301fc98fa..1f7c3eba9 100644
--- a/output/posts3.html
+++ b/output/posts3.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users" class="post-item-title">
+ <a href="/news.html#cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users">CVE-2023-50292: Apache Solr Schema Designer blindly "trusts" all configsets, possibly leading to RCE by unauthenticated users</a>
+ <a class="headerlink" href="#cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>Security:</strong>
+ 8 February 2024
+ </h5>
+ <p>Severity: Moderate Versions Affected: Apache Solr 6.0.0 through 8.11.2 Apache Solr 9.0.0 before 9.3.0 Description: Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr. This issue affects Apache Solr: from 8.10.0 through 8 …</p>
+ <div class="read-more">
+ <a href="/news.html#cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="cve-2023-50298-apache-solr-can-expose-zookeeper-credentials-via-streaming-expressions" class="post-item-title">
<a href="/news.html#cve-2023-50298-apache-solr-can-expose-zookeeper-credentials-via-streaming-expressions">CVE-2023-50298: Apache Solr can expose ZooKeeper credentials via Streaming Expressions</a>
<a class="headerlink" href="#cve-2023-50298-apache-solr-can-expose-zookeeper-credentials-via-streaming-expressions" title="Permanent link">¶</a>
@@ -402,19 +415,6 @@
<a href="/news.html#apache-solr-affected-by-apache-log4j-cve-2021-44228">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="apache-solrtm-8110-available" class="post-item-title">
- <a href="/news.html#apache-solrtm-8110-available">Apache Solr™ 8.11.0 available</a>
- <a class="headerlink" href="#apache-solrtm-8110-available" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>News:</strong>
- 16 November 2021
- </h5>
- <p>The Solr PMC is pleased to announce the release of Apache Solr 8.11.0. 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>
- <div class="read-more">
- <a href="/news.html#apache-solrtm-8110-available">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<a href="/posts2.html">← Previous</a>
diff --git a/output/posts4.html b/output/posts4.html
index 8aecd29a9..532fc722b 100644
--- a/output/posts4.html
+++ b/output/posts4.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="apache-solrtm-8110-available" class="post-item-title">
+ <a href="/news.html#apache-solrtm-8110-available">Apache Solr™ 8.11.0 available</a>
+ <a class="headerlink" href="#apache-solrtm-8110-available" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>News:</strong>
+ 16 November 2021
+ </h5>
+ <p>The Solr PMC is pleased to announce the release of Apache Solr 8.11.0. 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>
+ <div class="read-more">
+ <a href="/news.html#apache-solrtm-8110-available">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="apache-solrtm-8101-available" class="post-item-title">
<a href="/news.html#apache-solrtm-8101-available">Apache Solr™ 8.10.1 available</a>
<a class="headerlink" href="#apache-solrtm-8101-available" title="Permanent link">¶</a>
@@ -402,19 +415,6 @@
<a href="/news.html#apache-solrtm-773-available">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="apache-solrtm-851-available" class="post-item-title">
- <a href="/news.html#apache-solrtm-851-available">Apache Solr™ 8.5.1 available</a>
- <a class="headerlink" href="#apache-solrtm-851-available" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>News:</strong>
- 16 April 2020
- </h5>
- <p>The Lucene PMC is pleased to announce the release of Apache Solr 8.5.1 Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search and analytics, rich document parsing, geospatial search, extensive …</p>
- <div class="read-more">
- <a href="/news.html#apache-solrtm-851-available">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<a href="/posts3.html">← Previous</a>
diff --git a/output/posts5.html b/output/posts5.html
index 1d47fd268..1f5259075 100644
--- a/output/posts5.html
+++ b/output/posts5.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="apache-solrtm-851-available" class="post-item-title">
+ <a href="/news.html#apache-solrtm-851-available">Apache Solr™ 8.5.1 available</a>
+ <a class="headerlink" href="#apache-solrtm-851-available" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>News:</strong>
+ 16 April 2020
+ </h5>
+ <p>The Lucene PMC is pleased to announce the release of Apache Solr 8.5.1 Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search and analytics, rich document parsing, geospatial search, extensive …</p>
+ <div class="read-more">
+ <a href="/news.html#apache-solrtm-851-available">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="apache-solrtm-850-available" class="post-item-title">
<a href="/news.html#apache-solrtm-850-available">Apache Solr™ 8.5.0 available</a>
<a class="headerlink" href="#apache-solrtm-850-available" title="Permanent link">¶</a>
@@ -402,19 +415,6 @@
<a href="/news.html#apache-solrtm-771-available">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="cve-2017-3164-ssrf-issue-in-apache-solr" class="post-item-title">
- <a href="/news.html#cve-2017-3164-ssrf-issue-in-apache-solr">CVE-2017-3164: SSRF issue in Apache Solr</a>
- <a class="headerlink" href="#cve-2017-3164-ssrf-issue-in-apache-solr" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>Security:</strong>
- 12 February 2019
- </h5>
- <p>Severity: High Vendor: The Apache Software Foundation Versions Affected: Apache Solr versions from 1.3 to 7.6.0 Description: The "shards" parameter does not have a corresponding whitelist mechanism, so it can request any URL. Mitigation: Upgrade to Apache Solr 7.7.0 or later. Ensure your network settings …</p>
- <div class="read-more">
- <a href="/news.html#cve-2017-3164-ssrf-issue-in-apache-solr">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<a href="/posts4.html">← Previous</a>
diff --git a/output/posts6.html b/output/posts6.html
index c6140f45b..566749f27 100644
--- a/output/posts6.html
+++ b/output/posts6.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="cve-2017-3164-ssrf-issue-in-apache-solr" class="post-item-title">
+ <a href="/news.html#cve-2017-3164-ssrf-issue-in-apache-solr">CVE-2017-3164: SSRF issue in Apache Solr</a>
+ <a class="headerlink" href="#cve-2017-3164-ssrf-issue-in-apache-solr" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>Security:</strong>
+ 12 February 2019
+ </h5>
+ <p>Severity: High Vendor: The Apache Software Foundation Versions Affected: Apache Solr versions from 1.3 to 7.6.0 Description: The "shards" parameter does not have a corresponding whitelist mechanism, so it can request any URL. Mitigation: Upgrade to Apache Solr 7.7.0 or later. Ensure your network settings …</p>
+ <div class="read-more">
+ <a href="/news.html#cve-2017-3164-ssrf-issue-in-apache-solr">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="apache-solrtm-770-available" class="post-item-title">
<a href="/news.html#apache-solrtm-770-available">Apache Solr™ 7.7.0 available</a>
<a class="headerlink" href="#apache-solrtm-770-available" title="Permanent link">¶</a>
@@ -402,19 +415,6 @@
<a href="/news.html#solr-security-please-secure-your-apache-solr-servers-since-a-zero-day-exploit-has-been-reported-on-a-public-mailing-list">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="apache-solrtm-701-available" class="post-item-title">
- <a href="/news.html#apache-solrtm-701-available">Apache Solr™ 7.0.1 available</a>
- <a class="headerlink" href="#apache-solrtm-701-available" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>News:</strong>
- 6 October 2017
- </h5>
- <p>Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search and analytics, rich document parsing, geospatial search, extensive REST APIs as well as parallel SQL. Solr is enterprise grade, secure and highly scalable …</p>
- <div class="read-more">
- <a href="/news.html#apache-solrtm-701-available">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<a href="/posts5.html">← Previous</a>
diff --git a/output/posts7.html b/output/posts7.html
index e0c04bd44..6f5d3f1c4 100644
--- a/output/posts7.html
+++ b/output/posts7.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="apache-solrtm-701-available" class="post-item-title">
+ <a href="/news.html#apache-solrtm-701-available">Apache Solr™ 7.0.1 available</a>
+ <a class="headerlink" href="#apache-solrtm-701-available" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>News:</strong>
+ 6 October 2017
+ </h5>
+ <p>Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search and analytics, rich document parsing, geospatial search, extensive REST APIs as well as parallel SQL. Solr is enterprise grade, secure and highly scalable …</p>
+ <div class="read-more">
+ <a href="/news.html#apache-solrtm-701-available">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="apache-solr-reference-guide-for-70-available" class="post-item-title">
<a href="/news.html#apache-solr-reference-guide-for-70-available">Apache Solr Reference Guide for 7.0 available</a>
<a class="headerlink" href="#apache-solr-reference-guide-for-70-available" title="Permanent link">¶</a>
@@ -402,19 +415,6 @@
<a href="/news.html#apache-solr-553-available">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="apache-solr-620-available" class="post-item-title">
- <a href="/news.html#apache-solr-620-available">Apache Solr 6.2.0 available</a>
- <a class="headerlink" href="#apache-solr-620-available" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>News:</strong>
- 25 August 2016
- </h5>
- <p>The Lucene PMC is pleased to announce the release of Apache Solr 6.2.0. Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search and analytics, rich document parsing, geospatial search, extensive …</p>
- <div class="read-more">
- <a href="/news.html#apache-solr-620-available">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<a href="/posts6.html">← Previous</a>
diff --git a/output/posts8.html b/output/posts8.html
index 52d8441f7..308244709 100644
--- a/output/posts8.html
+++ b/output/posts8.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="apache-solr-620-available" class="post-item-title">
+ <a href="/news.html#apache-solr-620-available">Apache Solr 6.2.0 available</a>
+ <a class="headerlink" href="#apache-solr-620-available" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>News:</strong>
+ 25 August 2016
+ </h5>
+ <p>The Lucene PMC is pleased to announce the release of Apache Solr 6.2.0. Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search and analytics, rich document parsing, geospatial search, extensive …</p>
+ <div class="read-more">
+ <a href="/news.html#apache-solr-620-available">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="apache-solr-552-available" class="post-item-title">
<a href="/news.html#apache-solr-552-available">Apache Solr 5.5.2 available</a>
<a class="headerlink" href="#apache-solr-552-available" title="Permanent link">¶</a>
@@ -402,19 +415,6 @@
<a href="/news.html#apache-solr-4104-available">Read full article on news page →</a>
</div>
<hr/>
- <h2 id="apache-solr-500-and-reference-guide-for-50-available" class="post-item-title">
- <a href="/news.html#apache-solr-500-and-reference-guide-for-50-available">Apache Solr 5.0.0 and Reference Guide for 5.0 available</a>
- <a class="headerlink" href="#apache-solr-500-and-reference-guide-for-50-available" title="Permanent link">¶</a>
- </h2>
- <h5>
- <strong>News:</strong>
- 20 February 2015
- </h5>
- <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 (e.g., Word, PDF) handling, and geospatial search. Solr is highly scalable, providing fault tolerant distributed search …</p>
- <div class="read-more">
- <a href="/news.html#apache-solr-500-and-reference-guide-for-50-available">Read full article on news page →</a>
- </div>
- <hr/>
<div class="pagination">
<a href="/posts7.html">← Previous</a>
diff --git a/output/posts9.html b/output/posts9.html
index eb37281b4..bf6c48876 100644
--- a/output/posts9.html
+++ b/output/posts9.html
@@ -155,6 +155,19 @@
<h1 id="solr-news">Solr<sup>™</sup> News<a class="headerlink" href="#solr-news" title="Permanent link">¶</a></h1>
+ <h2 id="apache-solr-500-and-reference-guide-for-50-available" class="post-item-title">
+ <a href="/news.html#apache-solr-500-and-reference-guide-for-50-available">Apache Solr 5.0.0 and Reference Guide for 5.0 available</a>
+ <a class="headerlink" href="#apache-solr-500-and-reference-guide-for-50-available" title="Permanent link">¶</a>
+ </h2>
+ <h5>
+ <strong>News:</strong>
+ 20 February 2015
+ </h5>
+ <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 (e.g., Word, PDF) handling, and geospatial search. Solr is highly scalable, providing fault tolerant distributed search …</p>
+ <div class="read-more">
+ <a href="/news.html#apache-solr-500-and-reference-guide-for-50-available">Read full article on news page →</a>
+ </div>
+ <hr/>
<h2 id="apache-solr-4103-available" class="post-item-title">
<a href="/news.html#apache-solr-4103-available">Apache Solr 4.10.3 Available</a>
<a class="headerlink" href="#apache-solr-4103-available" title="Permanent link">¶</a>
diff --git a/output/security-dependency-cves.html b/output/security-dependency-cves.html
index 76f678ca4..d9630c4f8 100644
--- a/output/security-dependency-cves.html
+++ b/output/security-dependency-cves.html
@@ -191,6 +191,51 @@ 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-64607">CVE-2026-64607</a> </td>
+ <td>9.1.0-10.0.0</td>
+ <td>
+ httpclient5-5.5.jar </td>
+ <td><span class="cdx-not-affected">not affected</span></td>
+ <td><a href="/vex.html#cve-2026-64607">Apache HttpComponents Client: connection leak on Content-Encoding decode error</a></td>
+ </tr>
+ <tr>
+ <td>
+<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-54428">CVE-2026-54428</a> </td>
+ <td>9.1.0-10.0.0</td>
+ <td>
+ httpcore5-h2-5.3.4.jar </td>
+ <td><span class="cdx-not-affected">not affected</span></td>
+ <td><a href="/vex.html#cve-2026-54428">Apache HttpComponents Core: HPACK decoder unlimited header list size before SETTINGS ACK</a></td>
+ </tr>
+ <tr>
+ <td>
+<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-54399">CVE-2026-54399</a> </td>
+ <td>9.1.0-10.0.0</td>
+ <td>
+ httpcore5-5.3.5.jar </td>
+ <td><span class="cdx-not-affected">not affected</span></td>
+ <td><a href="/vex.html#cve-2026-54399">Apache HttpComponents Core: HTTP/1 header parsing memory-exhaustion denial of service</a></td>
+ </tr>
+ <tr>
+ <td>
+<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-48779">CVE-2026-48779</a> </td>
+ <td>10.0.0</td>
+ <td>
+ ws-8.18.0.tgz </td>
+ <td><span class="cdx-not-affected">not affected</span></td>
+ <td><a href="/vex.html#cve-2026-48779">ws: memory exhaustion denial of service from tiny WebSocket fragments</a></td>
+ </tr>
+ <tr>
+ <td>
+<a href="https://nvd.nist.gov/vuln/detail/CVE-2025-24970">CVE-2025-24970</a> </td>
+ <td>9.3.0-9.9.0</td>
+ <td>
+ netty-handler-4.1.114.Final.jar </td>
+ <td><span class="cdx-not-affected">not affected</span></td>
+ <td><a href="/vex.html#cve-2025-24970">Netty: SslHandler native crash on crafted packets</a></td>
+ </tr>
+ <tr>
+ <td>
<a href="https://nvd.nist.gov/vuln/detail/CVE-2025-12183">CVE-2025-12183</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-66566">CVE-2025-66566</a> </td>
<td>9.8.0-10.0.0</td>
<td>
diff --git a/output/solr.openvex.json b/output/solr.openvex.json
index 02ef64c30..d08fc2724 100644
--- a/output/solr.openvex.json
+++ b/output/solr.openvex.json
@@ -2,7 +2,7 @@
"@context": "https://openvex.dev/ns/v0.2.0",
"@id": "https://solr.apache.org/solr.openvex.json",
"author": "Apache Solr Project (security@apache.org)",
- "timestamp": "2026-08-13T00:00:00Z",
+ "timestamp": "2026-08-25T00:00:00Z",
"version": 1,
"statements": [
{
@@ -4323,6 +4323,95 @@
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "Two issues in the `lz4-java` codec:\n\n* **CVE-2025-12183** \u2014 several lz4-java compression/decompression implementations do not guard against\n out-of-bounds memory access (fixed in `lz4-java` 1.8.1).\n* **CVE-2025-66566** \u2014 decompressor implementations insufficiently clear their buffers, allowing a\n caller to read leftover contents of a previously used buffer (fixed in `lz4-java` 1.10.1).\n\nBoth require an application to drive lz4-java's (de)comp [...]
"status_notes": "Affected Apache Solr versions: 9.8.0-10.0.0."
+ },
+ {
+ "vulnerability": {
+ "name": "CVE-2025-24970"
+ },
+ "products": [
+ {
+ "@id": "pkg:maven/io.netty/netty-handler@4.1.104.Final"
+ },
+ {
+ "@id": "pkg:maven/io.netty/netty-handler@4.1.108.Final"
+ },
+ {
+ "@id": "pkg:maven/io.netty/netty-handler@4.1.111.Final"
+ },
+ {
+ "@id": "pkg:maven/io.netty/netty-handler@4.1.114.Final"
+ },
+ {
+ "@id": "pkg:maven/io.netty/netty-handler@4.1.93.Final"
+ },
+ {
+ "@id": "pkg:maven/io.netty/netty-handler@4.1.99.Final"
+ }
+ ],
+ "status": "not_affected",
+ "timestamp": "2026-08-23T00:00:00Z",
+ "impact_statement": "CVE-2025-24970 is a flaw in Netty's `SslHandler`: when the native (OpenSSL/BoringSSL, via\n`netty-tcnative`) TLS engine is in use, a specially crafted packet received during TLS\nprocessing is not properly validated, which can trigger a native crash (JVM segfault) rather\nthan a clean exception. It affects Netty `netty-handler` versions 4.1.91.Final through\n4.1.117.Final; fixed in 4.1.118.Final. The 4.2.x release line is not in the affected range at\nall \u201 [...]
+ "status_notes": "Affected Apache Solr versions: 9.3.0-9.9.0."
+ },
+ {
+ "vulnerability": {
+ "name": "CVE-2026-48779"
+ },
+ "products": [
+ {
+ "@id": "ws-8.18.0.tgz"
+ }
+ ],
+ "status": "not_affected",
+ "timestamp": "2026-08-25T00:00:00Z",
+ "justification": "vulnerable_code_not_present",
+ "impact_statement": "CVE-2026-48779 is a memory-exhaustion denial-of-service issue in the Node.js `ws` WebSocket library:\na peer that sends a high volume of exceptionally small message fragments can force the receiving side\nto allocate and retain structural wrappers far larger than the documented message-size limit,\neventually exhausting memory. It affects `ws` 8.0.0 through 8.20.x; fixed in 8.21.0 (with backports\nto the 5.x/6.x/7.x lines for older major versions).\n\nSolr is * [...]
+ "status_notes": "Affected Apache Solr versions: 10.0.0."
+ },
+ {
+ "vulnerability": {
+ "name": "CVE-2026-54399"
+ },
+ "products": [
+ {
+ "@id": "httpcore5-5.3.5.jar"
+ }
+ ],
+ "status": "not_affected",
+ "timestamp": "2026-08-25T00:00:00Z",
+ "justification": "vulnerable_code_not_in_execute_path",
+ "impact_statement": "CVE-2026-54399 is an uncontrolled-resource-consumption issue in Apache HttpComponents Core's HTTP/1.1\nmessage parser: a remote peer can send messages with an excessive number of headers or excessive\nheader length, exhausting memory and causing a denial of service. It affects `httpcore5` 5.4.2 and\nearlier (and 5.5-beta1 and earlier); fixed in 5.4.3.\n\nSolr is **not affected**. `httpcore5` is bundled transitively by\n`org.apache.calcite.avatica:avatica-core`, [...]
+ "status_notes": "Affected Apache Solr versions: 9.1.0-10.0.0."
+ },
+ {
+ "vulnerability": {
+ "name": "CVE-2026-54428"
+ },
+ "products": [
+ {
+ "@id": "httpcore5-h2-5.3.4.jar"
+ }
+ ],
+ "status": "not_affected",
+ "timestamp": "2026-08-25T00:00:00Z",
+ "justification": "vulnerable_code_not_in_execute_path",
+ "impact_statement": "CVE-2026-54428 is an allocation-without-limits issue in Apache HttpComponents Core's HTTP/2 HPACK\ndecoder: before an HTTP/2 peer's `SETTINGS` frame is acknowledged, the configured header list size\nlimit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust\nmemory, causing a denial of service. It affects `httpcore5-h2` 5.4.2 and earlier (and 5.5-beta1 and\nearlier); fixed in 5.4.3.\n\nSolr is **not affected**. `httpcore5- [...]
+ "status_notes": "Affected Apache Solr versions: 9.1.0-10.0.0."
+ },
+ {
+ "vulnerability": {
+ "name": "CVE-2026-64607"
+ },
+ "products": [
+ {
+ "@id": "httpclient5-5.5.jar"
+ }
+ ],
+ "status": "not_affected",
+ "timestamp": "2026-08-25T00:00:00Z",
+ "justification": "vulnerable_code_not_in_execute_path",
+ "impact_statement": "CVE-2026-64607 (medium severity) is a connection-leak bug in Apache HttpComponents Client's classic\n(blocking) I/O model: if a response has an invalid or unsupported `Content-Encoding` header, the\nclient fails to release the underlying connection back to the connection manager, eventually\nexhausting the pool and causing a denial of service. It does not affect HttpClient's async I/O model.\nIt affects `httpclient5` from 5.0-alpha1 through 5.6.2; fixed in 5.6. [...]
+ "status_notes": "Affected Apache Solr versions: 9.1.0-10.0.0."
}
]
}
\ No newline at end of file
diff --git a/output/solr.vex.json b/output/solr.vex.json
index 73b2c093d..6d1e97d01 100644
--- a/output/solr.vex.json
+++ b/output/solr.vex.json
@@ -7,7 +7,7 @@
"name": "solr",
"version": "SNAPSHOT",
"type": "application",
- "bom-ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "bom-ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
},
"vulnerabilities": [
@@ -23,7 +23,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -39,7 +39,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -55,7 +55,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -71,7 +71,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -87,7 +87,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -103,7 +103,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -119,7 +119,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -135,7 +135,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -151,7 +151,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -167,7 +167,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -183,7 +183,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -199,7 +199,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -215,7 +215,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -231,7 +231,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -247,7 +247,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -263,7 +263,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -279,7 +279,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -295,7 +295,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -311,7 +311,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -327,7 +327,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -343,7 +343,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -359,7 +359,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -375,7 +375,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -391,7 +391,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -407,7 +407,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -423,7 +423,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -439,7 +439,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -455,7 +455,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -471,7 +471,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -487,7 +487,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -503,7 +503,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -519,7 +519,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -535,7 +535,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -551,7 +551,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -567,7 +567,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -583,7 +583,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -599,7 +599,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -615,7 +615,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -631,7 +631,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -647,7 +647,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -663,7 +663,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -679,7 +679,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -695,7 +695,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -711,7 +711,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -727,7 +727,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -743,7 +743,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -759,7 +759,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -775,7 +775,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -791,7 +791,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -807,7 +807,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -823,7 +823,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -839,7 +839,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -855,7 +855,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -871,7 +871,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -887,7 +887,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -903,7 +903,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -919,7 +919,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -935,7 +935,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -951,7 +951,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -970,7 +970,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -986,7 +986,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1002,7 +1002,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1018,7 +1018,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1037,7 +1037,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1053,7 +1053,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1070,7 +1070,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1087,7 +1087,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1104,7 +1104,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1121,7 +1121,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1138,7 +1138,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1155,7 +1155,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1172,7 +1172,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1189,7 +1189,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1206,7 +1206,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1223,7 +1223,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1240,7 +1240,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1257,7 +1257,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1274,7 +1274,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1291,7 +1291,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1308,7 +1308,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1325,7 +1325,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1342,7 +1342,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1359,7 +1359,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1376,7 +1376,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1393,7 +1393,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1410,7 +1410,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1427,7 +1427,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1444,7 +1444,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1464,7 +1464,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1484,7 +1484,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1504,7 +1504,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1521,7 +1521,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1541,7 +1541,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1558,7 +1558,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1575,7 +1575,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1592,7 +1592,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1609,7 +1609,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1626,7 +1626,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1643,7 +1643,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1660,7 +1660,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1677,7 +1677,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1694,7 +1694,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1711,7 +1711,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1728,7 +1728,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1745,7 +1745,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1762,7 +1762,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1779,7 +1779,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1796,7 +1796,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1813,7 +1813,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1830,7 +1830,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1847,7 +1847,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1864,7 +1864,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1881,7 +1881,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1898,7 +1898,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1915,7 +1915,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1932,7 +1932,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1949,7 +1949,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1966,7 +1966,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -1983,7 +1983,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2000,7 +2000,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2017,7 +2017,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2034,7 +2034,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2051,7 +2051,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2068,7 +2068,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2085,7 +2085,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2102,7 +2102,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2119,7 +2119,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2136,7 +2136,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2153,7 +2153,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2170,7 +2170,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2187,7 +2187,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2204,7 +2204,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2221,7 +2221,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2238,7 +2238,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2255,7 +2255,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2272,7 +2272,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2289,7 +2289,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2306,7 +2306,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2323,7 +2323,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2340,7 +2340,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2357,7 +2357,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2374,7 +2374,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2391,7 +2391,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2408,7 +2408,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2425,7 +2425,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2442,7 +2442,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2459,7 +2459,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2476,7 +2476,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2493,7 +2493,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2510,7 +2510,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2529,7 +2529,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2546,7 +2546,7 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
},
@@ -2563,7 +2563,92 @@
},
"affects": [
{
- "ref": "1f72af82-5d37-5e80-ab99-8e6f4eb2ec4d"
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2025-24970",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24970"
+ },
+ "analysis": {
+ "state": "not_affected",
+ "justification": "requires_configuration",
+ "detail": "CVE-2025-24970 is a flaw in Netty's `SslHandler`: when the native (OpenSSL/BoringSSL, via\n`netty-tcnative`) TLS engine is in use, a specially crafted packet received during TLS\nprocessing is not properly validated, which can trigger a native crash (JVM segfault) rather\nthan a clean exception. It affects Netty `netty-handler` versions 4.1.91.Final through\n4.1.117.Final; fixed in 4.1.118.Final. The 4.2.x release line is not in the affected range at\nall \u2014 4.2.0. [...]
+ },
+ "affects": [
+ {
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-48779",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48779"
+ },
+ "analysis": {
+ "state": "not_affected",
+ "justification": "code_not_present",
+ "detail": "CVE-2026-48779 is a memory-exhaustion denial-of-service issue in the Node.js `ws` WebSocket library:\na peer that sends a high volume of exceptionally small message fragments can force the receiving side\nto allocate and retain structural wrappers far larger than the documented message-size limit,\neventually exhausting memory. It affects `ws` 8.0.0 through 8.20.x; fixed in 8.21.0 (with backports\nto the 5.x/6.x/7.x lines for older major versions).\n\nSolr is **not aff [...]
+ },
+ "affects": [
+ {
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-54399",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54399"
+ },
+ "analysis": {
+ "state": "not_affected",
+ "justification": "code_not_reachable",
+ "detail": "CVE-2026-54399 is an uncontrolled-resource-consumption issue in Apache HttpComponents Core's HTTP/1.1\nmessage parser: a remote peer can send messages with an excessive number of headers or excessive\nheader length, exhausting memory and causing a denial of service. It affects `httpcore5` 5.4.2 and\nearlier (and 5.5-beta1 and earlier); fixed in 5.4.3.\n\nSolr is **not affected**. `httpcore5` is bundled transitively by\n`org.apache.calcite.avatica:avatica-core`, which u [...]
+ },
+ "affects": [
+ {
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-54428",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54428"
+ },
+ "analysis": {
+ "state": "not_affected",
+ "justification": "code_not_reachable",
+ "detail": "CVE-2026-54428 is an allocation-without-limits issue in Apache HttpComponents Core's HTTP/2 HPACK\ndecoder: before an HTTP/2 peer's `SETTINGS` frame is acknowledged, the configured header list size\nlimit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust\nmemory, causing a denial of service. It affects `httpcore5-h2` 5.4.2 and earlier (and 5.5-beta1 and\nearlier); fixed in 5.4.3.\n\nSolr is **not affected**. `httpcore5-h2` is b [...]
+ },
+ "affects": [
+ {
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
+ }
+ ]
+ },
+ {
+ "id": "CVE-2026-64607",
+ "source": {
+ "name": "NVD",
+ "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64607"
+ },
+ "analysis": {
+ "state": "not_affected",
+ "justification": "code_not_reachable",
+ "detail": "CVE-2026-64607 (medium severity) is a connection-leak bug in Apache HttpComponents Client's classic\n(blocking) I/O model: if a response has an invalid or unsupported `Content-Encoding` header, the\nclient fails to release the underlying connection back to the connection manager, eventually\nexhausting the pool and causing a denial of service. It does not affect HttpClient's async I/O model.\nIt affects `httpclient5` from 5.0-alpha1 through 5.6.2; fixed in 5.6.3.\n\nSo [...]
+ },
+ "affects": [
+ {
+ "ref": "d37e76c9-d410-5cb1-82a1-e9fda42daf1f"
}
]
}
diff --git a/output/vex.html b/output/vex.html
index ad1edc640..d0df75e95 100644
--- a/output/vex.html
+++ b/output/vex.html
@@ -142,6 +142,210 @@
<h1>Apache Solr VEX</h1>
<p><a href="/security-dependency-cves.html">← Back to the dependency CVE table</a></p>
+ <article id="cve-2026-64607" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a href="https://nvd.nist.gov/vuln/detail/CVE-2026-64607">CVE-2026-64607</a>, Apache HttpComponents Client: connection leak on Content-Encoding decode error</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.1.0-10.0.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-64607 (medium severity) is a connection-leak bug in Apache HttpComponents Client's classic
+(blocking) I/O model: if a response has an invalid or unsupported <code>Content-Encoding</code> header, the
+client fails to release the underlying connection back to the connection manager, eventually
+exhausting the pool and causing a denial of service. It does not affect HttpClient's async I/O model.
+It affects <code>httpclient5</code> from 5.0-alpha1 through 5.6.2; fixed in 5.6.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpclient5</code> (along with <code>httpcore5</code> and <code>httpcore5-h2</code>, covered in
+separate VEX entries for their own CVEs) is bundled transitively by <code>org.apache.calcite.avatica:avatica-core</code>,
+which uses it to support Avatica's <em>optional remote-JDBC</em> transport -- connecting to a remote Avatica
+server over HTTP. Solr's own <code>/sql</code> handler (<code>CalciteSolrDriver</code>) only ever opens a local, in-process
+<code>org.apache.calcite.jdbc.CalciteConnection</code>; there is no <code>org.apache.hc.client5</code>/<code>org.apache.hc.core5</code>
+usage anywhere in <code>solr/modules/sql</code>'s source, and Solr never acts as an Avatica HTTP client or server.
+The dependency has in fact been marked <code>permitUnusedDeclared</code> in Solr's own build since at least the
+10.0.0 release, confirming the build's own dependency-analysis tooling already recognized it as
+present-but-unused. It's also shipped only via the optional <code>solr:modules:sql</code> module -- every other
+place it appears (<code>solrj-streaming</code>, <code>solr-ref-guide</code>, <code>webapp</code>) is test-scope only, not shipped.</p>
+<p>Solr has shipped an affected <code>httpclient5</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.5). <code>branch_9x</code> has since moved to 5.6.4, past the fix -- picked up
+incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the code path
+is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a href="https://nvd.nist.gov/vuln/detail/CVE-2026-64607">CVE-2026-64607</a></li>
+ </ul>
+ </article>
+ <article id="cve-2026-54428" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a href="https://nvd.nist.gov/vuln/detail/CVE-2026-54428">CVE-2026-54428</a>, Apache HttpComponents Core: HPACK decoder unlimited header list size before SETTINGS ACK</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.1.0-10.0.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-54428 is an allocation-without-limits issue in Apache HttpComponents Core's HTTP/2 HPACK
+decoder: before an HTTP/2 peer's <code>SETTINGS</code> frame is acknowledged, the configured header list size
+limit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust
+memory, causing a denial of service. It affects <code>httpcore5-h2</code> 5.4.2 and earlier (and 5.5-beta1 and
+earlier); fixed in 5.4.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpcore5-h2</code> is bundled transitively by
+<code>org.apache.calcite.avatica:avatica-core</code>, which uses it to support Avatica's <em>optional remote-JDBC</em>
+HTTP/2 transport -- see the companion VEX entry for CVE-2026-64607 (<code>httpclient5</code>) for the full
+reachability analysis, which applies identically here: Solr's <code>/sql</code> handler never uses Avatica's
+remote HTTP transport, only the local embedded <code>CalciteConnection</code>, so the HPACK decoder this CVE
+concerns -- which only runs when HttpComponents is actually acting as an HTTP/2 endpoint -- is never
+invoked. The dependency is <code>permitUnusedDeclared</code> in Solr's own build and shipped only via the
+optional <code>solr:modules:sql</code> module.</p>
+<p>Solr has shipped an affected <code>httpcore5-h2</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.3.4). <code>branch_9x</code> has since moved to 5.4.3, exactly the fix version --
+picked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the
+code path is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a href="https://nvd.nist.gov/vuln/detail/CVE-2026-54428">CVE-2026-54428</a></li>
+ </ul>
+ </article>
+ <article id="cve-2026-54399" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a href="https://nvd.nist.gov/vuln/detail/CVE-2026-54399">CVE-2026-54399</a>, Apache HttpComponents Core: HTTP/1 header parsing memory-exhaustion denial of service</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.1.0-10.0.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-54399 is an uncontrolled-resource-consumption issue in Apache HttpComponents Core's HTTP/1.1
+message parser: a remote peer can send messages with an excessive number of headers or excessive
+header length, exhausting memory and causing a denial of service. It affects <code>httpcore5</code> 5.4.2 and
+earlier (and 5.5-beta1 and earlier); fixed in 5.4.3.</p>
+<p>Solr is <strong>not affected</strong>. <code>httpcore5</code> is bundled transitively by
+<code>org.apache.calcite.avatica:avatica-core</code>, which uses it to support Avatica's <em>optional remote-JDBC</em>
+HTTP transport -- see the companion VEX entry for CVE-2026-64607 (<code>httpclient5</code>) for the full
+reachability analysis, which applies identically here: Solr's <code>/sql</code> handler never uses Avatica's
+remote HTTP transport, only the local embedded <code>CalciteConnection</code>, so <code>httpcore5</code>'s HTTP/1.1 message
+parser is never invoked to process any inbound message, trusted or otherwise. The dependency is
+<code>permitUnusedDeclared</code> in Solr's own build and shipped only via the optional <code>solr:modules:sql</code>
+module.</p>
+<p>Solr has shipped an affected <code>httpcore5</code> since at least 9.1.0 (through 10.0.0, and continuing on
+<code>branch_10x</code>/<code>main</code> at 5.3.5). <code>branch_9x</code> has since moved to 5.4.3, exactly the fix version --
+picked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the
+code path is unreachable regardless, no fix is required on <code>branch_10x</code>/<code>main</code> either.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a href="https://nvd.nist.gov/vuln/detail/CVE-2026-54399">CVE-2026-54399</a></li>
+ </ul>
+ </article>
+ <article id="cve-2026-48779" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a href="https://nvd.nist.gov/vuln/detail/CVE-2026-48779">CVE-2026-48779</a>, ws: memory exhaustion denial of service from tiny WebSocket fragments</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> 10.0.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2026-48779 is a memory-exhaustion denial-of-service issue in the Node.js <code>ws</code> WebSocket library:
+a peer that sends a high volume of exceptionally small message fragments can force the receiving side
+to allocate and retain structural wrappers far larger than the documented message-size limit,
+eventually exhausting memory. It affects <code>ws</code> 8.0.0 through 8.20.x; fixed in 8.21.0 (with backports
+to the 5.x/6.x/7.x lines for older major versions).</p>
+<p>Solr is <strong>not affected</strong>. <code>ws</code> is pinned in <code>kotlin-js-store/wasm/yarn.lock</code>, an auto-generated
+lockfile for the Kotlin/Wasm build toolchain that compiles the new Compose-based Admin UI
+(<code>solr/ui</code>). It is a transitive dependency of that toolchain's Node.js-based dev-server/test-runner
+tooling, not of Solr's own code. <code>ws</code> depends on Node.js's native TCP socket APIs, which don't exist
+in a browser sandbox -- it is therefore not possible for it to be bundled into the actual
+browser-executable Wasm/JS output that ships to end users and runs in their browser. This isn't a
+case of unreachable-but-present code; the vulnerable component is never part of the shipped product
+artifact at all, only of the build/test pipeline that produces it.</p>
+<p><code>ws</code> has been present in <code>solr/ui</code>'s build tooling since it was first introduced (shipped in the
+10.0.0 release at <code>ws@8.18.0</code>/<code>ws@8.18.3</code>, both within the affected range). <code>branch_9x</code> doesn't have
+this module at all. Since this dependency never reaches a shipped artifact, no application-level fix
+is required; bumping it is worth doing as routine build-tooling hygiene regardless, since a compromised
+or misbehaving local/CI dev-server dependency is still worth avoiding even without direct product
+exposure.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>CVE: <a href="https://nvd.nist.gov/vuln/detail/CVE-2026-48779">CVE-2026-48779</a></li>
+ </ul>
+ </article>
+ <article id="cve-2025-24970" class="post panel radius">
+ <header class="post-header">
+ <h3 class="title"><a href="https://nvd.nist.gov/vuln/detail/CVE-2025-24970">CVE-2025-24970</a>, Netty: SslHandler native crash on crafted packets</h3>
+ <div class="panel callout">
+ <p class="subheader">
+ <strong>Published:</strong>
+ <time datetime="2026-08-23T00:00:00+00:00">2026-08-23</time>
+ </p>
+ <p class="subheader">
+ <strong>Status:</strong>
+ <span class="cdx-not-affected">not_affected</span>
+ </p>
+ <p class="subheader"><strong>Affected Solr versions:</strong> 9.3.0-9.9.0</p>
+ </div>
+ </header>
+
+ <h4>Description</h4>
+ <p>CVE-2025-24970 is a flaw in Netty's <code>SslHandler</code>: when the native (OpenSSL/BoringSSL, via
+<code>netty-tcnative</code>) TLS engine is in use, a specially crafted packet received during TLS
+processing is not properly validated, which can trigger a native crash (JVM segfault) rather
+than a clean exception. It affects Netty <code>netty-handler</code> versions 4.1.91.Final through
+4.1.117.Final; fixed in 4.1.118.Final. The 4.2.x release line is not in the affected range at
+all — 4.2.0.Final was cut after the fix had already landed upstream.</p>
+<p>Solr shipped an affected <code>netty-handler</code> from 9.3.0 (4.1.93.Final) through 9.9.0
+(4.1.114.Final), arriving as a transitive runtime dependency of <code>io.grpc:grpc-netty</code>, used only
+by the optional <strong>opentelemetry</strong> module's OTLP gRPC trace exporter. Solr 9.10.0 onward already
+ships Netty 4.2.6.Final or later — outside the affected range — so no currently released Solr
+version bundles a vulnerable <code>netty-handler</code>. Solr is <strong>not affected</strong> even on the older,
+already-released 9.3.0–9.9.0 line:</p>
+<ul>
+<li><strong>The opentelemetry module is optional and disabled by default.</strong> It must be explicitly
+ enabled (e.g. via <code>-Dsolr.modules=opentelemetry</code>) before <code>grpc-netty</code>, and therefore
+ <code>netty-handler</code>, is even loaded.</li>
+<li><strong>Netty is used only as an outbound gRPC client dialing the operator's own configured OTLP
+ collector</strong>, not as a listener accepting arbitrary inbound connections. <code>SslHandler</code>'s
+ crafted-packet validation only matters for TLS data arriving from the remote peer on that
+ connection — here, the operator-designated collector endpoint, not an attacker-facing socket.</li>
+<li><strong>Solr's own request-handling surface is Jetty, not Netty.</strong> Every attacker-facing API call
+ Solr accepts is parsed and served by Jetty; <code>io.netty</code> code is never invoked to process
+ inbound requests to Solr itself.</li>
+<li>Exploitation would additionally require the operator to have pointed OTLP export at a
+ compromised or malicious collector (or accepted an on-path attacker on that egress route) —
+ a threat model outside standard use of this optional telemetry feature.</li>
+</ul>
+<p>No released Solr version ships a fix for this specific line, because none currently needs one:
+9.10.0+ already carries a post-fix Netty. The <code>branch_9x</code> (→ 9.11.0) and <code>main</code>/<code>branch_10x</code>
+(→ 10.x) development branches have since moved further still, to Netty 4.2.15.Final and
+4.2.17.Final respectively — picked up incidentally through routine dependency updates rather
+than a targeted SOLR-17826 fix commit. SOLR-17826 remains open upstream and should be closed
+out to reflect that no supported or in-development Solr line is exposed.</p>
+
+ <h4>References</h4>
+ <ul>
+ <li>JIRA: <a href="https://issues.apache.org/jira/browse/SOLR-17826">SOLR-17826</a></li>
+ <li>CVE: <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-24970">CVE-2025-24970</a></li>
+ </ul>
+ </article>
<article id="cve-2025-12183" class="post panel radius">
<header class="post-header">
<h3 class="title"><a href="https://nvd.nist.gov/vuln/detail/CVE-2025-12183">CVE-2025-12183</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-66566">CVE-2025-66566</a>, lz4-java: out-of-bounds memory access and insufficient buffer clearing in compression/decompression</h3>