Redis exposed to the internet

An unauthenticated Redis reachable from an untrusted network is not a data exposure with a code-execution edge case. It is remote code execution, using documented commands, working as designed.

This is worth being precise about, because “it’s only a cache, there’s nothing sensitive in it” is the reasoning that leaves these instances open — and it misunderstands the risk entirely. The data is not the target. The server is.

The chain

Redis lets a client change where it saves its data, and then save. That’s all that is needed.

1. CONFIG SET dir /root/.ssh — move the working directory.
2. CONFIG SET dbfilename authorized_keys — name the dump file.
3. SET x "ssh-rsa AAAA... attacker@host" — put a key in the keyspace.
4. SAVE — Redis writes the dataset to that path.

The RDB file now sits at /root/.ssh/authorized_keys. It has binary preamble and trailer around the value, but SSH ignores lines it cannot parse and reads the one it can. The attacker logs in.

Nothing here is a bug. Every command is behaving as documented. Redis’s own documentation acknowledges this directly, noting that CONFIG allows a client to change the working directory and dump filename, and that this “may lead to the ability to compromise the system and/or run untrusted code as the same user as Redis is running.”

Three details decide how bad it gets:

• Which user Redis runs as decides whether the write reaches /root/.ssh or is stuck in /var/lib/redis.
• /root/.ssh is one target of many — /etc/cron.d/, a systemd unit, or a web root all work the same way.
• MODULE LOAD is the shorter path where it’s available: load a shared object, execute code, skip the file-write dance entirely. REPLICAOF pointed at an attacker-controlled master is another.

Why “there’s nothing sensitive in the cache” is the wrong question

The attacker is not reading your cache. They are using your Redis as a file-writing primitive to get a shell on the host. What’s in the keyspace is irrelevant to that.

It follows that an empty, freshly installed, “just for testing” Redis on a public IP is exactly as dangerous as your production one. Possibly more, because nobody is watching it.

The shortest path from exposed to closed

In this order:

1. Bind to a private interface — the listener stops existing on the public interface. This alone closes it.
2. Require authentication with ACL users — the redundancy layer for when a network rule is wrong.
3. Restrict dangerous commands — removing CONFIG and MODULE from the application user removes the primitive itself.
4. Run as an unprivileged user — bounds what a successful write can reach.

Steps 1 and 2 take two minutes. Do them before you finish reading this page.

Verify it worked

Is it reachable? From another host — not from the server itself:

redis-cli -h your.host PING

PONG from an untrusted network means an open instance. Treat the host as compromised, not as a config to fix.

Were you hit? Check the things the chain touches. First, whether the working directory is where it should be:

redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename

Anything other than your data directory and dump.rdb is a finding, not a curiosity.

Then look for the payload the chain leaves behind:

sudo cat /root/.ssh/authorized_keys 2>/dev/null
sudo ls -la /etc/cron.d/ /var/spool/cron/crontabs/ 2>/dev/null

An authorized_keys containing binary junk around an ssh-rsa line is the signature of exactly this attack.

Check for loaded modules and unexpected replication:

redis-cli MODULE LIST
redis-cli INFO replication

role:slave on an instance you never configured as a replica means it is being fed by someone else.

Before you apply this

If the instance was reachable and unauthenticated, assume compromise. Do not fix the config and move on — that closes the door behind an attacker who may already be inside.

Configuration is not remediation. The instance being open is how they got in; the SSH key, cron entry, or module they left is how they stay. Fixing bind removes neither.

Minimum response:

1. Take it off the network first — firewall the port, don’t restart Redis (a restart destroys the volatile evidence in CONFIG GET and MODULE LIST).
2. Check authorized_keys for every user, /etc/cron.d/, /etc/systemd/system/, and MODULE LIST for anything you didn’t put there.
3. Rotate every credential the host held, and any credential that was in the keyspace — sessions, tokens, API keys.
4. If anything is found, rebuild the host. Removing the key you found does not establish that it was the only one.

The keyspace itself should be treated as disclosed regardless of what you find.

Related

• Hardening Redis and Valkey — the full checklist.
• Leave protected-mode on — the guard people disable right before this happens.