Port reference
Port 6379 (TCP) – Redis
Default port for the Redis in-memory data store and cache.
Default state
Historically Redis bound to all interfaces with NO authentication by default; modern versions ship 'protected mode' binding to localhost. Many exposed instances remain unauthenticated.
Common attacks
- Unauthenticated access to read, modify, or wipe all data
- RCE via config rewrite (writing SSH keys or cron jobs through CONFIG SET/SAVE)
- Module loading abuse for remote code execution
- Data theft and ransom of exposed instances
Hardening
- Bind to localhost or a private interface; keep protected-mode on
- Require authentication (requirepass / ACLs) with a strong password
- Never expose 6379 to the internet; firewall to trusted hosts only
- Rename or disable dangerous commands (CONFIG, FLUSHALL, MODULE) and require TLS
- Run Redis as an unprivileged user and patch regularly
nmap snippet
nmap -p6379 --script redis-info <target>Replace <target> with the host or range you're authorized to scan.
What runs on port 6379?
Port 6379 is the default for Redis, a high-performance in-memory data store used as a cache, message broker, and database. Applications connect over 6379 to read and write keys at very low latency. Redis speaks a simple text protocol and, crucially, has historically shipped without authentication enabled.
Why it matters for security
Redis is one of the most infamously exposed services on the internet. For years it bound to all interfaces with no password, so anyone who could reach 6379 had full read/write control. Worse, Redis can write files to disk, which turns an open instance into a remote code execution primitive — and beyond data theft, attackers routinely wipe exposed instances and demand ransom.
How it's attacked
Attackers scan for open 6379 and connect without credentials. They dump or
flush all data, then escalate to RCE via config rewrite: using
CONFIG SET and SAVE to plant SSH authorized_keys or cron jobs, or by
loading a malicious module. The result is frequently full control of the
host running Redis.
Hardening checklist
Bind Redis to localhost or a private interface, keep protected mode on,
and require authentication via requirepass or ACLs with a strong password.
Never expose 6379 to the internet — firewall it to trusted hosts only. Rename
or disable dangerous commands (CONFIG, FLUSHALL, MODULE), require TLS,
run Redis as an unprivileged user, and patch regularly. Use the nmap snippet
above to check exposure on hosts you are authorized to test.
Related ports
Frequently asked questions
- Does Redis require a password by default?
- Historically no — early Redis had no authentication, which led to mass compromises. Always set requirepass or ACLs, bind to localhost, and keep protected mode enabled.
- How does an exposed Redis lead to remote code execution?
- An unauthenticated attacker can use CONFIG SET/SAVE to write files such as SSH authorized_keys or cron jobs, or load a malicious module, turning data access into full host compromise.