Redis Running as Root – Privilege Escalation via File Write
When Redis runs as root, every CONFIG SET dir + BGSAVE write lands on disk as a root-owned file. From a low-privilege shell on the same machine — or from direct Redis access — this means you can write to any path on the filesystem: /root/.ssh/, /etc/cron.d/, /etc/passwd, SUID binary locations, or sudoers. Each is an independent path to a root shell.
Confirming Redis Runs as Root
From any shell on the target:
If the USER column shows root, proceed. If it shows redis or another user, the write paths are still valuable but limited to that user's permissions.
From Redis directly (requires Lua or a shell write trick):
Output showing uid=0(root) confirms root execution.
Confirming CONFIG Write Access
Must return a path, not an error.
Technique 1 – SSH Key Injection to /root/.ssh
The cleanest and most persistent path. Full walkthrough at https://hackindex.io/services/redis/exploitation/rce-ssh-key — the same technique applies here since Redis runs as root.
Quick steps:
Technique 2 – Write a SUID Bash Copy
Write a C program that copies /bin/bash to a SUID root binary, then compile and execute it via any shell access.
From your foothold shell, create the payload:
/tmp/suid.c
#include <stdlib.h>
int main() {
setuid(0);
setgid(0);
system("cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash");
return 0;
}
But this requires executing the compiled binary as root. A simpler direct path: use the Redis write to put a SUID shell directly.
Write a SUID shell payload via Redis. This requires writing a binary — use the cron technique instead to execute a SUID setup command as root:
Wait for cron to fire (up to 60 seconds), then:
-p preserves the SUID effective UID. You get a root shell.
Technique 3 – Write to /etc/passwd
Add a root-level user with a known password hash directly to /etc/passwd. Generate a password hash:
Sample output: $1$xyz$abc123...
Write the new user entry:
Warning
Writing to /etc/passwd appends a Redis RDB header/footer to the file. This corrupts it and will likely break PAM authentication for all users — including SSH. Only use this technique in CTF environments, never in production assessments. Test on a backup or use SSH key injection instead.
Switch to the new user:
Technique 4 – Sudoers Write
Write a sudoers entry that gives your current user passwordless sudo:
Then:
Writing to /etc/sudoers.d/ is safer than overwriting /etc/sudoers directly — individual files in that directory are included automatically and a bad file does not corrupt the whole sudoers config.
Clean Up
After escalating, restore the Redis config and remove evidence:
References
-
Redis Security Documentationredis.io/docs/latest/operate/oss_and_stack/management/security (opens in new tab)
Guidance on running Redis as a non-root user and protecting CONFIG access.
Was this helpful?
Your feedback helps improve this page.