CVE-2024-36114

What it actually does

The vulnerability permits out-of-bounds memory access in LZ4, LZO, Snappy, and Zstandard decompressors because sun.misc.Unsafe is used without additional bounds checks, allowing reads or writes outside provided byte arrays or buffers and resulting in JVM crashes or memory disclosure.

Why it matters to the business

Services handling untrusted compressed data can suffer sudden process termination that disrupts availability or unintended exposure of process memory contents that may contain sensitive information.

How an attack unfolds

An attacker supplies specially crafted compressed input to any Java application using a vulnerable Aircompressor version for decompression; the library performs unsafe memory operations that either terminate the JVM or leak adjacent memory regions.

How to fix it

Upgrade to Aircompressor 0.27 or newer containing commit e139a31be059855a5a70f6994a4ecaa0adbbea7a; no workarounds are available.

How to confirm the fix worked

Confirm the deployed library version is 0.27 or later; retest decompression routines with previously crashing inputs to verify stability and absence of memory disclosure.

Typical attack path

1. Locate Java applications or services that depend on Aircompressor for decompression of external data
2. Generate input that triggers out-of-bounds access in one of the four supported decompressors
3. Deliver the malicious payload through the normal data ingestion path
4. Trigger JVM crash for denial of service or inspect leaked memory for sensitive content

How to detect it

Review application and JVM logs for sudden crashes or access-violation errors during decompression of external data; correlate with spikes in CPU or memory anomalies on affected hosts.

What your security team should do

• Immediately update all Aircompressor usages to the fixed version
• Identify and prioritize services that accept compressed data from untrusted sources
• Add runtime monitoring for unexpected JVM terminations during decompression