🟢CVE-2026-59949

Overview

This advisory addresses a known security vulnerability identified in a third-party dependency used within DPGW.

Vulnerability Details

  • CVE ID: CVE-2026-59949 (GitHub advisory GHSA-xx22-p4ch-683r; insufficient validation of byte array arguments at a JNI boundary)
  • Dependency Name: at.yawk.lz4:lz4-java (1.12 / 1.13 / 1.14 branches)
  • Affected Version of Dependency: at.yawk.lz4:lz4-java <= 1.11.0 — fixed in 1.11.1 (released 2026-07-06)
  • Severity Score: 6.5 Medium (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H)

Affected Versions of DPGW

All maintained branches bundle a vulnerable version of the library:

  • 1.12 — all releases (<= 1.12.53-REL), bundles at.yawk.lz4:lz4-java 1.11.0
  • 1.13 — all releases (<= 1.13.30-REL), bundles at.yawk.lz4:lz4-java 1.11.0
  • 1.14 — all releases (<= 1.14.08-REL), bundles at.yawk.lz4:lz4-java 1.11.0

Risk Assessment & Applicability

Usage
DPGW declares lz4-java as a direct dependency and uses it exclusively for XXHash64 hashing — the LZ4 compression/decompression API (LZ4Factory, net.jpountz.lz4.*) is not referenced anywhere in the codebase, and dependency:tree confirms the artifact is not pulled in transitively by any other component.

XXHash64 is used at the following call sites:

  • org.medoro.dpgw.base.pub.hash.XXHash64InputStream / XXHash64OutputStream — checksum streams (java.util.zip.CheckedInputStream/CheckedOutputStream subclasses) used by the storage module (HashAlgorithm.XXH64) to compute content hashes of stored objects while they are read/written.
  • org.medoro.dpgw.digi.HashUtils.xxh64(Path) — hashes a file from disk with a fixed 64 KiB buffer.
  • org.medoro.dpgw.core.db.DB.calculateLiquibaseHash() — hashes bundled Liquibase changelog resources at startup with a fixed 8 KiB buffer.
  • org.medoro.lib.utils.LogHashUtils, NaturalMapHasher, ShareLinksAPIImpl — obtain the hasher via XXHashFactory.fastestJavaInstance().

The first three obtain the hasher via XXHashFactory.fastestInstance(), which selects the JNI/native implementation where available, so the vulnerable code path is present in the build. The remaining three use fastestJavaInstance() (pure-Java implementation), which does not cross the JNI boundary at all.

Analysis
CVE-2026-59949 is a missing-argument-validation defect in lz4-java’s JNI-based XXHash implementations. The native hash(...) / update(...) entry points do not validate the byte array reference or the off/len range before handing them to native code, allowing two failure modes:

  • Null array: hash(null, 0, 0, seed) or update(null, 0, 0) reaches GetPrimitiveArrayCritical with a null reference, producing a fatal JVM crash.
  • Out-of-bounds range: a call such as update(new byte[16], 0, Integer.MAX_VALUE) lets native code read far past the end of the Java array, again crashing the JVM.

The impact is denial of service through abrupt JVM termination (A:H), with a limited confidentiality component (C:L) from the out-of-bounds read. Critically, exploitation requires the attacker to influence the array object, offset, or length arguments passed to the native API. The upstream advisory states explicitly that normal usage patterns, where only the contents of the array are attacker-controlled, are not affected.

DPGW’s usage falls entirely into that unaffected pattern:

  • Every native call site passes a locally allocated, fixed-size buffer with the range (buf, 0, read), where read is the return value of InputStream.read(buf) — by contract non-negative and never greater than buf.length. The array reference is never null and never externally supplied.
  • The two checksum streams delegate through java.util.zip.CheckedInputStream/CheckedOutputStream. In CheckedInputStream.read(b, off, len) the range is validated by the underlying stream’s read before Checksum.update is invoked; in CheckedOutputStream.write(b, off, len) the wrapped OutputStream.write is called first and rejects an invalid range before the checksum update is reached. In both cases the offset/length originate from DPGW’s internal copy loops, not from remote input.
  • Attacker-supplied data (DICOM objects, uploaded documents) only ever reaches the hasher as array contents, never as an array reference, offset, or length.

There is therefore no path by which a remote or local actor can steer the offset, length, or array reference reaching the native XXHash entry points.

Status
Not affected

Impact on DPGW

No impact. The vulnerable JNI argument-validation gap can only be triggered by a caller that supplies a null array or an out-of-range off/len pair. All DPGW call sites pass internally allocated buffers with ranges derived from InputStream.read return values, so the crash condition cannot be reached — including on the 1.11 branch, where the abandoned org.lz4:lz4-java 1.8.0 artifact has no upstream fix.

Remediation & Mitigations

Scheduled fix
Although DPGW is not affected, the vulnerable dependency version will be cleared from the builds as hygiene:
– 1.14 / 1.13 / 1.12 — bump at.yawk.lz4:lz4-java 1.11.0 → 1.11.1 in the next routine release of each branch.

User Actions
No user action required.