CVE-2026-14684: HdrHistogram Memory Exhaustion Vulnerability – Local Exploitation Only

Technical summary

The vulnerability exists in org.HdrHistogram.AbstractHistogram.decodeFromByteBuffer within AbstractHistogram.java. During deserialization of histogram data, the numberOfSignificantValueDigits parameter is not validated before being used to calculate memory allocation sizes. An attacker who can supply a malicious serialized histogram object can trigger allocation of extremely large memory buffers, leading to denial of service through memory exhaustion. The flaw combines CWE-400 (uncontrolled resource consumption) and CWE-789 (memory allocation with excessive size value). Exploitation requires local code execution context and the ability to influence deserialization input.

Business impact

The practical business risk is low given the local-only attack vector and disputable security boundary crossing. Applications using HdrHistogram are at risk only if they deserialize untrusted or user-supplied histogram data in a shared environment where a low-privileged user could monopolize system memory. In most deployments—where HdrHistogram processes only trusted internal telemetry—the risk is minimal. However, in multi-tenant containerized or sandbox environments where users have shell access, a low-privileged attacker could degrade or crash the application by crafting a malicious histogram payload.

Affected systems

HdrHistogram versions up to and including 2.2.2 are affected. The library is commonly integrated into Java applications for high-performance latency measurement and histogram analysis. No specific vendor products are listed in the disclosure, suggesting this is a direct library vulnerability rather than a pre-bundled flaw. Organizations using HdrHistogram should verify their installed version and assess whether they deserialize histogram data from untrusted sources.

Exploitability

Exploitability is limited by a high barrier to entry. An attacker must have local access to the system and sufficient privileges to execute code within the application's runtime context. The attack cannot be performed remotely or without authentication. A published proof-of-concept exists, lowering the technical skill required, but the prerequisite access level makes opportunistic exploitation unlikely. The security community has raised valid questions about whether this constitutes a genuine cross-boundary vulnerability, since the attacker would already need the privileges and access necessary to perform the exploit.

Remediation

Upgrade HdrHistogram to a patched version beyond 2.2.2 (verify the exact version number against the vendor's release notes). If an immediate upgrade is not feasible, mitigate by restricting code execution privileges, isolating applications that deserialize histogram data, and avoiding deserialization of untrusted histogram payloads. Implement input validation and limits on acceptable values for numberOfSignificantValueDigits if you maintain a wrapper around the library.

Patch guidance

Check the HdrHistogram project repository and release notes for versions after 2.2.2 that address this flaw. Patch deployment should be scheduled in your standard change windows; the low CVSS score and local-only nature of the vulnerability do not warrant emergency patching. Verify compatibility with your application's version of Java and any dependent libraries before deploying updates in production.

Detection guidance

Monitor for unusual memory allocation patterns or out-of-memory errors in applications using HdrHistogram, particularly if they process external or user-supplied histogram data. Review application logs for deserialization errors or warnings from the HdrHistogram library. If available, enable Java heap profiling during testing to identify whether malicious histogram inputs cause memory bloat. Assess data flow: confirm whether histogram data sources are trusted or come from untrusted origins.

Why prioritize this

This vulnerability merits low priority for most organizations. The local-only attack vector, disputed security boundary implications, and low CVSS score (3.3) position it below critical and high-severity issues. Prioritize patching only if you have confirmed that applications deserialize untrusted histogram data or run in multi-tenant environments where users have local shell access. For applications that use HdrHistogram only for internal telemetry from trusted sources, this can be addressed in routine maintenance cycles.

Risk score, explained

The CVSS 3.1 score of 3.3 (LOW) reflects the restrictive attack surface: local-only access is required (AV:L), no elevated privileges bypass is needed (AC:L, PR:L), and the sole impact is denial of service (A:L, C:N, I:N). The score appropriately discounts the fact that exploitation requires the attacker to already have local presence. The disputed nature of whether this crosses a security boundary suggests the true risk may be even lower in most deployment contexts.

Frequently asked questions