Redis Has a 13-Year-Old RCE Bug. CVSS 10. You're Probably Running It.

#Thirteen years. This bug has been in Redis for thirteen years.

CVE-2025-49844. CVSS 10.0. A perfect score. A use-after-free in Redis's Lua scripting subsystem that has existed since approximately 2012. Demonstrated at Pwn2Own Berlin 2025. Patches released October 2025. And right now, in June 2026, scanning and exploitation against unpatched instances is picking back up.

A crafted Lua script manipulates the garbage collector to trigger the use-after-free, giving the attacker native code execution outside the Lua sandbox with the privileges of the Redis process.

If you don't know what Redis is: you're probably running it. It's the most popular in-memory data store in the world. Caching layer, session store, message broker, job queue. If your web application is faster than "hit the database for every single request," there's a good chance Redis is why.

#"But our Redis requires authentication."

You're right that CVE-2025-49844 requires authentication. The attacker needs to run a Lua script, which means they need access to issue Redis commands.

Here's why that's less reassuring than you think:

Default Redis has no password. Out of the box, Redis binds to all interfaces with no authentication. If your Redis instance is on a network an attacker can reach (internal or, worse, internet-facing), they can connect and run commands immediately. No exploit needed for the initial access. The exploit is what turns "I can read your cache" into "I own your server."

Shared hosting and cloud deployments. In many architectures, the application server and Redis live on the same network segment. If the attacker compromises your web application (through, say, a SQL injection in Drupal or a WordPress plugin vulnerability), they can reach Redis on the internal network.

Weak or reused Redis passwords. When Redis does have a password (via requirepass), it's often something simple because "it's just the cache." Or it's the same password as the database. Or it's in a configuration file that the attacker already exfiltrated.

The authentication requirement lowers the attack complexity slightly, but in practice, getting authenticated access to Redis in a misconfigured environment is trivial.

#What a compromised Redis gives the attacker.

Redis sits in the middle of everything. A compromised Redis instance leaks:

• Session tokens. If your app stores sessions in Redis (a very common pattern), the attacker can read or forge any user's session. Instant impersonation of any logged-in user, including admins.
• Cached credentials. API keys, database query results, OAuth tokens. Whatever your application caches for performance.
• Job queue payloads. If you use Redis for background jobs (Sidekiq, Celery, Bull), the attacker can inject malicious job payloads that your workers will execute.
• Pub/sub messages. Real-time data flowing between services.

And with RCE on the Redis host itself, the attacker pivots to whatever else that server can reach. Databases, internal APIs, other services on the same network.

#What to do.

1. Check your Redis version. Fixed in Redis 6.2.20, 7.2.11, 7.4.6, 8.0.4, and 8.2.2. If you're running anything older, upgrade.

`

redis-cli INFO server | grep redis_version

`

1. If you can't upgrade immediately, restrict Lua scripting. Disable EVAL and EVALSHA commands via Redis ACLs for all users except trusted administrative accounts.

1. Make sure Redis is not internet-facing. Run nmap or check Shodan for your public IP on port 6379. If Redis is reachable from the internet, fix that before anything else. Bind to localhost or your internal network interface only.

1. Set a strong password. If requirepass is empty or set to something like "redis123," change it to a random 32+ character string. Use your password manager.

1. Segment your network. Redis should only be reachable by the application servers that need it. Not by the entire internal network. Not by the office Wi-Fi. Not by the guest network.

1. Enable TLS for Redis connections if your version supports it (6.0+). Unencrypted Redis traffic on a shared network means anyone on that network can sniff credentials, session tokens, and cached data.

#A 13-year-old bug is not unusual. It's normal.

The xz backdoor was a multi-year social engineering operation. The Gitea access control bug was open for four years. This Redis bug existed for thirteen.

Old software has old bugs. The code your business depends on has been accumulating technical debt and undiscovered vulnerabilities for as long as it's existed. Some of those vulnerabilities are found by researchers who report them responsibly. Some are found by attackers who exploit them silently.

The only defense is staying current. Patch. Update. Monitor. It's not exciting. It's not innovative. It's maintenance. And it's the difference between running a business and explaining to your clients why their session tokens are on a dark web forum.

#Further reading

• NVD: CVE-2025-49844 - official vulnerability entry
• Redis Security Advisory - patch details and affected versions
• Sysdig RediShell Analysis - exploitation details
• Redis ACL Documentation - restrict Lua scripting via ACLs
• Shodan - check if your Redis is internet-exposed