SOLR-18333: Split bundled 2026 jackson-databind VEX entry into per-CVE files with accurate ranges

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

@@ -1,38 +1,26 @@
 ---
-cve:
-  - CVE-2026-50193
-  - CVE-2026-54514
-  - CVE-2026-54515
-  - CVE-2026-59889
-  - CVE-2026-59888
-  - CVE-2026-54518
-  - GHSA-mhm7-754m-9p8w
+cve: CVE-2026-50193
 category:
   - solr/vex
-versions: "4.7.0-10.0.0"
+versions: "9.0.0-9.1.1"
 jars:
-  - jackson-databind-2.12.7.1.jar
+  - jackson-databind-2.13.4.2.jar
 analysis:
   state: not_affected
   justification: code_not_reachable
-title: "jackson-databind: nested-toString DoS, InetSocketAddress SSRF, and deserialization-filter bypasses"
+title: "jackson-databind: StackOverflowError calling toString() on a deeply-nested JsonNode"
 ---
-Four jackson-databind issues, in two groups:
+CVE-2026-50193 is a denial-of-service issue in jackson-databind: calling `toString()` on a
+deeply-nested `JsonNode` recurses until it throws a `StackOverflowError`. It affects jackson-databind
+before 2.14.0 (fixed in 2.14.0), and is reachable only when an application builds a `JsonNode` tree
+from attacker-controlled JSON and then calls `toString()` on it.
 
-* **Only the Hadoop-shaded old copy is affected.** CVE-2026-50193 (StackOverflow on `toString()` of a
-  deeply-nested `JsonNode`, fixed 2.14.0) and CVE-2026-54514 (eager DNS resolution / SSRF when
-  deserializing into `InetSocketAddress`, fixed 2.18.8 / 2.21.4) do not affect Solr's own
-  jackson-databind (2.18.0 in current 9.x, 2.22.0 in 9.11 — both patched). The `2.12.7.1` a scanner
-  flags is Hadoop's shaded copy, reachable only through the optional Hadoop modules, which process
-  administrator-supplied configuration rather than untrusted external JSON.
-* **Require Jackson features Solr does not use.** CVE-2026-54515 (case-insensitive deserialization
-  bypassing per-property `@JsonIgnoreProperties`), CVE-2026-59889 (`@JsonView` bypass for
-  `@JsonUnwrapped` container properties), CVE-2026-59888 (`@JsonIgnore` on a Record property bypassed
-  via a `PropertyNamingStrategy`), GHSA-mhm7-754m-9p8w (`@JsonView` bypass for creator properties
-  with `@JsonTypeInfo(include = As.EXTERNAL_PROPERTY)`), and CVE-2026-54518 (`@JsonView` bypass for
-  unwrapped creator parameters) can reach Solr's own jackson-databind, but
-  only when an application relies on those annotation-based mechanisms — case-insensitive property
-  mapping, `@JsonView`, `@JsonUnwrapped`, `@JsonIgnore` on records, or `@JsonTypeInfo` external-property
-  polymorphism — to restrict which fields untrusted input may set. Solr uses none of them: it maps
-  request JSON to fixed, known types and never applies `@JsonView`/`@JsonIgnore`-based deserialization
-  filtering or polymorphic typing to untrusted input, so these bypasses have nothing to bypass.
+Solr is **not affected**. Solr does not call `toString()` on an untrusted, attacker-nested `JsonNode`
+as part of any request path.
+
+Solr's own standalone `jackson-databind` is below 2.14.0 only in 9.0.0 – 9.1.1 (2.13.2.2 / 2.13.3 /
+2.13.4.2); from 9.2.0 onward it ships 2.14.2 or later (up to 2.20.0 in 10.0.0), all past the fix, so
+those releases are not affected. Note the old `2.12.7.1` copy shaded inside `hadoop-client-runtime`
+(optional `hdfs` module) is also below 2.14.0 and is present across the wider 9.x line, but that
+shaded purl is a separate scanner/generator concern tracked with the other Hadoop-shaded dependencies
+(SOLR-17900); this statement covers Solr's standalone jackson-databind.

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

@@ -0,0 +1,28 @@
+---
+cve: CVE-2026-54514
+category:
+  - solr/vex
+versions: "9.0.0-9.10.1, 10.0.0"
+jars:
+  - jackson-databind-2.18.0.jar
+analysis:
+  state: not_affected
+  justification: code_not_reachable
+title: "jackson-databind: SSRF via eager DNS resolution deserializing into InetSocketAddress"
+---
+CVE-2026-54514 is a server-side request forgery (SSRF) issue in jackson-databind:
+`JDKFromStringDeserializer` builds an `InetSocketAddress` with `new InetSocketAddress(host, port)`,
+which performs eager DNS name resolution. Deserializing attacker-controlled JSON into an
+`InetSocketAddress` therefore triggers a DNS lookup of an attacker-chosen name. It affects
+jackson-databind 2.0.0 – 2.18.7 and 2.19.0 – 2.21.3 (fixed in 2.18.8 / 2.21.4).
+
+Solr is **not affected**. Solr deserializes request JSON into fixed, known types and never binds
+untrusted input to a `java.net.InetSocketAddress` (or a field that would trigger this deserializer),
+so the eager-resolution path is never driven by attacker-controlled data.
+
+Solr shipped an in-range `jackson-databind` from 9.0.0 through 9.10.1 (2.13.2.2 → 2.18.0, all
+< 2.18.8) and in 10.0.0 (2.20.0, within 2.19.0 – 2.21.3). Solr 9.11 upgrades to 2.22.0 (past the
+2.21.4 fix) and is not affected. The old `2.12.7.1` copy shaded inside `hadoop-client-runtime` (in the
+optional `hdfs` module across the 9.x line) is likewise below the fix, but its shaded purl is a
+separate scanner/generator concern tracked with the other Hadoop-shaded dependencies (SOLR-17900);
+either way Solr does not route untrusted JSON into `InetSocketAddress` deserialization.

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

@@ -0,0 +1,29 @@
+---
+cve: CVE-2026-54515
+category:
+  - solr/vex
+versions: "9.0.0-9.10.1, 10.0.0"
+jars:
+  - jackson-databind-2.18.0.jar
+analysis:
+  state: not_affected
+  justification: requires_configuration
+title: "jackson-databind: case-insensitive deserialization bypasses per-property @JsonIgnoreProperties"
+---
+CVE-2026-54515 is a deserialization-filter bypass in jackson-databind: when case-insensitive property
+matching (`MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES`) is enabled together with per-property
+`@JsonIgnoreProperties`, a property meant to be ignored can still be set from untrusted JSON using a
+different-case name (a mass-assignment-style write). It affects jackson-databind 2.8.0 – 2.18.8,
+2.19.0 – 2.21.4, and 2.22.0 (fixed in 2.18.9 / 2.21.5 / 2.22.1).
+
+Solr is **not affected**. Exploiting this requires an application to rely on case-insensitive matching
+plus per-property `@JsonIgnoreProperties` to restrict which fields untrusted input may set. Solr does
+neither: it maps request JSON to fixed, known types and does not use `@JsonIgnoreProperties`-based
+filtering (nor case-insensitive property mapping) as a security boundary on untrusted input, so there
+is nothing for the bypass to defeat.
+
+Solr shipped an in-range `jackson-databind` from 9.0.0 through 9.10.1 (2.13.2.2 → 2.18.0) and in
+10.0.0 (2.20.0). Solr 9.11 ships 2.22.0, which is also affected (fixed in 2.22.1) — it should be added
+to this range once released. The old `2.12.7.1` copy shaded inside `hadoop-client-runtime` (optional
+`hdfs` module) is also in range, but its shaded purl is a separate scanner/generator concern tracked
+with the other Hadoop-shaded dependencies (SOLR-17900).

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

@@ -0,0 +1,27 @@
+---
+cve: CVE-2026-59888
+category:
+  - solr/vex
+versions: "9.3.0-9.10.1, 10.0.0"
+jars:
+  - jackson-databind-2.18.0.jar
+analysis:
+  state: not_affected
+  justification: requires_configuration
+title: "jackson-databind: @JsonIgnore on a Record property bypassed via a PropertyNamingStrategy"
+---
+CVE-2026-59888 is a deserialization-filter bypass in jackson-databind: `@JsonIgnore` on a Record
+property can be bypassed when a `PropertyNamingStrategy` is in effect, because
+`POJOPropertiesCollector._removeUnwantedIgnorals()` records the ignored component under its original
+implicit name before `_renameUsing()` applies the naming strategy — so the renamed property is no
+longer recognised as ignored and can be set from untrusted JSON. It affects jackson-databind
+2.15.0 – 2.18.7 and 2.19.0 – 2.21.3 (fixed in 2.18.8 / 2.21.4).
+
+Solr is **not affected**. Exploiting this requires an application to deserialize untrusted JSON into
+Java Records that use `@JsonIgnore` together with a `PropertyNamingStrategy` to keep a field
+unwritable. Solr does not rely on that mechanism to filter untrusted input, so the bypass has nothing
+to defeat.
+
+Solr shipped an in-range `jackson-databind` from 9.3.0 through 9.10.1 (2.15.2 → 2.18.0) and in 10.0.0
+(2.20.0). Earlier 9.x (≤ 9.2.x, jackson-databind ≤ 2.14.2) and Solr 9.11 (2.22.0) are past/below the
+affected ranges and are not affected.

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

@@ -0,0 +1,25 @@
+---
+cve: CVE-2026-59889
+category:
+  - solr/vex
+versions: "9.8.0-9.10.1"
+jars:
+  - jackson-databind-2.18.0.jar
+analysis:
+  state: not_affected
+  justification: requires_configuration
+title: "jackson-databind: @JsonView bypass for @JsonUnwrapped container properties"
+---
+CVE-2026-59889 is a deserialization-filter bypass in jackson-databind: a `@JsonView` restriction can
+be bypassed for the properties of a `@JsonUnwrapped` container, letting untrusted JSON set fields that
+the active view was meant to exclude. It affects jackson-databind 2.18.0 – 2.18.8, 2.21.0 – 2.21.4,
+and 2.22.0 (fixed in 2.18.9 / 2.21.5 / 2.22.1).
+
+Solr is **not affected**. Exploiting this requires an application to use `@JsonView`-based
+deserialization filtering over `@JsonUnwrapped` container properties to restrict which fields
+untrusted input may set. Solr applies no `@JsonView` filtering to request deserialization, so there
+is nothing for the bypass to defeat.
+
+Solr's own standalone `jackson-databind` is in an affected range only in 9.8.0 – 9.10.1 (2.18.0).
+Solr 10.0.0 ships 2.20.0, which is outside the affected ranges and is not affected. Solr 9.11 ships
+2.22.0, which *is* affected (fixed in 2.22.1) and should be added to this range once released.

content/solr/vex/2026-07-31-ghsa-mhm7-754m-9p8w.md

@@ -0,0 +1,27 @@
+---
+cve: GHSA-mhm7-754m-9p8w
+category:
+  - solr/vex
+versions: "9.8.0-9.10.1"
+jars:
+  - jackson-databind-2.18.0.jar
+analysis:
+  state: not_affected
+  justification: requires_configuration
+title: "jackson-databind: @JsonView bypass for creator properties with @JsonTypeInfo external-property polymorphism"
+---
+GHSA-mhm7-754m-9p8w is a deserialization-filter bypass in jackson-databind: a `@JsonView` restriction
+can be bypassed for creator properties that use `@JsonTypeInfo(include = As.EXTERNAL_PROPERTY)`
+polymorphic typing, letting untrusted JSON populate fields the active view was meant to exclude. It
+affects jackson-databind 2.18.0 – 2.18.8 and 2.21.0 – 2.21.4 (fixed in 2.18.9 / 2.21.5); the
+external-type-id creator path was fixed on the 3.x line and not backported to the 2.19/2.20 lines,
+which are not affected.
+
+Solr is **not affected**. Exploiting this requires an application to combine `@JsonView` filtering
+with `@JsonTypeInfo` external-property polymorphic typing on untrusted input. Solr applies neither
+`@JsonView` filtering nor polymorphic type handling to request deserialization (see also the
+long-standing polymorphic-typing analysis in the jackson-databind gadget statement), so the bypass has
+nothing to defeat.
+
+Solr's own standalone `jackson-databind` is in an affected range only in 9.8.0 – 9.10.1 (2.18.0).
+Solr 10.0.0 (2.20.0) and Solr 9.11 (2.22.0) are outside the affected ranges and are not affected.