SOLR-18013: Split lz4-java CVEs by fix boundary and emit a matchable org.lz4 purl

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.

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.

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",