based on some questions "from in the wild" on CVE-2026-46718, i looked again and refined these two CVE statements

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.

content/solr/vex/2026-07-31-cve-2026-46718.md

@@ -6,17 +6,30 @@ 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
 execution (affects calcite-core 1.5.0 – 1.41.x, fixed in 1.42.0). Exploitation requires the
 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 `<lib>` 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.