CVE-2026-14683: 
Linux Debian Analyse et atténuation des vulnérabilités

CVE-2026-14683 is an uncontrolled memory allocation vulnerability in HdrHistogram (Java implementation) versions up to and including 2.2.2. The flaw resides in the org.HdrHistogram.AbstractHistogram.decodeFromCompressedByteBuffer() method in src/main/java/org/HdrHistogram/AbstractHistogram.java, where the lengthOfCompressedContents argument read from an attacker-controlled ByteBuffer is used directly as an allocation size without validation. The vulnerability was reported via a GitHub issue (Issue #219) on June 3, 2026, and published to NVD on July 4, 2026; the project maintainers had not responded at time of disclosure. The CNA (VulDB) assigned a CVSS v3.1 base score of 3.3 (Low) and a CVSS v4.0 score of 1.9 (Low), though the original reporter assessed it as 7.5 (High) under a network-exploitable scenario (GitHub Advisory, GitHub Issue).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-789 (Memory Allocation with Excessive Size Value). In AbstractHistogram.java at lines 2275–2281, the method reads a 4-byte integer (lengthOfCompressedContents) from the input ByteBuffer and, when the buffer is not array-backed (e.g., a DirectByteBuffer), immediately allocates new byte[lengthOfCompressedContents] without validating the value against the buffer's remaining bytes, a maximum size bound, or negative values. An attacker who can supply a crafted ByteBuffer — for example, by injecting malicious histogram data into a metrics aggregation pipeline — can set lengthOfCompressedContents to Integer.MAX_VALUE / 2 (~1 GB) using a payload as small as 16 bytes, triggering an OutOfMemoryError (GitHub Issue). The fix requires adding a bounds check: if (lengthOfCompressedContents < 0 || lengthOfCompressedContents > buffer.remaining()) throw new IllegalArgumentException(...) (GitHub Issue).

Successful exploitation causes a Denial of Service (DoS) by exhausting JVM heap memory, resulting in an OutOfMemoryError that can crash the processing thread or the entire JVM, affecting all threads sharing the heap. There is no confidentiality or integrity impact. Applications most at risk are those that decode compressed HdrHistogram data from untrusted sources, including metrics aggregation services, distributed tracing backends, and monitoring systems — a single 16-byte malicious payload can trigger an attempted ~1 GB allocation, representing an amplification factor of approximately 67 million times (GitHub Issue, GitHub Advisory).

1. Identify target: Locate an application that accepts and decodes compressed HdrHistogram data from external or untrusted sources (e.g., a metrics aggregation service, distributed tracing backend, or monitoring system using HdrHistogram ≤ 2.2.2).
2. Craft malicious payload: Construct a 16-byte DirectByteBuffer with the V2 compressed cookie (0x1c849304) followed by a large lengthOfCompressedContents value (e.g., Integer.MAX_VALUE / 2 = 1,073,741,823):

ByteBuffer buffer = ByteBuffer.allocateDirect(16).order(ByteOrder.BIG_ENDIAN);
buffer.putInt(0x1c849304); // V2 compressed cookie
buffer.putInt(Integer.MAX_VALUE / 2); // ~1GB claimed length
buffer.flip();

3. Deliver payload: Submit the crafted buffer to the target application through any interface that passes it to Histogram.decodeFromCompressedByteBuffer() — this could be a network API endpoint, a message queue, or a file upload mechanism depending on the application's architecture.
4. Trigger OOM: The vulnerable code path (buffer.hasArray() returns false for DirectByteBuffer) executes new byte[1073741823], causing the JVM to attempt a ~1 GB allocation and throw an OutOfMemoryError, crashing the processing thread or the entire JVM (GitHub Issue).

• Logs: JVM crash logs or application logs containing java.lang.OutOfMemoryError: Java heap space originating from org.HdrHistogram.AbstractHistogram.decodeFromCompressedByteBuffer in the stack trace.
• Logs: Repeated or sudden OutOfMemoryError events in monitoring/metrics service logs without a corresponding increase in legitimate data volume.
• Process: Unexpected JVM process termination or restart of services that use HdrHistogram for metrics collection or histogram decoding.
• Network: Unusually small (≤16 byte) payloads submitted to endpoints that accept compressed histogram data, particularly if they trigger service crashes or restarts (GitHub Issue).

The recommended remediation is to upgrade HdrHistogram to a version newer than 2.2.2 once a patched release is available; as of the disclosure date, the project maintainers had not yet responded to the issue report. As a workaround, add input validation before the allocation in AbstractHistogram.java: reject any lengthOfCompressedContents value that is negative or exceeds buffer.remaining(). Additionally, restrict local and network access to systems running vulnerable HdrHistogram versions, and consider running JVM-based services with constrained heap sizes and monitoring for OutOfMemoryError events as a detection measure (GitHub Issue, GitHub Advisory).

The vulnerability was reported by researcher sara11h via a detailed GitHub issue (Issue #219) on June 3, 2026, including a full PoC, CVSS scoring rationale, and remediation code. The project maintainers had not publicly responded at the time of CVE publication. The GitHub Advisory Database classified the advisory as "Unreviewed" with Low severity based on the CNA (VulDB) score, which differs from the reporter's own assessment of High (7.5) under a network-exploitable scenario — a discrepancy that may reflect debate about the realistic attack vector (GitHub Issue, GitHub Advisory).