CVE-2026-21864: Valkey-Bloom DOS Vulnerability

CVE-2026-21864 Overview

CVE-2026-21864 is a Denial of Service vulnerability affecting Valkey-Bloom, a Rust-based Valkey module that implements Bloom Filter data types for the Valkey distributed key-value database. A specially crafted RESTORE command can trigger an assertion failure that causes the Valkey server to shutdown, resulting in a complete denial of service condition.

The vulnerability stems from the Valkey-Bloom module's failure to set the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag, which is required for proper error handling during RDB parsing. Although the module correctly implemented parsing logic, the missing flag causes any parsing errors to trigger a system assertion, leading to immediate server termination.

Critical Impact

Remote attackers can cause immediate server shutdown via network-accessible RESTORE commands, resulting in complete denial of service for all Valkey database operations.

Affected Products

• lfprojects valkey-bloom (all versions prior to commit a68614b6e3845777d383b3a513cedcc08b3b7ccd)

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

This vulnerability is a classic example of improper error handling in modular architecture. The Valkey database server relies on modules to properly declare their error handling capabilities through specific flags. When a module fails to set the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag, the server assumes the module cannot gracefully handle RDB parsing errors and responds by triggering a system assertion, which terminates the entire server process.

The attack is particularly dangerous because it can be executed remotely over the network without authentication requirements. An attacker only needs to send a malformed RESTORE command containing specially crafted data that will cause parsing errors. When the Valkey-Bloom module encounters these errors during RDB deserialization, the missing flag causes the server to immediately halt rather than gracefully reject the malformed input.

Root Cause

The root cause is the absence of the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS option flag in the Valkey-Bloom module initialization. Valkey modules are contractually required to set this flag to indicate they can properly handle I/O errors during RDB parsing operations. Without this flag, any parsing error—whether malicious or accidental—results in a catastrophic assertion failure rather than controlled error propagation.

The vulnerability falls under CWE-20 (Improper Input Validation), as the module did not properly configure itself to handle invalid input scenarios that arise during the RESTORE command processing.

Attack Vector

The attack exploits the network-accessible RESTORE command interface. An attacker can craft a malicious RESTORE payload targeting Bloom Filter data types. When the Valkey-Bloom module attempts to parse this malformed data, it encounters errors that would normally be handled gracefully. However, due to the missing VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag, the Valkey server triggers an assertion failure, causing immediate and complete shutdown of the database service.

The following patch demonstrates the fix that adds the ModuleOptions import to enable proper I/O error handling:

 use crate::bloom::command_handler;
 use crate::bloom::data_type::BLOOM_TYPE;
 use crate::bloom::utils::valid_server_version;
+use valkey_module::ModuleOptions;
 use valkey_module_macros::info_command_handler;
 
 pub const MODULE_NAME: &str = "bf";

Source: GitHub Commit Update

Detection Methods for CVE-2026-21864

Indicators of Compromise

• Unexpected Valkey server crashes or shutdowns without graceful error messages
• Log entries showing assertion failures related to RDB parsing or RESTORE command processing
• Incoming network connections sending malformed RESTORE commands targeting Bloom Filter data types
• Repeated server restart attempts following assertion-triggered terminations

Detection Strategies

• Monitor Valkey server logs for assertion failure messages or unexpected termination events
• Implement network-level inspection for anomalous RESTORE command patterns
• Deploy SentinelOne Singularity to detect process termination anomalies in database services
• Audit incoming connections for clients sending unusually structured RESTORE payloads

Monitoring Recommendations

• Configure alerting on Valkey process crashes and unexpected restarts
• Monitor system logs for assertion failure stack traces from the Valkey-Bloom module
• Implement connection rate limiting for clients sending RESTORE commands
• Use SentinelOne's behavioral AI to detect DoS attack patterns against database infrastructure

How to Mitigate CVE-2026-21864

Immediate Actions Required

• Update Valkey-Bloom to a version containing commit a68614b6e3845777d383b3a513cedcc08b3b7ccd or later
• If updating is not immediately possible, disable the RESTORE command using ACL rules if your application does not require it
• Implement network segmentation to limit access to Valkey instances from untrusted networks
• Review application dependencies to ensure all Valkey modules are using appropriate error handling flags

Patch Information

The vulnerability has been addressed in commit a68614b6e3845777d383b3a513cedcc08b3b7ccd. This patch adds the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag to the module initialization, ensuring that I/O errors during RDB parsing are handled gracefully rather than triggering fatal assertions. Refer to the GitHub Security Advisory GHSA-mc2g-h759-3qw2 for complete details and update instructions.

Workarounds

• Disable the RESTORE command via Valkey ACL configuration if it is not required by your application
• Implement firewall rules to restrict network access to Valkey instances
• Use a reverse proxy or API gateway to filter and validate incoming commands before they reach the Valkey server

# Configuration example - Disable RESTORE command via ACL
# Add to valkey.conf or apply via CLI
ACL SETUSER default -RESTORE

# Alternatively, create a restricted user without RESTORE access
ACL SETUSER appuser on >password ~* +@all -RESTORE