Redis exposed without authentication: the CONFIG SET dir crontab attack

An unauthenticated Redis instance on a public interface is remote code execution. The classic attack chains four commands: CONFIG SET dir to a cron folder, CONFIG SET dbfilename to a valid cron file, SET a malicious payload, and SAVE. If Redis runs as root, the host is compromised immediately. If unprivileged, attackers pivot via SSH keys or systemd timers.

This guide is an operational audit and lockdown. It covers how the file-write attack works, how to detect exposure, how to check for active compromise, and how to harden the instance. It also covers the follow-on risk: once authenticated access is gained, recently disclosed authenticated RCE bugs can escalate to full system control.

What this audit covers

The historic attack uses CONFIG SET dir, CONFIG SET dbfilename, SET, and SAVE to write arbitrary files. Common targets are /var/spool/cron/crontabs on Debian/Ubuntu/Kali, /var/spool/cron on RHEL/CentOS, /etc/cron.d/, and ~/.ssh/authorized_keys.

Prerequisites

• redis-cli access to the instance you are auditing
• Shell access to the Redis host to inspect cron directories and process ownership
• Root or sudo for reading system cron spools and socket state
• Redis 6.0 or newer if you plan to use ACLs for least-privilege access

Procedure

1. Detect network exposure

Run a socket audit to see which interfaces Redis is listening on.

ss -tlnp | grep ':6379'

Any line showing *:6379 or 0.0.0.0:6379 means the port is reachable from outside the host. Verify the running configuration:

redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode
redis-cli CONFIG GET requirepass

If bind is 0.0.0.0 or absent, protected-mode is no, and requirepass is empty, the instance accepts unauthenticated connections from any source.

2. Inspect for active compromise

An exposed instance may already have been used to write cron jobs or SSH keys. Check the locations the attack typically targets.

# Debian/Ubuntu/Kali cron spool
ls -la /var/spool/cron/crontabs/

# RHEL/CentOS cron spool
ls -la /var/spool/cron/

# System-wide cron drop-ins
ls -la /etc/cron.d/

Look for unexpected files such as root, redis, or filenames containing redis_backdoor. Also check for keys planted via the .ssh vector:

find /home /root -name authorized_keys 2>/dev/null

Check process ownership to assess blast radius:

ps -eo pid,user,comm | grep redis-server

3. Review command statistics for abuse

Redis accumulates per-command counters in INFO commandstats. An attacker who has exploited the instance will likely have run CONFIG and SAVE.

redis-cli INFO commandstats | grep -iE 'cmdstat_(config|save|bgsave|flushall|flushdb|shutdown)'

cmdstat_config aggregates all CONFIG subcommands and cannot distinguish a benign CONFIG GET from a malicious CONFIG SET dir. On Redis 6.0 and newer, inspect authorization events:

redis-cli ACL LOG

4. Enable network restrictions

If the instance does not need to accept external connections, restrict the bind address. Warning: changing bind via CONFIG SET closes and recreates the listening socket (existing client connections stay up); it fails if the target IP is not present on the host, and a failed change leaves the instance without a listening socket until a working bind is set.

redis-cli CONFIG SET bind '127.0.0.1 10.0.0.1'

If the instance must accept external connections and you cannot bind to a private interface, enable protected-mode when no password is configured. Since Redis 3.2, protected-mode yes is the default and rejects non-loopback connections when no bind address and no password are set. If an operator disabled it, re-enable it:

redis-cli CONFIG SET protected-mode yes

Warning: protected-mode is a guardrail, not a security boundary. An attacker who already has code execution on the host can connect from 127.0.0.1, disable it with CONFIG SET protected-mode no, and proceed unimpeded.

5. Require authentication

Set a strong password if you are running Redis 5.x or earlier. Warning: this takes effect immediately; clients must authenticate on their next command.

redis-cli CONFIG SET requirepass 'STRONG_PASSWORD_HERE'

On Redis 6.0 and newer, use ACLs instead of a shared password. Disable the default user and create least-privilege accounts. For example, create an application user with read and write access but without dangerous commands, and a monitoring user with limited access:

redis-cli ACL SETUSER app_user on '>STRONG_PASSWORD' '~app:*' '+@read' '+@write' '+@string' '-@dangerous'
redis-cli ACL SETUSER monitor on '>MONITOR_PASSWORD' '+@read' '+ping' '+info' '+client'
redis-cli ACL SETUSER default off

Persist ACLs. If ACL SAVE returns an error, the server is not configured with an aclfile; use CONFIG REWRITE instead to persist users defined in the main configuration.

redis-cli ACL SAVE

6. Restrict or disable CONFIG

The cleanest pre-6.0 defense is to disable the CONFIG command entirely in redis.conf:

rename-command CONFIG ""

This breaks redis-cli configuration management and some deployment tools, so weigh the operational cost. On Redis 7.0 and newer, you can block specific subcommands via ACLs without disabling the entire command:

redis-cli ACL SETUSER app_user '-config|set' '-config|get'

7. Enforce TLS for external exposure

If the instance must listen on an external interface, encrypt the traffic. Redis 6.0 and newer supports TLS via tls-cert-file, tls-key-file, and tls-ca-cert-file. Enforcing TLS closes the plaintext interception vector and prevents credential sniffing on the wire.

8. Patch against follow-on authenticated RCE

The crontab attack gives an attacker Redis access. Several recent CVEs then provide additional attack paths, from authenticated RCE to unauthenticated denial of service.

• CVE-2025-49844 (RediShell): 8.2.2, 8.0.4, 7.4.6, 7.2.11
• CVE-2026-23479 (blocked.c UAF): 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3
• CVE-2025-21605 (unauthenticated DoS): 7.4.3, 7.2.8, 6.2.18

If you cannot patch immediately, deny the @scripting and @admin command categories from any user who does not require them.

9. Persist configuration changes

Live CONFIG SET changes are lost on restart. Write the running config to disk:

redis-cli CONFIG REWRITE

Verify the resulting redis.conf contains your bind, protected-mode, requirepass, or ACL file reference.

Verifying hardening

After applying the controls, confirm the attack surface is closed:

• Re-run ss -tlnp | grep ':6379' and confirm no public interfaces are listed.
• From a remote host, attempt redis-cli -h <public_ip> PING. It should time out, or return a Redis error such as DENIED Redis is running in protected mode (when no password is configured) or NOAUTH (when a password is configured).
• From the local host, attempt CONFIG SET dir /tmp as the application user. It should return an ACL error or command not found.
• Run redis-cli ACL LIST (Redis 6.0+) and confirm the default user is off and application users lack @dangerous and config|set.

Common pitfalls

• protected-mode bypass from loopback. An attacker with a co-located container or SSRF can reach 127.0.0.1:6379 and disable protected-mode. Do not rely on it as your only control.
• CONFIG SET without CONFIG REWRITE. Operators harden an instance at runtime and forget to persist. The next restart opens the instance again.
• rename-command breaking tooling. Disabling CONFIG prevents redis-cli from inspecting the server. Document the tradeoff.
• Running Redis as root. If the crontab attack succeeds against a root-owned process, the resulting shell is root. Run Redis as a dedicated non-root user such as redis.
• Pre-shared passwords in application configs. A requirepass password stored in a public Git repository or application log is equivalent to no password for a determined attacker.

Signals to monitor

How Netdata helps

• Connection metrics (connected_clients, rejected_connections, total_connections_received) surface connection storms that often accompany internet-wide scanning.
• Per-command statistics from INFO commandstats expose spikes in cmdstat_config outside maintenance windows.
• Persistence health alarms on rdb_last_bgsave_status and aof_last_write_status catch unauthorized SAVE calls that may follow a successful intrusion.
• Uptime and reachability checks detect unexpected restarts that may indicate a crash or operator response to compromise.
• Memory metrics correlate used_memory with maxmemory, revealing spikes from attacker payloads or unbounded output buffer growth.

Related guides

• How Redis actually works in production: a mental model for operators
• Redis aof_last_write_status:err: AOF write failures and recovery
• Redis appendfsync always latency: durability vs throughput trade-offs
• Redis big keys: finding the giant key that blocks the event loop
• Redis blocked_clients growing: dead consumers vs healthy queues
• Redis BUSY Redis is busy running a script: blocking Lua and how to recover
• Redis Can’t save in background: fork: Cannot allocate memory - diagnosis and fix
• Redis client output buffer overflow: slow consumers and client-output-buffer-limit
• Redis cluster_slots_pfail > 0: impending node failure in a cluster
• Redis CLUSTERDOWN / cluster_state:fail: slot coverage and recovery
• Redis connected_clients climbing: connection leak detection
• Redis connected_slaves dropped: detecting replica disconnects on the primary