compress-lzf CVE-2026-109395

The target application must decompress attacker-supplied LZF data using the default LZFDecoder, which selects the sun.misc.Unsafe-based UnsafeChunkDecoder on JVMs/platforms where Unsafe is available; no authentication or user interaction is required (PR:N/UI:N). Key limiting factors: exploitation only occurs if untrusted/attacker-controlled LZF streams reach the decoder - applications that decompress only trusted, internally-generated data are not meaningfully exposed - and deployments where the Unsafe-based decoder is not selected (platforms/JVM configurations that fall back to the safe pure-Java decoder) avoid the vulnerable code path.

This is a genuinely high-priority library flaw, though its real-world impact is gated by how the affected library is used. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H) describes an unauthenticated, low-complexity network attack with high confidentiality impact (leaking unrelated JVM heap memory, which may contain secrets, keys, or other users' data) and high availability impact (JVM crash), with no integrity impact - consistent with the CWE-125 out-of-bounds read and the description. No EPSS score, KEV listing, or public exploit was provided in the input, so despite the high CVSS the signals point to a serious-but-not-yet-actively-exploited issue: there is no public exploit identified at time of analysis and no confirmation of in-the-wild use. The one caveat worth flagging is the attack vector: CVSS marks this AV:N/PR:N (unauthenticated remote), but exploitation actually depends on an application choosing to feed attacker-controlled LZF data into the default decoder - so whether a given deployment is truly 'remote unauthenticated' depends on the consuming application's data flow, not the library in isolation. Discovery via VulnCheck using Jazzer fuzzing (visible in the PR diff) indicates the condition is reliably triggerable, which raises the practical likelihood of exploit development even though none is published yet.

A Java service decompresses LZF-compressed input received from an untrusted source (e.g., an upload or message payload) using the default LZFDecoder, which selects the sun.misc.Unsafe-based UnsafeChunkDecoder. An unauthenticated attacker submits a crafted LZF stream with malformed back-references or literal runs, causing an out-of-bounds read that either returns unrelated JVM heap memory inside the decompressed output or crashes the JVM. No public exploit is identified, but VulnCheck's Jazzer-based fuzzing discovery indicates the flaw is straightforward to trigger.