CVE-2025-12183: 
Java vulnerability analysis and mitigation

CVE-2025-12183 is an out-of-bounds read vulnerability in the org.lz4:lz4-java library (versions 1.8.0 and earlier) that allows remote attackers to cause denial of service and read adjacent memory via untrusted compressed input. The vulnerability was discovered by Jonas Konrad (Oracle Corp.) and disclosed on November 28, 2025, with coordinated disclosure via Sonatype. Affected Maven coordinates include org.lz4:lz4-java, org.lz4:lz4-pure-java, and net.jpountz.lz4:lz4, all up to and including version 1.8.0. It carries a CVSS v4.0 base score of 8.8 (High) (Sonatype Advisory, oss-security).

The vulnerability is classified as CWE-125 (Out-of-bounds Read) and stems from insufficient bounds checking in multiple lz4-java decompression implementations. Specifically, the JNI-based "fast" decompressor relies on the deprecated LZ4_decompress_fast C library API, which lacks bounds checks and is explicitly documented as insecure for untrusted input. Additionally, all Java-based implementations using the sun.misc.Unsafe API lack sufficient bounds checks, enabling both denial of service and memory disclosure when processing malicious compressed data; the pure-Java (non-Unsafe) implementations only produce ArrayIndexOutOfBoundsExceptions and are not considered exploitable. An unauthenticated remote attacker can trigger the flaw by supplying crafted compressed input to any service that decompresses data using the vulnerable factory methods (LZ4Factory.nativeInstance().fastDecompressor(), LZ4Factory.unsafeInstance(), LZ4Factory.fastestInstance(), or LZ4Factory.fastestJavaInstance()) (Sonatype Advisory, oss-security).

Successful exploitation allows an unauthenticated remote attacker to read adjacent heap memory contents (information disclosure) and crash the affected service (denial of service). The memory disclosure risk is most severe in applications using the JNI fast decompressor or the sun.misc.Unsafe-based Java implementations, potentially exposing sensitive in-memory data such as credentials, session tokens, or application secrets. The vulnerability affects a wide range of downstream products that bundle lz4-java, including IBM App Connect Enterprise, IBM DB2, IBM Cloud Pak for Business Automation, IBM Application Performance Management, Oracle products, Splunk AppDynamics, and others (Sonatype Advisory, IBM Advisory).

As of the time of reporting, there is no public proof-of-concept exploit and no evidence of active in-the-wild exploitation (Feedly). The vulnerability is remotely exploitable without authentication and requires no user interaction, making it attractive for automated scanning. The EPSS score is approximately 0.0018 (0.18%), indicating a low current probability of exploitation in the wild. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Detection is available via Qualys (detection IDs 6046895 and 6046900) (Feedly).

1. Identify vulnerable services: Enumerate applications or services that process LZ4-compressed data and depend on org.lz4:lz4-java ≤ 1.8.0, using dependency scanners (e.g., OWASP Dependency-Check, Sonatype Lifecycle) or by inspecting Maven/Gradle build files.
2. Determine the decompressor in use: Confirm the target application uses a vulnerable factory method — LZ4Factory.nativeInstance().fastDecompressor(), LZ4Factory.unsafeInstance(), LZ4Factory.fastestInstance(), or LZ4Factory.fastestJavaInstance() — by reviewing source code or observing application behavior.
3. Craft malicious compressed input: Construct an LZ4-compressed payload that, when decompressed, causes the library to read beyond the allocated buffer boundary. This exploits the missing bounds checks in the deprecated LZ4_decompress_fast C API or the Unsafe-based Java implementation.
4. Deliver the payload: Submit the crafted compressed data to the target service via any network-accessible input channel that accepts LZ4-compressed content (e.g., Kafka messages, HTTP request bodies, database streams).
5. Observe results: A successful exploit causes the service to either crash (DoS) or return memory contents adjacent to the decompression buffer, potentially disclosing sensitive in-memory data (Sonatype Advisory, oss-security).

• Logs: Unexpected JVM crashes or SIGSEGV/SIGBUS signals in application logs associated with LZ4 decompression operations; ArrayIndexOutOfBoundsException or native crash dumps referencing LZ4_decompress_fast in stack traces.
• Application Behavior: Repeated service restarts or out-of-memory errors in applications processing external LZ4-compressed data; anomalous memory dumps or heap snapshots generated by the JVM.
• Network: Unusual or malformed LZ4-compressed payloads arriving from external/untrusted sources on data ingestion endpoints (e.g., Kafka topics, HTTP APIs accepting compressed content).
• File System: Unexpected JVM core dump files (hs_err_pid*.log) in the application working directory referencing native lz4 library frames.

The primary remediation is to upgrade to the community-maintained fork at.yawk.lz4:lz4-java:1.8.1 (or later, including 1.9.0), which replaces the vulnerable JNI fast decompressor and all sun.misc.Unsafe-based implementations with safe counterparts. A relocation POM at org.lz4:lz4-java:1.8.1 redirects to the new artifact for backward compatibility. As a code-level workaround without patching, applications using LZ4Factory.nativeInstance().fastDecompressor() should switch to .safeDecompressor(), and those using unsafeInstance(), fastestInstance(), or fastestJavaInstance() should switch to safeInstance(). Downstream product users should apply vendor-specific patches from IBM (available April–June 2026), Oracle (April 2026 CPU), and Splunk (May 2026) as applicable (Sonatype Advisory, lz4-java fork, Oracle CPU).

The vulnerability was coordinated by Sonatype and disclosed via the oss-security mailing list on December 1, 2025, with Alan Coopersmith noting the discontinuation of the official lz4-java project and the availability of a community fork. The security community highlighted the unusual situation of a widely-used library being abandoned mid-vulnerability, forcing migration to a new group ID (at.yawk.lz4). SecurityOnline.info covered the story with emphasis on the need for immediate migration due to the library's discontinued status. Multiple major vendors including IBM, Oracle, and Splunk issued advisories acknowledging the impact on their products (oss-security, Sonatype Advisory).