CVE-2025-66566 fixed in lz4-java 1.10.1

[Alan Coopersmith <alan.coopersmith () oracle com>]

https://github.com/yawkat/lz4-java/security/advisories/GHSA-cmp6-m4wj-q63q
discloses:

> Java-based decompressor implementations can leak information from
> uninitialized output buffer
>
> yawkat published GHSA-cmp6-m4wj-q63q Dec 5, 2025
>
> Package                              Affected versions  Patched versions
> -------                              -----------------  ----------------
> at.yawk.lz4:lz4-java (Maven)             <= 1.10.0           1.10.1
> net.jpountz.lz4:lz4 (Maven)              <= 1.8.1            None
> org.lz4:lz4-java (Maven)                 <= 1.8.1            None
> org.lz4:lz4-pure-java (Maven)            <= 1.8.1            None
>
> Description
> ===========
>
> Summary
> -------
> Insufficient clearing of the output buffer in Java-based decompressor
> implementations in lz4-java 1.10.0 and earlier allows remote attackers
> to read previous buffer contents via crafted compressed input. In
> applications where the output buffer is reused without being cleared,
> this may lead to disclosure of sensitive data.
>
> JNI-based implementations are not affected.
>
>
> Details
> -------
>
> During the decompression process, the lz4 algorithm may have to repeat
> data that was previously decompressed in the same input frame. In the
> Java implementation, this is implemented by copy operations within the
> output buffer.
>
> With a crafted input, an attacker may induce the Java implementation
> to copy from a region in the output buffer that does not contain
> decompressed data yet. If that region contains sensitive information
> because the output buffer was not cleared prior to decompression, that
> data will then be copied to the decompressed output.
>
>  - LZ4Factory.nativeInstance().safeDecompressor() is not affected.
>
>  - LZ4Factory.nativeInstance().fastDecompressor() is affected because
>    it actually uses safeInstance() since 1.8.1. In 1.8.0 and earlier
>    versions, this implementation is instead vulnerable to the more
>    severe CVE‐2025‐12183, so downgrading is not a solution.
>
>  - Both decompressors of LZ4Factory.safeInstance(),
>    LZ4Factory.unsafeInstance() and LZ4Factory.fastestJavaInstance()
>    are affected.
>
>  - LZ4Factory.fastestInstance() uses the nativeInstance or
>    fastestJavaInstance depending on platform.
>    LZ4Factory.fastestInstance().fastDecompressor() is always affected,
>    while LZ4Factory.fastestInstance().safeDecompressor() is affected
>    only when JNI cannot be used (e.g. on unsupported platforms).
>
> Independent of this vulnerability, it is recommended that users
> migrate from fastDecompressor to safeDecompressor, as the latter is
> more performant (despite the name).
>
> The impact of this vulnerability depends on how user code interacts
> with the decompression API. Users that allocate a new destination
> buffer each time, or use only zeroed buffers, are not impacted. When
> the buffer is reused, however, the confidentiality impact can be
> severe. This vulnerability is marked as VC:H out of caution.
>
> Mitigation
> ----------
> lz4-java 1.10.1 fixes this issue without requiring changes in user code.
>
> If you cannot upgrade to 1.10.1, you can mitigate this vulnerability
> by zeroing the output buffer before passing it to the decompression
> function.
>
> Relation to CVE‐2025‐12183
> --------------------------
> This CVE is a different attack than CVE‐2025‐12183, affecting
> different implementations with different impact. This new
> vulnerability was discovered by CodeIntelligence during research that
> followed up on CVE‐2025‐12183. Users are recommended to upgrade to
> 1.10.1 to fix both vulnerabilities.
>
> Severity: High 8.2 / 10
> CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
> CVE ID: CVE-2025-66566
> Weaknesses: Weakness CWE-201
> Credits: @simonresch (Reporter)

--
        -Alan Coopersmith-                 alan.coopersmith () oracle com
         Oracle Solaris Engineering - https://blogs.oracle.com/solaris