Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!
CVE-2025-49844 — Scanner and educational guide for CVE-2025-49844 (RediShell), a Redis Lua scripting use-after-free vulnerability. Checks Redis servers for exposure, provides remediation steps, and explains the exploit mechanics for learning purposes. | Kitploit
Scanner and educational guide for CVE-2025-49844 (RediShell), a Redis Lua scripting use-after-free vulnerability. Checks Redis servers for exposure, provides remediation steps, and explains the exploit mechanics for learning purposes.
Hey! This is a simple tool I made to help people check if their Redis servers are vulnerable to the bug. It's not meant for actual attacks - just for learning and protecting your own stuff.
What's This All About?
Alright my lovely people, here's one of the most interesting fuckups of 2025, CVE-2025-49844. Essentially, if someone can run Lua scripts on your Redis server, they can gain access to the memory.
The Important Stuff
How Bad?: Fucked up (9.9/10)
Who's Affected: Anyone using Redis version 8.2.1 or older
What Happens: Code Execution
How They Do It: Through Lua scripting (which Redis uses for fancy database shit)
Let's Get Started!
Step 1: Build This Thing
root@kitploit:~
# First, get the Go stuff ready
cd scanner
go mod tidy
# Then build the scanner
go build -o rscan redis-scanner.go
Step 2: Check Your Servers
root@kitploit:~
# Check one server
./rscan -host your-server.com -port 6379
# Check with a password (if you have one)
./rscan -host your-server.com -port 6379 -auth yourpassword
# Check a bunch at once
./rscan -host server1.com,server2.com,server3.com
# Or check from a file
./rscan -file hosts.txt
Step 3: Fix What's Broken
root@kitploit:~
# Turn off Lua scripting (this stops the attack)
redis-cli ACL SETUSER default -@scripting
# Or just update Redis to the newest version
What Do the Results Mean?
🚨 DANGER! - Your Redis is vulnerable (old version + Lua scripts work)
🛡️ Good! - Your Redis is protected (Lua disabled or newer version)
✅ Great! - Your Redis is safe (version 8.2.2 or newer)
❌ Oops! - Can't connect or something went wrong
How This Memory Bug Works
The Problem
This is what is called a "use-after-free" bug. Essentially, Redis has a memory management system that sometimes gets confused about what memory it's already cleaned up.
How It Should Work:
📝 Redis creates some data in memory
🔍 Uses that data for something
🗑️ Cleans up the memory when it's done
✅ Everything is safe and sound
How It Actually Works (The Bug):
📝 Redis creates some data in memory
🔍 Uses that data for something
🗑️ Cleans up the memory
🔍 Tries to use the data again (but it's already gone!)
💥 Everything breaks which is the exploited for funsies ;)
How Hackers Use This
What They Target: Redis's Lua scripting system
Commands They Use: EVAL and EVALSHA (these run Lua scripts)
What They Want: To overwrite memory and run arbitrary code
How to Fix This
Do This Right Now (First 24 Hours)
Find all your Redis servers (you might have more than you think)
Check their versions (anything 8.2.1 or older is fucked, you will need to update!)
Turn off Lua scripts (this stops the attack immediately)
Plan your upgrade (this is the real fix)
Quick Fix (Stop the Attack Now!)
root@kitploit:~
# Turn off Lua scripts (this stops the attack)
redis-cli ACL SETUSER default -@scripting
# Or edit your redis.conf file and add this line:
disable-commands eval evalsha
# Then restart Redis
sudo systemctl restart redis
Lock Down Your Network
root@kitploit:~
# Only allow specific IPs to connect to Redis
iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP
# Make Redis only listen on specific network interfaces
bind 127.0.0.1 10.0.0.100
Set Up Proper Passwords
root@kitploit:~
# Set a strong password
redis-cli CONFIG SET requirepass "fuckredis1234ilovehacking!"
# Create users with limited permissions
redis-cli ACL SETUSER appuser on >password +@read +@write -@scripting
redis-cli ACL SETUSER readonly on >password +@read -@scripting
Update Redis (The Real Fix)
root@kitploit:~
# Backup your data first (always do this!)
sudo cp -r /var/lib/redis /var/lib/redis.backup.$(date +%Y%m%d)
# Update Redis to the fixed version
# On Ubuntu/Debian:
sudo apt update && sudo apt install redis-server=8.2.2*
# On CentOS/RHEL:
sudo yum update redis
# Check that it worked
redis-server --version
Test That Your Fix Actually Works
Make Sure Scripts Are Blocked
root@kitploit:~
# This should fail if your fix is working
redis-cli -a "YourPassword" EVAL "return 'test'" 0
# Should say: (error) ERR unknown command 'EVAL'
Check Your Network Security
root@kitploit:~
# See if Redis is accessible from the network
nmap -p 6379 your-redis-server
# Test if password is required
redis-cli -h your-redis-server -p 6379 ping
# Should ask for password
How to Spot This Attack
Signs in Your Network
Increased patterns of Lua script usage
Someone sending really big or complicated scripts
Lots of scripts running really fast
Scripts that are obviously suspicious
Signs on Your Server
Redis keeps crashing or restarting
Memory usage jumping up and/or down
Redis making strange network connections
Files being accessed that shouldn't be
Check Your Logs
root@kitploit:~
# Look for weird Lua script activity
grep -i "eval\|evalsha" /var/log/redis/redis.log
# Check for failed login attempts
grep -i "auth" /var/log/redis/redis.log
# Look for script errors
grep -i "script" /var/log/redis/redis.log
How Hard Is This to Exploit?
It's Pretty Complicated (if you don't know what's going on)
You need to understand how Redis works inside
Memory Tricks: You have to mess with how Redis manages memory
Lua Skills: You need to be good at writing Lua scripts
Perfect Timing: You have to trigger the bug at exactly the right moment
What Real Exploits Look Like
Create Weird Memory Patterns: Write Lua scripts that make Redis arrange memory in specific ways
Trick the Cleanup Process: Make Redis clean up memory at the wrong time
Break the Memory: Cause Redis to use memory that's already been deleted
Run Your Code: Use the broken memory to execute whatever you want
How Bad Is This Really?
What Happens If You Get Hacked
Complete Takeover: Hackers can run anything they want on your server
All Your Data: They can see everything in your Redis database
Spread to Other Servers: They might use your server to attack other things
Stay Hidden: They can keep access even after you think you fixed it
What This Means for Your Business
Data Leaked: All your sensitive information could be stolen
Everything Breaks: Your Redis service might stop working
Legal Trouble: You might get fined for not protecting data
Nobody Trusts You: Customers might leave if they find out
Lets get technical
What Parts of Redis Are Broken
Lua scripting engine (eval and evalsha commands)
How Redis manages memory
The garbage collection system (cleans up unused memory)
How the Memory Gets Broken
The bug happens when:
You create specific patterns of objects in Lua
You mess with how Redis counts references to memory
You force Redis to clean up memory at the wrong time
You exploit the timing of when Redis manages memory
Which Versions Are Affected
Redis version 8.2.1 and older
Any version that has Lua scripting turned on
This bug has been around for about 13 years (yikes!)
What Exploits Look Like (For Learning)
Basic Structure (This Won't Actually Work)
root@kitploit:~
-- This is just to show you what the structure looks like
local function create_memory_pattern()
-- Create objects that mess with Redis's memory cleanup
local objects = {}
for i = 1, 1000 do
objects[i] = {data = "pattern_" .. i}
end
return objects
end
local function trigger_gc()
-- Force Redis to clean up memory at the wrong time
collectgarbage("collect")
-- This is where the memory bug happens
end
-- Main attack structure
local objects = create_memory_pattern()
-- Mess with memory references
-- Force garbage collection
-- Use the broken memory to run code
How to Protect Yourself
Lock Down Your Network
Set up firewall rules
Don't let Redis talk to the whole internet
Watch your network traffic
Turn on logging
Control Who Can Access
Use strong passwords
Set up user permissions (ACLs)
Only give people the access they need
Check who has access regularly
Watch for Problems
Look at your logs
Monitor how Redis is performing
Watch for weird behavior
Have a plan for when things go wrong
Want to Test This Safely?
If you want to see how this works without breaking anything real, you can use Docker:
root@kitploit:~
# Start a test Redis (this one is vulnerable)
docker run -d --name redis-test -p 6379:6379 redis:6.0
# Test it
cd scanner
./rscan -host localhost -port 6379
# Stop the vulnerable one and start a fixed one
docker stop redis-test
docker run -d --name redis-fixed -p 6379:6379 redis:6.0 redis-server --rename-command EVAL "" --rename-command EVALSHA ""
./rscan -host localhost -port 6379
# Clean up when you're done
docker stop redis-fixed && docker rm redis-fixed
Fancy Stuff (If You Want It)
All the Options
root@kitploit:~
cd scanner
./rscan --help
Scanning Multiple Servers
Create a hosts.txt file like this:
root@kitploit:~
# Put your servers here
server1.com
server2.com:6380
192.168.1.100
redis.example.com:6379
Make It Faster
root@kitploit:~
# Use more workers to scan faster (if you have lots of servers)
./rscan -host server1.com,server2.com -workers 20
