From 10a4b4d9fb036de4ec39c3992334fc594453c22f Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Mon, 21 Sep 2026 17:43:13 -0700 Subject: [PATCH] based on some questions, i looked again and refined these two CVE statements --- content/solr/vex/2026-07-31-cve-2026-45205.md | 10 +++++-- content/solr/vex/2026-07-31-cve-2026-46718.md | 27 ++++++++++++++----- 2 files changed, 28 insertions(+), 9 deletions(-) diff --git a/content/solr/vex/2026-07-31-cve-2026-45205.md b/content/solr/vex/2026-07-31-cve-2026-45205.md index e995a97ab..9f4d1d723 100644 --- a/content/solr/vex/2026-07-31-cve-2026-45205.md +++ b/content/solr/vex/2026-07-31-cve-2026-45205.md @@ -2,9 +2,9 @@ cve: CVE-2026-45205 category: - solr/vex -versions: "9.0.0-10.0.0" +versions: "9.0.0-9.10.1" jars: - - commons-configuration2-2.10.1.jar + - commons-configuration2-2.12.0.jar analysis: state: not_affected justification: code_not_reachable @@ -18,3 +18,9 @@ Hadoop integration (Kerberos / HDFS support), to load **administrator-supplied** files — not untrusted, externally-supplied YAML. No Solr request path feeds attacker-controlled YAML to Commons Configuration, so the cyclic-YAML parser cannot be driven by an adversary. (This matches the existing assessment of the other Commons Configuration CVEs in Solr.) + +The affected range is 9.0.0 – 9.10.1: every release in that span ships a vulnerable +`commons-configuration2` (2.8.0 through 2.12.0, all below the 2.15.0 fix) via the optional +`hadoop-auth`/`hdfs` modules. Solr 10.0.0 removed the Hadoop integration entirely (SOLR-17540, +SOLR-17609) and ships no `commons-configuration2` at all, so 10.x is not affected for the additional +reason that the dependency isn't present. diff --git a/content/solr/vex/2026-07-31-cve-2026-46718.md b/content/solr/vex/2026-07-31-cve-2026-46718.md index be4c58f09..2bde8f4a9 100644 --- a/content/solr/vex/2026-07-31-cve-2026-46718.md +++ b/content/solr/vex/2026-07-31-cve-2026-46718.md @@ -6,8 +6,10 @@ versions: "9.0.0-10.0.0" jars: - calcite-core-1.37.0.jar analysis: - state: not_affected - justification: code_not_reachable + state: exploitable + response: + - workaround_available + - update title: "Apache Calcite: arbitrary class loading via a user-controlled model" --- CVE-2026-46718 lets a **user-controlled Calcite model** load arbitrary classes, leading to code @@ -15,8 +17,19 @@ execution (affects calcite-core 1.5.0 – 1.41.x, fixed in 1.42.0). Exploitation application to let an attacker supply the Calcite *model* (the JSON schema/model definition that can name factory classes). -Solr is **not affected**. Calcite is used only by the optional `sql` module (Parallel SQL, the `/sql` -handler). Solr constructs the Calcite schema/model **server-side** from the target collection; users -submit only a SQL statement, never a Calcite model or schema-factory definition. There is no request -path through which an attacker can supply a Calcite model, so the arbitrary-class-loading vector is -never reached. +Solr **is affected** when the optional `sql` module (Parallel SQL, the `/sql` handler) is loaded. +`SQLHandler` forwards every `/sql` request parameter, unfiltered, into the JDBC connection properties +used to open the Calcite connection — including a `model` parameter, if a caller sends one. Those +properties reach Calcite's own `Driver.connect()` unmodified, which is exactly where the vulnerable +model-loading happens. Nothing in Solr limits which parameters get forwarded, so any caller who can +reach `/sql` (only `READ` permission on the collection is required) can trigger it directly, without +needing another proxy or app in front of Solr. + +A fix — an allowlist that restricts which parameters `SQLHandler` forwards to Calcite, together with +the Calcite 1.42.0 upgrade — is in progress upstream but has not shipped in a Solr release yet. + +**Workaround**: don't load the `sql` module (no `SOLR_MODULES=sql`, no `` reference to +`modules/sql/lib`) unless Parallel SQL / Streaming Expressions over SQL are actually in use — `/sql` is +registered as an implicit handler on every collection automatically as soon as the module is enabled. +Where the module is required, restrict `/sql` to trusted, authenticated callers via Solr's +authorization plugin.