# CVE-2026-88382: hiredis uncontrolled memory allocation in RESP aggregate parser

Source: https://junglewise.ai/threats/cve-2026-88382-hiredis-commit-29ea279-post-v1-5-0-contains-an-uncontrolled  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-09-24. Updated: 2026-09-26  
License: CC BY 4.0 with a link back

CVE-2026-88382 · Severity: high · CVSS 7.5 · Published 2026-09-24

hiredis is a Redis client library used to parse the Redis Serialization Protocol (RESP). An attacker can send a specially crafted RESP message with an extremely large array or map element count, causing the parser to attempt allocating tens of gigabytes of memory in a single operation. This triggers an out-of-memory condition that crashes the application, causing a denial of service against any system parsing untrusted RESP streams.

Vendors: [Redis](https://junglewise.ai/threats/vendors/redis).

## Quick answers

**Is CVE-2026-88382 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-88382 being exploited in the wild.

**How severe is CVE-2026-88382?** High severity, with a CVSS score of 7.5, published 24 September 2026.

**Which products and versions are affected?** Redis Hiredis post-v1.5.0, including commit 29ea279.

**Is there a fix for CVE-2026-88382?** No fixed version is recorded yet. Check the vendor's advisory in the references below. If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.

**How is CVE-2026-88382 attacked?** It is attacked over the network, in a software library.

**Am I affected by CVE-2026-88382?** Check whether you run Redis Hiredis at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## Technical details

The vulnerability exists in the RESP aggregate parser (processAggregateItem in src/read.c), which accepts an attacker-controlled element count for ARRAY/MAP/SET/PUSH/ATTR types and passes it directly to hi_calloc() without sufficient bounds checking. Although a maximum limit of 2^32-1 elements is enforced, multiplying this by the size of a pointer (8 bytes, and doubled for MAP/ATTR types) results in allocation requests of 34–69 GB. The hi_calloc() wraparound guard does not prevent these huge-but-valid values on 64-bit systems, allowing a single untrusted RESP message to exhaust all available memory and trigger the OS OOM killer.

## Affected products

- Redis hiredis post-v1.5.0, including commit 29ea279

## Timeline

- 2026-09-24: disclosed

## References

- [https://github.com/redis/hiredis/issues/1357](https://github.com/redis/hiredis/issues/1357)