CVE-2026-88382: 
Redis vulnerability analysis and mitigation

CVE-2026-88382 is an uncontrolled memory allocation vulnerability in the hiredis C library's RESP aggregate parser, classified as a denial-of-service flaw. It affects hiredis at commit 29ea279 and later post-v1.5.0 builds. A remote, unauthenticated attacker can send a single 12-byte malformed RESP protocol message to trigger a multi-gigabyte memory allocation request, causing an out-of-memory (OOM) crash. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (Feedly, GitHub Issue).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-789 (Memory Allocation with Excessive Size Value). In src/read.c, the processAggregateItem() function reads an attacker-controlled element count from the RESP stream and passes it nearly verbatim to hi_calloc(elements, sizeof(redisReply*)). The only bound check uses REDIS_READER_MAX_ARRAY_ELEMENTS = (1LL<<32)-1 (i.e., 4,294,967,295), which is still large enough to request ~34.4 GB for an ARRAY type or ~68.7 GB for a MAP/ATTR type (where the count is doubled before allocation). The hi_calloc wraparound guard does not fire on 64-bit platforms because SIZE_MAX / 8 far exceeds 2^32-1, so the allocation proceeds and exhausts host memory (GitHub Issue).

Successful exploitation causes a deterministic, single-packet denial of service: the target process is terminated by the OS OOM killer (or aborts under ASan), making any hiredis-based service immediately unavailable. There is no confidentiality or integrity impact — the vulnerability is limited to availability. Any application embedding hiredis that parses RESP input from an untrusted network source is at risk, including Redis proxies, gateways, monitoring tools, and custom library consumers (GitHub Issue, Feedly).

A public proof-of-concept is available on GitHub, consisting of minimal 12-byte RESP payloads (%4294967295\r\n for MAP or *4294967295\r\n for ARRAY) with step-by-step reproduction instructions. The exploit requires no authentication, no user interaction, and is fully automatable over the network. The EPSS score is approximately 0.0039, and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the time of reporting (GitHub Issue, Feedly).

1. Reconnaissance: Identify applications using hiredis post-v1.5.0 (commit 29ea279 or later) that expose a RESP protocol interface to the network — this includes Redis proxies, gateways, or custom services listening on TCP (commonly port 6379 or application-specific ports).
2. Establish connection: Open a TCP connection to the target host on the port where the RESP-parsing application listens.
3. Send MAP payload: Transmit the 12-byte RESP MAP header %4294967295\r\n (hex: 25 34 32 39 34 39 36 37 32 39 35 0d 0a). Alternatively, send the ARRAY variant *4294967295\r\n (hex: 2a 34 32 39 34 39 36 37 32 39 35 0d 0a).
4. Parser processes header: The hiredis processAggregateItem() function parses the element count (4,294,967,295), passes the bound check (value equals REDIS_READER_MAX_ARRAY_ELEMENTS), and for MAP types doubles it to 8,589,934,590 before calling hi_calloc(elements, 8).
5. OOM triggered: The allocation request (~34.4 GB for ARRAY, ~68.7 GB for MAP) exhausts available system memory; the OS OOM killer terminates the process, achieving denial of service (GitHub Issue).

• Network: Single short TCP connection (12 bytes of payload) to the RESP service port, immediately followed by process crash or connection drop; repeated such connections from the same source IP indicating automated exploitation attempts.
• Logs: Application crash logs or core dumps referencing hi_calloc, createArrayObject, or processAggregateItem; ASan output containing ERROR: AddressSanitizer: out of memory: allocator is trying to allocate 0xffffffff0 bytes or 0x7fffffff8 bytes.
• Process: Unexpected termination of the hiredis-based service process (exit code 1, SIGABRT, or OOM kill signal); OS-level OOM killer log entries (kernel: Out of memory: Kill process) referencing the affected service.
• System: Sudden spike in memory consumption on the host immediately before process termination, with no corresponding increase in legitimate workload (GitHub Issue).

The reporter submitted a fix (commit 4c34f02) that addresses the amplification by bounding pre-allocation to data actually buffered on the wire, preventing a 12-byte input from claiming billions of elements. Users should update hiredis to a version that includes this fix (post-commit 4c34f02, once merged into master). As interim workarounds: restrict network access to hiredis-based services to trusted clients only using firewall rules; implement rate limiting on RESP protocol connections; and monitor memory consumption on affected hosts. A numeric cap of approximately 2^28 (~268M elements) was also discussed as an acceptable alternative bound (GitHub Issue, Feedly).

The hiredis maintainer (michael-grunder) engaged directly on the GitHub issue, initially noting skepticism about attack scenarios requiring a malicious Redis server but acknowledging the amplification concern as valid after discussion. The maintainer agreed that the wire-length heuristic proposed by the reporter is a sound fix strategy and indicated the Redis team would weigh in on the preferred approach. The issue prompted a concrete patch commit (4c34f02) from the reporter within two weeks of disclosure (GitHub Issue).