Port 6379 (Redis): Risks, Attacks and How to Secure It

Written by Ruben Selby, founder and penetration tester at Wolfcore. Last reviewed 13 November 2026.

In one sentence: Port 6379 is where Redis, a very fast in-memory data store used for caching and sessions, listens, and it should only ever be reachable by your own application servers, never by the internet.

What runs on this port

Redis stores data in memory so applications can read it quickly. Websites use it as a cache, as a store for login sessions, as a queue for background jobs and for counting things such as rate limits. By default it listens on TCP port 6379.

Redis was built on an assumption. The Redis security documentation says Redis is designed to be accessed by trusted clients inside trusted environments, and that it is usually not a good idea to expose it directly to the internet. It is not a public service like a web server.

Why attackers look for it

Attackers and researchers run internet-wide scans that try every public address on well-known ports. A Redis server that answers on 6379 from the open internet shows up in those scans and in search engines for exposed devices. No skill is needed to find it. The question is only what happens when someone connects.

How it gets attacked

The weaknesses are mostly about configuration, not clever code.

No password. The Redis documentation says that a single FLUSHALL command can be used by an external attacker to delete the whole data set. Anyone who can reach an unprotected instance can read, change or wipe what it holds.
Protected mode switched off. Since version 3.2.0, Redis enters protected mode when it runs with the default configuration and no password, and then only answers local connections. The documentation notes that an administrator can still ignore the error and disable protected mode or bind all the interfaces. A common mistake is to switch it off just to make a connection work.
A weak or shared password. The documentation warns that Redis is fast, so an outsider can test many passwords per second. A short password is not enough.
Unencrypted traffic. The AUTH command, like every other command, is sent unencrypted by default, so it does not protect against someone who can eavesdrop on the network. TLS is optional and has to be turned on.
The CONFIG command. The documentation says a client that can use CONFIG can change the working directory and the name of the dump file, so Redis can write files to paths the client chooses. It describes this as a security issue that may lead to compromising the system or running untrusted code as the user Redis runs as.

Advisory for this entry: the Redis security documentation page above. We have not cited a specific CVE here because we did not open a primary advisory page for one in this review.

Who it affects and how badly

This port matters to any organisation that runs its own web applications, in any country. SaaS start-ups, retailers with their own online shop and agencies hosting client sites are the usual owners of Redis.

Sole trader to 10 staff: a web developer’s cloud server with Redis left open could lose a cache, which is an annoyance, or sessions and stored tokens, which is a real problem for the client’s customers.
10 to 50 staff and 50 to 250: sessions, API responses and job queues may sit in Redis. Losing them means downtime and logging everyone out. Treat Redis data as only as harmless as its most sensitive key.
Regulated and 250 plus: if personal data sits in Redis, an exposed instance can be a personal data breach, with the reporting duties that follow.

The UK angle

The NCSC’s Cyber Essentials requirements (v3.3, April 2026) say the aim of the firewall control is to make sure only secure and necessary network services can be accessed from the internet. Firewalls must block unauthenticated inbound connections by default. Inbound rules must be approved, documented with the business need, and removed when no longer needed. An open 6379 fails that test on its face. Cyber Essentials also covers cloud servers you configure yourself (IaaS), so a Redis server on a rented virtual machine is in scope.

What we check on a test

Method only, no findings claimed:

Whether 6379 (and the cluster and Sentinel ports) answer from outside, checked against your own asset list.
Whether a connection needs authentication, and whether it uses named users or one shared password.
Whether protected mode, the bind setting and TLS are set as intended.
Whether risky commands such as CONFIG are restricted by access control lists.
What the instance holds, and whether sessions or keys in it would matter if read.

How to check whether yours is exposed

List every server you run and note whether Redis is installed, including inside containers.
Read your firewall or cloud security group rules and look for any rule that allows 6379 from anywhere.
On the server, check the bind setting in redis.conf and confirm it lists only loopback or private addresses.
Run the free scan at https://wolfcore.co.uk/free-web-vulnerability-scan/ for what your public site shows. Checking your own firewall rules is safe and is the reliable method.

How to secure it

Block 6379 at the firewall or cloud security group for everyone except named application servers.
Bind Redis to loopback or a private address in redis.conf, as the Redis documentation shows.
Leave protected mode on. Do not switch it off to fix a connection error.
Use Redis ACLs (introduced in Redis 6) with named users instead of one shared requirepass password, and make passwords long.
Turn on TLS for client, replication and cluster traffic.
Use ACL rules to stop normal clients using CONFIG. The old rename-command method is described as deprecated.
Run Redis as an unprivileged user, as the documentation recommends, and keep it patched.

Frequently asked questions

Does Redis need a password? The documentation describes passwords as a layer of redundancy in case the firewall fails. Network restriction comes first.

What does protected mode do? With default settings and no password, it makes Redis answer only local connections.

Is a Redis password enough on its own? No. Commands, including AUTH, are sent unencrypted unless TLS is enabled.

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. See manual penetration testing and start with the free web vulnerability scan.

Port 6379 (Redis): what it is, how it is attacked and how to secure it