Yes. The Redis security documentation says a client with the CONFIG command can change the server's working directory and the dump file name, which lets it write RDB files to arbitrary paths. That can lead to compromise of the system or running untrusted code as the Redis user. Deny CONFIG to application users and run Redis unprivileged.
What the documentation says
In a classic Redis setup, clients get full access to the command set, but the documentation says access to an instance should never result in the ability to control the system where Redis runs. Redis uses well known practices to avoid memory corruption bugs. Even so, the ability to control the server configuration with CONFIG lets a client change the working directory and the dump file name. The documentation calls this a security issue that may lead to compromising the system or running untrusted code as the same user Redis runs as.
The attack path in plain terms: a client that can talk to Redis and run CONFIG points the snapshot location somewhere useful, stores data it controls, and triggers a save. The result is a file with attacker-chosen content at an attacker-chosen path, written with the privileges of the Redis process.
Three layers of defence
| Layer | What to do |
|---|---|
| Command control | Deny CONFIG, and other administrative commands, to application users with ACL rules |
| Process privilege | Run Redis as an unprivileged user that exists only for Redis; it does not need root |
| Filesystem | Make sure the Redis user can write only its data directory |
The documentation says Redis does not require root privileges and recommends an unprivileged redis user used only for that purpose.
Steps
- Check the user Redis runs as. In containers, look at the image's user and the securityContext in your orchestrator. Do not run it as root.
- Check what that account can write. Remove write access to system directories, web roots, cron locations and anywhere else code could be picked up.
- Create application users without CONFIG. You can deny the command entirely, or from Redis 7.0 allow config get while blocking config set. See How do you block dangerous Redis commands.
- Use ACL CAT with the dangerous category on your version to see which commands that category contains, and decide whether to deny the whole category.
- Reserve a separate admin user for the few who need CONFIG, protect its password, and never share it with applications.
- Firewall the Redis port and remove public exposure. See Redis exposed to the internet: protected mode, bind and firewall.
- Make the filesystem read-only where your platform allows, except for the data directory.
Protect the snapshots as well
RDB files contain the whole data set. The Redis persistence documentation says an RDB snapshot is a compact single file you can move to remote data centers or to object storage, possibly encrypted. It suggests transferring daily or hourly snapshots to S3 in encrypted form, and gives symmetric encryption with gpg as one way. It also says to keep the password in several safe places, because losing it makes the backups useless. For choosing between RDB and AOF, see Redis backups: RDB vs AOF.
Do not leave snapshots in a world-readable directory or a bucket with broad read access. A backup is a second copy of your data and needs the same access controls as the first.
Test the control
In staging, connect as an application user and try to run CONFIG SET dir. It should fail. Add this as a standing test in your deployment checks so a later rule change does not undo it quietly.
Safeguard's asset discovery helps find Redis instances and its policies and gates can check configuration in pull requests. The free scan covers your code and dependencies.
Quick check
Is protected mode enough to stop this?
No. Protected mode limits unauthenticated access from outside the loopback interface in default configurations. It does not stop a connected, permitted client from running CONFIG.
Does Redis need root to run?
No. The documentation says it does not and recommends an unprivileged user that is used only for Redis.
Sources
Last reviewed: 19 October 2026.
