CVE-2026-14683: HdrHistogram DoS Vulnerability

CVE-2026-14683 Overview

CVE-2026-14683 is an uncontrolled resource consumption vulnerability [CWE-400] affecting HdrHistogram versions up to 2.2.2. The flaw resides in the org.HdrHistogram.AbstractHistogram.decodeFromCompressedByteBuffer function within src/main/java/org/HdrHistogram/AbstractHistogram.java. An attacker with local access can manipulate the lengthOfCompressedContents argument to trigger uncontrolled memory allocation. The exploit is publicly available, and the maintainers were notified through an issue report but have not yet responded. The attack requires local access and low privileges, limiting practical impact to environments where untrusted input reaches the decoding function.

Critical Impact
Local attackers can trigger uncontrolled memory allocation in Java applications embedding HdrHistogram, potentially causing denial of service through memory exhaustion.

Affected Products

HdrHistogram versions up to and including 2.2.2
Java applications that decode untrusted compressed histogram data using decodeFromCompressedByteBuffer
Downstream libraries and monitoring tools bundling vulnerable HdrHistogram releases

Discovery Timeline

2026-07-04 - CVE-2026-14683 published to NVD
2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-14683

Vulnerability Analysis

HdrHistogram is a Java library for recording and analyzing high-dynamic-range histograms, widely used in latency measurement and performance monitoring. The vulnerable function decodeFromCompressedByteBuffer reads a length field, lengthOfCompressedContents, from an incoming serialized buffer and uses it to allocate memory before validating the value against realistic bounds or the actual buffer size.

When an attacker supplies a crafted buffer containing an inflated lengthOfCompressedContents value, the function attempts to allocate a buffer of the declared size. This behavior enables a resource exhaustion condition. The Java Virtual Machine (JVM) hosting the application can encounter OutOfMemoryError conditions, degrading or halting service availability.

The attack vector is local, meaning the malicious buffer must originate from a source reachable within the local execution context. Applications that persist and later deserialize histogram snapshots from user-controllable storage locations are the most exposed.

Root Cause

The root cause is missing validation of a length field controlled by attacker-supplied data before that field drives a memory allocation. The code trusts lengthOfCompressedContents without cross-checking it against the remaining buffer capacity or an upper bound sized to expected histogram payloads.

Attack Vector

Exploitation requires the attacker to submit a crafted compressed histogram byte buffer to a routine that calls decodeFromCompressedByteBuffer. The attacker sets the length prefix to a large value, causing the library to request a correspondingly large allocation. Repeated invocations amplify the impact, exhausting heap memory and forcing the JVM into garbage collection thrashing or termination.

The vulnerability mechanism is described in the public GitHub issue thread. See the GitHub Issue Discussion and the VulDB CVE-2026-14683 advisory for additional technical detail.

Detection Methods for CVE-2026-14683

Indicators of Compromise

Repeated java.lang.OutOfMemoryError events originating from stack frames containing AbstractHistogram.decodeFromCompressedByteBuffer
Sudden JVM heap spikes correlated with ingestion of external histogram snapshot files or network payloads
Process termination or restart loops in services that deserialize HdrHistogram data from untrusted sources

Detection Strategies

Inspect application dependency trees for HdrHistogram versions at or below 2.2.2 using build tooling such as mvn dependency:tree or gradle dependencies
Enable JVM heap dump on OutOfMemoryError and inspect dumps for large byte array allocations attributed to HdrHistogram decoding paths
Instrument the decode entry point with logging that records the declared lengthOfCompressedContents value versus available buffer size

Monitoring Recommendations

Alert on abnormal JVM heap growth rates in services that consume histogram data feeds
Track garbage collection pause times and full GC frequency for services embedding HdrHistogram
Log and rate-limit deserialization operations that accept externally sourced histogram buffers

How to Mitigate CVE-2026-14683

Immediate Actions Required

Identify all applications and services that bundle HdrHistogram version 2.2.2 or earlier and inventory their exposure to external histogram input
Restrict access to interfaces or files that feed data into decodeFromCompressedByteBuffer to trusted principals only
Apply input size caps at the application layer before passing buffers into HdrHistogram decode routines

Patch Information

As of the last modification date of 2026-07-07, the HdrHistogram maintainers have not published a fix. Track the GitHub Issue Discussion and the HdrHistogram Project Repository for release notes containing a corrective commit. Apply the fixed release once available and rebuild dependent artifacts.

Workarounds

Wrap calls to decodeFromCompressedByteBuffer with a pre-check that rejects buffers whose declared length exceeds a conservative maximum matched to expected histogram sizes
Enforce JVM memory limits with -Xmx sized to fail fast rather than allow runaway allocation to affect co-located workloads
Isolate services that must decode untrusted histogram data in dedicated containers with memory quotas to contain denial-of-service impact
Remove or replace the HdrHistogram dependency in components that do not require compressed histogram deserialization

bash

# Configuration example: enforce container memory limits and JVM heap cap
docker run --memory=512m --memory-swap=512m \
  -e JAVA_OPTS="-Xmx256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdumps" \
  my-histogram-service:latest