Valkey Io
Monthly
Use-after-free in Valkey's RESTORE command allows a low-privileged remote attacker to potentially execute arbitrary code by supplying a crafted RDB stream payload that assigns a single Pending Entry List (PEL) NACK to multiple stream consumers. Valkey versions prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1 across all active release trains are affected. When one consumer referencing the shared NACK is deleted while another still holds a pointer to the same memory, a use-after-free condition occurs that can corrupt the allocator heap and enable remote code execution. No public exploit or CISA KEV listing exists at time of analysis, though the vendor's own fix PR includes a detailed reproducer test that substantially lowers the barrier to weaponization.
Use-after-free in Valkey's TLS connection handler allows an authenticated remote attacker to crash the server or potentially achieve remote code execution on TLS-enabled deployments. The flaw exists across all Valkey branches prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1, confirmed via GitHub security advisory GHSA-53mc-f3m3-99vh and EUVD-2026-60822. No active exploitation has been confirmed (not in CISA KEV), but the full C:H/I:H/A:H CVSS impact and the RCE/Memory Corruption tags warrant prompt patching for any TLS-configured Valkey instance.
Out-of-bounds read in Valkey's `kvstoreGetHashtable` function (src/kvstore.c) allows an attacker who can supply a crafted RDB file at server startup to corrupt the `didx` argument beyond the valid hashtable index range, crashing the process and rendering the cluster node unavailable. Affected versions are ≤9.0.5 (stable) and ≤9.1.1 (development branch); exploitation requires cluster mode and attacker-controlled RDB input, making this a constrained, low-severity DoS limited to the startup phase. A POC RDB archive is publicly available; no public exploit identified for active exploitation and CISA KEV listing is absent. The Valkey maintainers explicitly characterized the issue as a memory-safety improvement below their security-disclosure threshold.
Out-of-bounds read in Valkey's cluster slot-migration RDB loader allows a network-positioned attacker to crash affected servers by supplying a crafted RDB file with a truncated `job_name` field in an `RDB_OPCODE_SLOT_IMPORT` record. Valkey versions up to 9.0.4 and 9.1.0 running in cluster mode are affected; the vulnerable `createSlotImportJob()` function in `src/cluster_migrateslots.c` performs a fixed 40-byte `memcpy` without first validating that the loaded `job_name` is exactly `CLUSTER_NAMELEN` bytes, triggering CWE-125 on undersized input. A public proof-of-concept is available via GitHub issue #4207, and patched releases 9.0.5 and 9.1.1 are confirmed available.
Double-free memory corruption in Valkey 9.1.0's Module Timer Subsystem allows a high-privileged remote attacker to crash the server by triggering a self-stopping timer callback pattern. The moduleTimerHandler function in src/module.c frees the timer object both inside the callback (via ValkeyModule_StopTimer) and again after callback return, causing a double-free. A public proof-of-concept has been disclosed via GitHub, though the CVSS 4.0 score of 1.9 reflects that exploitation requires high-privilege module control, severely constraining real-world impact to low-severity availability disruption.
Use-after-free in Valkey's RESTORE command allows a low-privileged remote attacker to potentially execute arbitrary code by supplying a crafted RDB stream payload that assigns a single Pending Entry List (PEL) NACK to multiple stream consumers. Valkey versions prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1 across all active release trains are affected. When one consumer referencing the shared NACK is deleted while another still holds a pointer to the same memory, a use-after-free condition occurs that can corrupt the allocator heap and enable remote code execution. No public exploit or CISA KEV listing exists at time of analysis, though the vendor's own fix PR includes a detailed reproducer test that substantially lowers the barrier to weaponization.
Use-after-free in Valkey's TLS connection handler allows an authenticated remote attacker to crash the server or potentially achieve remote code execution on TLS-enabled deployments. The flaw exists across all Valkey branches prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1, confirmed via GitHub security advisory GHSA-53mc-f3m3-99vh and EUVD-2026-60822. No active exploitation has been confirmed (not in CISA KEV), but the full C:H/I:H/A:H CVSS impact and the RCE/Memory Corruption tags warrant prompt patching for any TLS-configured Valkey instance.
Out-of-bounds read in Valkey's `kvstoreGetHashtable` function (src/kvstore.c) allows an attacker who can supply a crafted RDB file at server startup to corrupt the `didx` argument beyond the valid hashtable index range, crashing the process and rendering the cluster node unavailable. Affected versions are ≤9.0.5 (stable) and ≤9.1.1 (development branch); exploitation requires cluster mode and attacker-controlled RDB input, making this a constrained, low-severity DoS limited to the startup phase. A POC RDB archive is publicly available; no public exploit identified for active exploitation and CISA KEV listing is absent. The Valkey maintainers explicitly characterized the issue as a memory-safety improvement below their security-disclosure threshold.
Out-of-bounds read in Valkey's cluster slot-migration RDB loader allows a network-positioned attacker to crash affected servers by supplying a crafted RDB file with a truncated `job_name` field in an `RDB_OPCODE_SLOT_IMPORT` record. Valkey versions up to 9.0.4 and 9.1.0 running in cluster mode are affected; the vulnerable `createSlotImportJob()` function in `src/cluster_migrateslots.c` performs a fixed 40-byte `memcpy` without first validating that the loaded `job_name` is exactly `CLUSTER_NAMELEN` bytes, triggering CWE-125 on undersized input. A public proof-of-concept is available via GitHub issue #4207, and patched releases 9.0.5 and 9.1.1 are confirmed available.
Double-free memory corruption in Valkey 9.1.0's Module Timer Subsystem allows a high-privileged remote attacker to crash the server by triggering a self-stopping timer callback pattern. The moduleTimerHandler function in src/module.c frees the timer object both inside the callback (via ValkeyModule_StopTimer) and again after callback return, causing a double-free. A public proof-of-concept has been disclosed via GitHub, though the CVSS 4.0 score of 1.9 reflects that exploitation requires high-privilege module control, severely constraining real-world impact to low-severity availability disruption.