add additonal cves that github flags.

content/solr/vex/2026-08-25-cve-2026-48779.md

@@ -0,0 +1,33 @@
+---
+cve: CVE-2026-48779
+category:
+  - solr/vex
+versions: "10.0.0"
+jars:
+  - ws-8.18.0.tgz
+analysis:
+  state: not_affected
+  justification: code_not_present
+title: "ws: memory exhaustion denial of service from tiny WebSocket fragments"
+---
+CVE-2026-48779 is a memory-exhaustion denial-of-service issue in the Node.js `ws` 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 `ws` 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).
+
+Solr is **not affected**. `ws` is pinned in `kotlin-js-store/wasm/yarn.lock`, an auto-generated
+lockfile for the Kotlin/Wasm build toolchain that compiles the new Compose-based Admin UI
+(`solr/ui`). It is a transitive dependency of that toolchain's Node.js-based dev-server/test-runner
+tooling, not of Solr's own code. `ws` 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.
+
+`ws` has been present in `solr/ui`'s build tooling since it was first introduced (shipped in the
+10.0.0 release at `ws@8.18.0`/`ws@8.18.3`, both within the affected range). `branch_9x` 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.

content/solr/vex/2026-08-25-cve-2026-54399.md

@@ -0,0 +1,30 @@
+---
+cve: CVE-2026-54399
+category:
+  - solr/vex
+versions: "9.1.0-10.0.0"
+jars:
+  - httpcore5-5.3.5.jar
+analysis:
+  state: not_affected
+  justification: code_not_reachable
+title: "Apache HttpComponents Core: HTTP/1 header parsing memory-exhaustion denial of service"
+---
+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 `httpcore5` 5.4.2 and
+earlier (and 5.5-beta1 and earlier); fixed in 5.4.3.
+
+Solr is **not affected**. `httpcore5` is bundled transitively by
+`org.apache.calcite.avatica:avatica-core`, which uses it to support Avatica's *optional remote-JDBC*
+HTTP transport -- see the companion VEX entry for CVE-2026-64607 (`httpclient5`) for the full
+reachability analysis, which applies identically here: Solr's `/sql` handler never uses Avatica's
+remote HTTP transport, only the local embedded `CalciteConnection`, so `httpcore5`'s HTTP/1.1 message
+parser is never invoked to process any inbound message, trusted or otherwise. The dependency is
+`permitUnusedDeclared` in Solr's own build and shipped only via the optional `solr:modules:sql`
+module.
+
+Solr has shipped an affected `httpcore5` since at least 9.1.0 (through 10.0.0, and continuing on
+`branch_10x`/`main` at 5.3.5). `branch_9x` 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 `branch_10x`/`main` either.

content/solr/vex/2026-08-25-cve-2026-54428.md

@@ -0,0 +1,31 @@
+---
+cve: CVE-2026-54428
+category:
+  - solr/vex
+versions: "9.1.0-10.0.0"
+jars:
+  - httpcore5-h2-5.3.4.jar
+analysis:
+  state: not_affected
+  justification: code_not_reachable
+title: "Apache HttpComponents Core: HPACK decoder unlimited header list size before SETTINGS ACK"
+---
+CVE-2026-54428 is an allocation-without-limits issue in Apache HttpComponents Core's HTTP/2 HPACK
+decoder: before an HTTP/2 peer's `SETTINGS` 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 `httpcore5-h2` 5.4.2 and earlier (and 5.5-beta1 and
+earlier); fixed in 5.4.3.
+
+Solr is **not affected**. `httpcore5-h2` is bundled transitively by
+`org.apache.calcite.avatica:avatica-core`, which uses it to support Avatica's *optional remote-JDBC*
+HTTP/2 transport -- see the companion VEX entry for CVE-2026-64607 (`httpclient5`) for the full
+reachability analysis, which applies identically here: Solr's `/sql` handler never uses Avatica's
+remote HTTP transport, only the local embedded `CalciteConnection`, 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 `permitUnusedDeclared` in Solr's own build and shipped only via the
+optional `solr:modules:sql` module.
+
+Solr has shipped an affected `httpcore5-h2` since at least 9.1.0 (through 10.0.0, and continuing on
+`branch_10x`/`main` at 5.3.4). `branch_9x` 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 `branch_10x`/`main` either.

content/solr/vex/2026-08-25-cve-2026-64607.md

@@ -0,0 +1,33 @@
+---
+cve: CVE-2026-64607
+category:
+  - solr/vex
+versions: "9.1.0-10.0.0"
+jars:
+  - httpclient5-5.5.jar
+analysis:
+  state: not_affected
+  justification: code_not_reachable
+title: "Apache HttpComponents Client: connection leak on Content-Encoding decode error"
+---
+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 `Content-Encoding` 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 `httpclient5` from 5.0-alpha1 through 5.6.2; fixed in 5.6.3.
+
+Solr is **not affected**. `httpclient5` (along with `httpcore5` and `httpcore5-h2`, covered in
+separate VEX entries for their own CVEs) is bundled transitively by `org.apache.calcite.avatica:avatica-core`,
+which uses it to support Avatica's *optional remote-JDBC* transport -- connecting to a remote Avatica
+server over HTTP. Solr's own `/sql` handler (`CalciteSolrDriver`) only ever opens a local, in-process
+`org.apache.calcite.jdbc.CalciteConnection`; there is no `org.apache.hc.client5`/`org.apache.hc.core5`
+usage anywhere in `solr/modules/sql`'s source, and Solr never acts as an Avatica HTTP client or server.
+The dependency has in fact been marked `permitUnusedDeclared` 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 `solr:modules:sql` module -- every other
+place it appears (`solrj-streaming`, `solr-ref-guide`, `webapp`) is test-scope only, not shipped.
+
+Solr has shipped an affected `httpclient5` since at least 9.1.0 (through 10.0.0, and continuing on
+`branch_10x`/`main` at 5.5). `branch_9x` 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 `branch_10x`/`main` either.