CVE-2021-32675: Redis Database DOS Vulnerability

CVE-2021-32675 Overview

CVE-2021-32675 is a resource exhaustion vulnerability in Redis, the popular open source in-memory database. When parsing incoming Redis Standard Protocol (RESP) requests, Redis allocates memory based on user-specified values that determine the number of elements in multi-bulk headers and the size of each element in bulk headers. An attacker can deliver specially crafted requests over multiple connections to force the server to allocate significant amounts of memory, leading to denial of service conditions. Critically, because the same parsing mechanism handles authentication requests, this vulnerability can be exploited by unauthenticated users, significantly increasing the attack surface.

Critical Impact

Unauthenticated attackers can exhaust server memory through crafted RESP requests, causing denial of service on Redis instances exposed to untrusted networks.

Affected Products

• Redis versions prior to 6.2.6
• Redis versions prior to 6.0.16
• Redis versions prior to 5.0.14
• Fedora 33, 34, and 35
• Debian Linux 10.0 and 11.0
• NetApp Management Services for Element Software and NetApp HCI
• Oracle Communications Operations Monitor 4.3, 4.4, and 5.0

Discovery Timeline

• 2021-10-04 - CVE-2021-32675 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-32675

Vulnerability Analysis

This vulnerability stems from improper resource allocation controls within Redis's RESP request parsing mechanism. The Redis protocol allows clients to specify the number and size of data elements in their requests through multi-bulk and bulk headers. The server trusts these user-supplied values and allocates memory accordingly without sufficient validation or limits. An attacker can exploit this by sending requests with extremely large element counts or sizes across multiple connections, causing the server to consume all available memory.

The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling), which accurately describes the root cause: Redis fails to impose adequate restrictions on memory allocation during request parsing.

Root Cause

The root cause is the absence of proper memory allocation limits when processing RESP protocol headers. Redis directly uses client-specified values from multi-bulk headers (number of elements) and bulk headers (element sizes) to determine memory allocation, without implementing safeguards against excessive or malicious values. The same vulnerable parsing code path is used for both authenticated and unauthenticated requests, including the initial authentication handshake.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can:

1. Establish multiple connections to an exposed Redis instance
2. Send specially crafted RESP requests with inflated element counts or sizes in the headers
3. Force Redis to allocate large amounts of memory for each connection
4. Repeat across multiple connections to exhaust server memory
5. Cause denial of service when the system runs out of available memory

The attack can be performed without authentication because the vulnerable parsing code processes requests before authentication is validated.

// Security patch from src/networking.c
// Source: https://github.com/redis/redis/commit/5674b0057ff2903d43eaff802017eddf37c360f8

    raxInsert(server.clients_index,(unsigned char*)&id,sizeof(id),c,NULL);
 }
 
+int authRequired(client *c) {
+    /* Check if the user is authenticated. This check is skipped in case
+     * the default user is flagged as "nopass" and is active. */
+    int auth_required = (!(DefaultUser->flags & USER_FLAG_NOPASS) ||
+                          (DefaultUser->flags & USER_FLAG_DISABLED)) &&
+                        !c->authenticated;
+    return auth_required;
+}
+
 client *createClient(connection *conn) {
     client *c = zmalloc(sizeof(client));

The patch introduces the authRequired() function to centralize authentication checking. This enables the server to enforce memory limits differently for authenticated versus unauthenticated clients, preventing unauthenticated users from consuming excessive resources.

// Security patch from src/server.c
// Source: https://github.com/redis/redis/commit/5674b0057ff2903d43eaff802017eddf37c360f8

    int is_denyloading_command = !(c->cmd->flags & CMD_LOADING) ||
                                 (c->cmd->proc == execCommand && (c->mstate.cmd_inv_flags & CMD_LOADING));
 
-    /* Check if the user is authenticated. This check is skipped in case
-     * the default user is flagged as "nopass" and is active. */
-    int auth_required = (!(DefaultUser->flags & USER_FLAG_NOPASS) ||
-                          (DefaultUser->flags & USER_FLAG_DISABLED)) &&
-                        !c->authenticated;
-    if (auth_required) {
-        /* AUTH and HELLO and no auth modules are valid even in
+    if (authRequired(c)) {
+        /* AUTH and HELLO and no auth commands are valid even in
          * non-authenticated state. */
         if (!(c->cmd->flags & CMD_NO_AUTH)) {
             rejectCommand(c,shared.noautherr);

Detection Methods for CVE-2021-32675

Indicators of Compromise

• Unusual memory consumption spikes on Redis server processes
• Multiple simultaneous connections from single or related IP addresses
• Redis server becoming unresponsive or crashing due to out-of-memory conditions
• Abnormally large RESP requests in network traffic or Redis logs

Detection Strategies

• Monitor Redis memory usage metrics for sudden unexplained increases using INFO memory command
• Implement network intrusion detection rules to identify RESP requests with unusually large header values
• Set up alerting on Redis connection counts exceeding normal operational baselines
• Use Redis slowlog and client list commands to identify suspicious connection patterns

Monitoring Recommendations

• Deploy continuous memory usage monitoring with alerting thresholds for Redis instances
• Configure network traffic analysis to inspect RESP protocol communications for anomalies
• Implement connection rate limiting and monitoring at the network and application layers
• Review Redis logs regularly for signs of resource exhaustion attacks

How to Mitigate CVE-2021-32675

Immediate Actions Required

• Upgrade Redis to patched versions: 6.2.6, 6.0.16, or 5.0.14 or later
• Block unauthenticated access to Redis using firewalls, iptables, or security groups
• Enable TLS and require client certificate authentication if patching is delayed
• Restrict network access to Redis to only trusted internal networks

Patch Information

The vulnerability is fixed in Redis versions 6.2.6, 6.0.16, and 5.0.14. The official patch is available through the GitHub Redis Commit. Additional vendor-specific patches are available from Debian Security Advisory DSA-5001, NetApp Security Advisory, and Oracle Security Alert April 2022.

For complete technical details, refer to the GitHub Security Advisory.

Workarounds

• Use network access control tools (firewalls, iptables, security groups) to prevent unauthenticated users from connecting
• Enable TLS on Redis and require users to authenticate using client-side certificates
• Deploy Redis behind a reverse proxy that can enforce authentication before connections reach the server
• Implement memory limits at the operating system level using cgroups or similar mechanisms

# Configuration example - Network access control with iptables
# Allow Redis access only from trusted network (example: 10.0.0.0/24)
iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

# Enable Redis authentication in redis.conf
# requirepass your_strong_password_here

# Enable TLS in redis.conf (Redis 6.0+)
# tls-port 6379
# port 0
# tls-cert-file /path/to/redis.crt
# tls-key-file /path/to/redis.key
# tls-ca-cert-file /path/to/ca.crt
# tls-auth-clients yes