From e1a3c51c8307dd0928ee4e4f1d76cb0b03208edc Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Tue, 25 Aug 2026 13:21:08 -0400 Subject: [PATCH] add additonal cves that github flags. --- content/solr/vex/2026-08-25-cve-2026-48779.md | 33 +++++++++++++++++++ content/solr/vex/2026-08-25-cve-2026-54399.md | 30 +++++++++++++++++ content/solr/vex/2026-08-25-cve-2026-54428.md | 31 +++++++++++++++++ content/solr/vex/2026-08-25-cve-2026-64607.md | 33 +++++++++++++++++++ 4 files changed, 127 insertions(+) create mode 100644 content/solr/vex/2026-08-25-cve-2026-48779.md create mode 100644 content/solr/vex/2026-08-25-cve-2026-54399.md create mode 100644 content/solr/vex/2026-08-25-cve-2026-54428.md create mode 100644 content/solr/vex/2026-08-25-cve-2026-64607.md diff --git a/content/solr/vex/2026-08-25-cve-2026-48779.md b/content/solr/vex/2026-08-25-cve-2026-48779.md new file mode 100644 index 000000000..d70ed6f68 --- /dev/null +++ b/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. diff --git a/content/solr/vex/2026-08-25-cve-2026-54399.md b/content/solr/vex/2026-08-25-cve-2026-54399.md new file mode 100644 index 000000000..16db8cf30 --- /dev/null +++ b/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. diff --git a/content/solr/vex/2026-08-25-cve-2026-54428.md b/content/solr/vex/2026-08-25-cve-2026-54428.md new file mode 100644 index 000000000..e560042cc --- /dev/null +++ b/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. diff --git a/content/solr/vex/2026-08-25-cve-2026-64607.md b/content/solr/vex/2026-08-25-cve-2026-64607.md new file mode 100644 index 000000000..2bc785151 --- /dev/null +++ b/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.