CVE-2025–21605 – Critical Redis Bug Discovered — Could Let Anyone Crash Your Server

A critical vulnerability in Redis just put hundreds of thousands of servers at risk — and it doesn’t require a single line of code from the attacker.

If your infrastructure relies on Redis (and chances are, it does), you need to read this.

Redis is one of the most popular in-memory databases in the world. It’s used for everything from caching and session storage to powering real-time analytics and message queues. Major platforms — think Twitter, GitHub, and even parts of AWS — use Redis under the hood. Its speed and flexibility make it a favorite for developers and ops teams alike.

But that popularity comes with a downside: when Redis has a vulnerability, it doesn’t just affect one system — it can impact entire ecosystems.

Recently, Redis maintainers disclosed a high-severity denial-of-service (DoS) vulnerability, tracked as CVE-2025-21605, that can crash servers or exhaust memory with almost no effort. No login required. No prior access. Just a Redis instance exposed to the network — and an attacker with a script.

What’s the Issue?

At the heart of the problem is Redis’s default behavior: it doesn’t limit how much data it sends to clients. That might seem harmless — until someone takes advantage of it.

An unauthenticated attacker (meaning they don’t need a password) can spam the server with requests. Redis responds to each with an error — but those error messages get stored in a growing output buffer. The longer this goes on, the bigger that buffer gets, eventually eating up all the system’s memory and potentially crashing the server.

Even if you’ve enabled password protection, Redis still sends “NOAUTH” error messages to unauthenticated clients — and those still take up memory.

Why You Should Care

If you’re running Redis on the public internet or in a cloud environment, you’re especially at risk. Here’s a quick look at what’s at stake:

• 🧠 Memory exhaustion: Attackers can eat through system memory, leading to crashes or slowdowns.
• 🔓 No login required: This is a zero-auth vulnerability — anyone with access to your Redis port can exploit it.
• 🌍 Widespread exposure: Over 300,000 Redis instances are believed to be exposed online right now.
• 🚨 High severity: It scores 8.6 out of 10 on the CVSS scale — definitely not one to ignore.

What to Do Now

Redis maintainers have released critical patches. If you’re running Redis, update to one of these versions as soon as possible:

• ✅ 6.2.18
• ✅ 7.2.8
• ✅ 7.4.3

If you can’t patch right away, here are some detailed workarounds to help reduce your risk in the meantime:

🔒 1. Restrict Network Access

• Use firewalls to block incoming traffic to Redis from untrusted IPs.
• In cloud environments (like AWS, Azure, or GCP), tighten security groups or network ACLs so only internal systems or known addresses can access Redis.
• Consider running Redis in a private subnet with no direct internet access.
• Use tools like fail2ban or iptables rate limiting to slow down brute-force or spammy requests.

💡 Pro tip: Redis was never designed to be directly exposed to the internet. If your instance has a public IP, you’re asking for trouble — fix that first.

🔐 2. Enable TLS and Use Client Certificates

• Configure Redis to require TLS/SSL for all connections to encrypt traffic and prevent snooping.
• Require mutual TLS (mTLS) so clients must present valid certificates to connect — this blocks unauthenticated users before they can even trigger the vulnerability.
• Use Redis’s tls-auth-clients setting and enforce client certificate validation.

💡 Bonus: TLS also protects against man-in-the-middle attacks and adds a strong layer of authentication for production workloads.

🛡️ 3. Set Client Output Buffer Limits Manually (Advanced)

If you’re comfortable tuning configs, add explicit limits for output buffers:

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit pubsub 32mb 8mb 60

This won’t fully prevent the vulnerability but can reduce the damage in some scenarios.

A Word from the Experts

Yaacov Hazan, a Redis maintainer, put it bluntly:

“This vulnerability allows trivial exploitation with catastrophic results.”

And security researcher Polaris-alioth, who found the bug, added:

“The lack of output buffer limits in the default config creates a low-effort attack vector for adversaries.”

Other Fixes in the Latest Release

Besides the DoS fix, the latest Redis updates also patch:

• 🧵 Race conditions between main and module threads
• 🧼 Memory leaks in FUNCTION FLUSH
• ⚠️ Crashes related to SLAVEOF and premature WAITAOF returns

Final Thoughts

This vulnerability is a classic example of how default configurations, while convenient, can create huge security holes. Redis is a powerful tool — but that power comes with responsibility.

If you’re running Redis, take action today. Patch if you can. Lock it down if you can’t. Because when your infrastructure depends on Redis, downtime isn’t just annoying — it could cost you real money.