From 1034b61a29ef085f93c96964bf14b47853b6d92d Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Thu, 13 Aug 2026 10:07:11 -0400 Subject: [PATCH] Split lz4-java CVEs by fix boundary; emit real org.lz4 purl The three lz4-java CVEs were bundled in one entry, but CVE-2026-59949 has a different fix boundary than the SOLR-18013 pair: - CVE-2025-12183 (fix 1.8.1) + CVE-2025-66566 (fix 1.10.1): fixed by the branch_9x/branch_10x/main migration to the fork at.yawk.lz4:lz4-java 1.10.1, so the upcoming 9.11/10.1 are not affected. -> own file, 9.8.0-10.0.0. - CVE-2026-59949 (fix 1.11.1): NOT fixed by the 1.10.1 fork bump; all three dev branches are still on 1.10.1, so 9.11/10.1 will remain affected. -> stays in its own file, range will extend once those release. Also add org.lz4:lz4-java to the dependency map (9.8.0-10.0.0 -> 1.8.0) so these statements emit a matchable pkg:maven/org.lz4/lz4-java@1.8.0 purl instead of a bare, unmatchable id. Disposition unchanged (not_affected; lz4-java is reachable only via the optional cross-dc Kafka client, not from untrusted input). Co-Authored-By: Claude Opus 4.8 --- content/solr/vex/2026-07-31-cve-2026-59949.md | 47 ++++++++----------- content/solr/vex/2026-08-13-cve-2025-12183.md | 39 +++++++++++++++ plugins/vex/solr-dependency-versions.json | 8 ++++ 3 files changed, 67 insertions(+), 27 deletions(-) create mode 100644 content/solr/vex/2026-08-13-cve-2025-12183.md diff --git a/content/solr/vex/2026-07-31-cve-2026-59949.md b/content/solr/vex/2026-07-31-cve-2026-59949.md index b45e8b01f..99f78089f 100644 --- a/content/solr/vex/2026-07-31-cve-2026-59949.md +++ b/content/solr/vex/2026-07-31-cve-2026-59949.md @@ -1,8 +1,5 @@ --- -cve: - - CVE-2026-59949 - - CVE-2025-12183 - - CVE-2025-66566 +cve: CVE-2026-59949 jira: SOLR-18013 category: - solr/vex @@ -12,29 +9,25 @@ jars: analysis: state: not_affected justification: code_not_reachable -title: "lz4-java: out-of-bounds access and buffer-reuse disclosure in (de)compression" +title: "lz4-java: out-of-bounds read via invalid arguments to native XXHash" --- -Three issues in the `at.yawk.lz4:lz4-java` codec (the community-maintained fork of the discontinued -lz4-java): +CVE-2026-59949 (CVSS 6.5) is an out-of-bounds read in the `lz4-java` codec: the JNI-based XXHash +implementations insufficiently validate their byte-array arguments, so a caller that passes an +invalid array reference or an out-of-range `off`/`len` to the native XXHash methods can crash the JVM. +It affects `lz4-java` ≤ 1.11.0 (fixed in 1.11.1). Exploitation requires an application to pass +attacker-influenced array/offset/length values into those XXHash APIs. -* **CVE-2026-59949** (CVSS 6.5) — out-of-bounds read: the JNI-based XXHash implementations don't - validate their byte-array arguments, so a caller passing an invalid array reference or out-of-range - `off`/`len` can crash the JVM (fixed in 1.11.1). -* **CVE-2025-12183** — out-of-bounds memory access in the compression/decompression functions, - leading to denial of service and possible information disclosure when processing untrusted input - (fixed in 1.8.1). -* **CVE-2025-66566** — the Java decompressor does not clear reused output buffers, so crafted - compressed input can read previous buffer contents when an output buffer is reused (fixed in - 1.10.1). +Solr is **not affected**. `lz4-java` is bundled only by the optional `cross-dc` module, where it is +used by the embedded Apache Kafka client for LZ4 compression / checksums of cross-datacenter +replication messages. Kafka calls the XXHash APIs with its own internally-managed, validated buffers +and offsets — it does not forward attacker-controlled `off`/`len` values into the native methods — and +the replication stream flows through an operator-controlled Kafka pipeline, not untrusted external +input. The `cross-dc` module is not part of a default Solr installation, and no Solr request path +reaches the vulnerable XXHash argument handling. -All three affect the `lz4-java` 1.8.0 that Solr's released 9.8.0 – 10.0.0 line bundles (SOLR-18013 -tracks the upgrade to 1.10.1). Each is reachable only when an application feeds attacker-controlled -input to the codec, or passes attacker-influenced arguments into it. - -Solr is **not affected**. `lz4-java` is bundled only by the optional `cross-dc` module, where the -embedded Apache Kafka client uses it to (de)compress and checksum cross-datacenter replication -messages. Those messages flow through an **operator-controlled** Kafka pipeline (Solr's own cross-DC -producer → the operator's Kafka → Solr's consumer), not untrusted external input, and Kafka calls the -codec with its own internally-managed, validated buffers and offsets rather than forwarding -attacker-controlled arguments. The `cross-dc` module is not part of a default Solr installation, and -no Solr request path reaches the vulnerable compression/decompression or XXHash code. +Solr shipped an affected `org.lz4:lz4-java` 1.8.0 from 9.8.0 (when the `cross-dc` module first bundled +it) through 10.0.0. Unlike CVE-2025-12183 / CVE-2025-66566 (covered separately and fixed by the +`branch_9x` / `branch_10x` / `main` migration to the fork `at.yawk.lz4:lz4-java` 1.10.1), **this issue +is not yet fixed on any branch**: 1.11.1 is required, and all three development branches are on 1.10.1, +so the upcoming 9.11 and 10.1 releases will still bundle an affected version. The affected Solr range +will need to extend to those releases once they ship. diff --git a/content/solr/vex/2026-08-13-cve-2025-12183.md b/content/solr/vex/2026-08-13-cve-2025-12183.md new file mode 100644 index 000000000..2d04721d8 --- /dev/null +++ b/content/solr/vex/2026-08-13-cve-2025-12183.md @@ -0,0 +1,39 @@ +--- +cve: + - CVE-2025-12183 + - CVE-2025-66566 +jira: SOLR-18013 +category: + - solr/vex +versions: "9.8.0-10.0.0" +jars: + - lz4-java-1.8.0.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "lz4-java: out-of-bounds memory access and insufficient buffer clearing in compression/decompression" +--- +Two issues in the `lz4-java` codec: + +* **CVE-2025-12183** — several lz4-java compression/decompression implementations do not guard against + out-of-bounds memory access (fixed in `lz4-java` 1.8.1). +* **CVE-2025-66566** — decompressor implementations insufficiently clear their buffers, allowing a + caller to read leftover contents of a previously used buffer (fixed in `lz4-java` 1.10.1). + +Both require an application to drive lz4-java's (de)compression APIs with attacker-influenced +input/buffers. + +Solr is **not affected**. `lz4-java` is bundled only by the optional `cross-dc` module, where it is +used by the embedded Apache Kafka client for LZ4 compression of cross-datacenter replication messages. +Kafka manages its own internal, validated buffers and does not forward attacker-controlled data into +the vulnerable code paths, and the replication stream flows through an operator-controlled Kafka +pipeline rather than untrusted external input. The `cross-dc` module is not part of a default Solr +installation, and no Solr request path reaches these lz4-java routines. + +Solr shipped an affected `org.lz4:lz4-java` 1.8.0 from 9.8.0 (when the `cross-dc` module first bundled +it) through 10.0.0; releases 9.7.0 and earlier, and the 8.x line, ship no `lz4-java`. The fix is +already on all active development branches: `branch_9x`, `branch_10x`, and `main` migrated to the +maintained community fork `at.yawk.lz4:lz4-java` 1.10.1, which is past both fixes (1.8.1 and 1.10.1), +so the next releases (9.11, 10.1) will not be affected. Note this upgrade did not require Apache Kafka +to update first — Kafka still declares the old `org.lz4:lz4-java`, and Solr replaced that transitive +dependency with the fork directly. diff --git a/plugins/vex/solr-dependency-versions.json b/plugins/vex/solr-dependency-versions.json index 334d4bb8c..42c5c4c40 100644 --- a/plugins/vex/solr-dependency-versions.json +++ b/plugins/vex/solr-dependency-versions.json @@ -2918,6 +2918,14 @@ "9.8.1": "2.0.6.1", "9.9.0": "2.0.6.1" }, + "org.lz4:lz4-java": { + "10.0.0": "1.8.0", + "9.10.0": "1.8.0", + "9.10.1": "1.8.0", + "9.8.0": "1.8.0", + "9.8.1": "1.8.0", + "9.9.0": "1.8.0" + }, "org.restlet.jee:org.restlet": { "4.10.0": "2.1.1", "4.10.1": "2.1.1",