From bb6759e54df706e9c9baf900c88f738dea094a3d Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Thu, 13 Aug 2026 08:00:28 -0400 Subject: [PATCH] Split bundled 2026 jackson-databind VEX entry into per-CVE files with accurate ranges The single 2026-50193 entry bundled six issues under one range (4.7.0-10.0.0) and one justification, but they have genuinely different affected-version ranges and rationales. Split into one file per CVE, each scoped to the Solr releases whose own standalone jackson-databind is actually in that CVE's range (so the generator emits only in-range purls): - CVE-2026-54514 (SSRF) -> 9.0.0-9.10.1, 10.0.0 (code_not_reachable) - CVE-2026-54515 (case-insensitive)-> 9.0.0-9.10.1, 10.0.0 (requires_configuration) - CVE-2026-50193 (toString DoS) -> 9.0.0-9.1.1 (code_not_reachable) - CVE-2026-59888 (Record JsonIgnore)-> 9.3.0-9.10.1, 10.0.0 (requires_configuration) - CVE-2026-59889 (JsonView) -> 9.8.0-9.10.1 (requires_configuration) - GHSA-mhm7-754m-9p8w (ext-type-id)-> 9.8.0-9.10.1 (requires_configuration) Disposition stays not_affected. The prior entry also mis-stated that the SSRF did not affect Solr's own jackson-databind; it does (2.18.0 in 9.x, 2.20.0 in 10.0.0), only patched in 9.11 (2.22.0) - now corrected. The hadoop-client-runtime shaded 2.12.7.1 copy cannot be emitted by the generator (same shaded-purl gap as SOLR-17900) and is noted as a separate follow-up in each body. Co-Authored-By: Claude Opus 4.8 --- content/solr/vex/2026-07-31-cve-2026-50193.md | 46 +++++++------------ content/solr/vex/2026-07-31-cve-2026-54514.md | 28 +++++++++++ content/solr/vex/2026-07-31-cve-2026-54515.md | 29 ++++++++++++ content/solr/vex/2026-07-31-cve-2026-59888.md | 27 +++++++++++ content/solr/vex/2026-07-31-cve-2026-59889.md | 25 ++++++++++ .../vex/2026-07-31-ghsa-mhm7-754m-9p8w.md | 27 +++++++++++ 6 files changed, 153 insertions(+), 29 deletions(-) create mode 100644 content/solr/vex/2026-07-31-cve-2026-54514.md create mode 100644 content/solr/vex/2026-07-31-cve-2026-54515.md create mode 100644 content/solr/vex/2026-07-31-cve-2026-59888.md create mode 100644 content/solr/vex/2026-07-31-cve-2026-59889.md create mode 100644 content/solr/vex/2026-07-31-ghsa-mhm7-754m-9p8w.md diff --git a/content/solr/vex/2026-07-31-cve-2026-50193.md b/content/solr/vex/2026-07-31-cve-2026-50193.md index 4477ca2cf..5cf9554db 100644 --- a/content/solr/vex/2026-07-31-cve-2026-50193.md +++ b/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. diff --git a/content/solr/vex/2026-07-31-cve-2026-54514.md b/content/solr/vex/2026-07-31-cve-2026-54514.md new file mode 100644 index 000000000..d1784a804 --- /dev/null +++ b/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. diff --git a/content/solr/vex/2026-07-31-cve-2026-54515.md b/content/solr/vex/2026-07-31-cve-2026-54515.md new file mode 100644 index 000000000..cf6b7ef36 --- /dev/null +++ b/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). diff --git a/content/solr/vex/2026-07-31-cve-2026-59888.md b/content/solr/vex/2026-07-31-cve-2026-59888.md new file mode 100644 index 000000000..d5fd67448 --- /dev/null +++ b/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. diff --git a/content/solr/vex/2026-07-31-cve-2026-59889.md b/content/solr/vex/2026-07-31-cve-2026-59889.md new file mode 100644 index 000000000..49203555e --- /dev/null +++ b/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. diff --git a/content/solr/vex/2026-07-31-ghsa-mhm7-754m-9p8w.md b/content/solr/vex/2026-07-31-ghsa-mhm7-754m-9p8w.md new file mode 100644 index 000000000..328742871 --- /dev/null +++ b/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.