A set of Redis vulnerabilities disclosed in late 2024 and early 2025 deserve attention from any organization running Redis in production. If you're running modern web applications, that almost certainly includes you.
The most significant, CVE-2024-31449, allows remote code execution through specially crafted Lua scripts. If an attacker can reach your Redis instance and it's running an affected version, they can execute arbitrary code on the host.
Why this matters more than a typical CVE
Redis is unusual in the infrastructure stack because it's often deployed with minimal access controls. Many organizations treat it as an internal service and skip authentication entirely. The assumption is that if someone can reach Redis, they're already inside the network.
That assumption breaks down quickly when you consider:
- Cloud deployments where network segmentation isn't as tight as on-premises
- Container environments where service-to-service communication is more open by default
- VPN-connected remote workers who may have broader network access than intended
An unauthenticated Redis instance on a reachable network segment combined with an RCE vulnerability is a direct path to code execution. No phishing required.
Affected versions and what to do
Redis versions prior to 7.2.7, 7.4.2, and 7.6 are affected. The fix is straightforward: update Redis. But the operational reality for many organizations is that Redis is embedded in application stacks, managed by development teams, and not always visible to the security team.
Step 1: Find all your Redis instances. This sounds basic, but shadow Redis deployments are common. Development teams spin them up for caching, session management, or message queuing. Check your container orchestration platforms, cloud service inventories, and run network scans for port 6379.
Step 2: Check authentication. Every Redis instance should require authentication. The `requirepass` directive takes five minutes to configure and eliminates the most common attack path. For Redis 6+, use ACLs for more granular control.
Step 3: Patch or isolate. If you can patch immediately, do it. If patching requires a maintenance window, isolate the instances behind stricter network controls in the interim. Disable Lua scripting if it's not needed, as this removes the specific attack vector for CVE-2024-31449.
Step 4: Restrict network access. Redis should never be reachable from the internet. Bind it to localhost or specific internal interfaces. Use firewall rules to limit which hosts can connect.
The broader lesson
Infrastructure components like Redis, Memcached, and Elasticsearch often receive less security scrutiny than the applications they support. They're "just infrastructure," managed by developers who are focused on functionality, not security configuration.
If your vulnerability management program only covers operating systems and web applications, you're missing a significant portion of your attack surface. Build an inventory of infrastructure services and include them in your patching cadence.