CVE-2026-21864: Valkey-bloom DOS Vulnerability

CVE-2026-21864 Overview

CVE-2026-21864 affects Valkey-Bloom, a Rust-based module that adds Bloom Filter data types to the Valkey distributed key-value database. A specially crafted RESTORE command can trigger an assertion failure in the Valkey server, forcing an immediate shutdown. The defect stems from the module not setting the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag, which is required for Valkey modules to handle RDB parsing errors gracefully. Without this flag, parsing errors escalate to a system assertion that terminates the process. The issue is patched in commit a68614b6e3845777d383b3a513cedcc08b3b7ccd.

Critical Impact
Remote, unauthenticated attackers can shut down Valkey instances running the Bloom module by sending a crafted RESTORE command, producing a denial-of-service condition.

Affected Products

Valkey-Bloom module (lfprojects:valkey-bloom)
All versions prior to commit a68614b6e3845777d383b3a513cedcc08b3b7ccd
Valkey deployments loading the vulnerable Bloom module

Discovery Timeline

2026-02-24 - CVE-2026-21864 published to NVD
2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-21864

Vulnerability Analysis

Valkey supports modules that extend its data types and command surface. The Valkey-Bloom module introduces Bloom Filter functionality and registers custom RDB serialization callbacks. When a client issues a RESTORE command, Valkey passes the serialized payload to the owning module for deserialization. The Bloom module performs validation during parsing, but it did not declare itself capable of handling input/output errors. This classifies as improper input validation [CWE-20]. The result is a remotely triggerable denial of service against any Valkey instance using the module.

Root Cause

Valkey modules must set the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag to signal that they tolerate malformed RDB input. If the flag is absent, the Valkey core treats any parsing failure as a fatal condition and triggers an assertion that halts the server. Valkey-Bloom correctly detected malformed payloads in its parser, but the missing options flag prevented the engine from returning a normal error to the client. The patch in commit a68614b6e3845777d383b3a513cedcc08b3b7ccd adds the required flag so that parse failures surface as command errors instead of assertions.

Attack Vector

An unauthenticated attacker with network access to a Valkey port crafts a RESTORE command containing a malformed Bloom Filter serialization. Submitting the command causes the module to fail RDB parsing, which the core escalates to an assertion and process termination. The attack requires no privileges and no user interaction. Repeating the command can prevent service recovery after restart if attackers persist.

No public exploit code is available at this time. See the GitHub Security Advisory GHSA-mc2g-h759-3qw2 for additional technical context.

Detection Methods for CVE-2026-21864

Indicators of Compromise

Unexpected Valkey process termination accompanied by assertion failure messages in server logs
Repeated RESTORE commands originating from untrusted clients in the Valkey command audit trail
Service restart loops on hosts running the Valkey-Bloom module
Client disconnections coinciding with abrupt server shutdown events

Detection Strategies

Monitor Valkey logs for assertion strings and abnormal exit codes following client command execution
Inspect command logs and MONITOR output for RESTORE operations against Bloom Filter keys from external sources
Correlate Valkey crashes with preceding network sessions to identify candidate attacker IPs
Track process supervisor restart counters for Valkey services as a leading indicator of repeated exploitation

Monitoring Recommendations

Alert on any Valkey process exit that is not initiated by an administrative SHUTDOWN command
Forward Valkey server logs to a centralized SIEM for retention and pattern analysis across the fleet
Enable command auditing and restrict who may issue RESTORE through Valkey access control lists
Baseline normal client command patterns so anomalous RESTORE usage triggers investigation

How to Mitigate CVE-2026-21864

Immediate Actions Required

Upgrade Valkey-Bloom to a build that includes commit a68614b6e3845777d383b3a513cedcc08b3b7ccd or later
Restrict network exposure of Valkey ports to trusted application tiers only
Disable the RESTORE command via Valkey ACLs if it is not used by the application
Review Valkey logs for prior assertion-driven shutdowns that may indicate exploitation attempts

Patch Information

The upstream fix is available in the Valkey-Bloom commit a68614b6. The patch sets the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag during module initialization so that RDB parsing errors are returned to the caller instead of triggering an assertion. Rebuild and redeploy the module against an updated source tree, then reload it into Valkey.

Workarounds

Rename or disable the RESTORE command using Valkey ACL rules to block attacker-controlled deserialization
Place Valkey behind a network policy that allows only authenticated application hosts to reach the listening port
Require strong authentication on Valkey instances and rotate credentials used by the application tier
Apply rate limiting at the proxy or firewall layer to slow repeated crash-inducing commands

bash

# Configuration example: disable RESTORE for the default user via Valkey ACL
valkey-cli ACL SETUSER default -restore

# Verify the command is blocked
valkey-cli ACL WHOAMI
valkey-cli ACL GETUSER default