Exposed Redis Instance
An exposed Redis instance is a Redis key-value server reachable from untrusted networks (typically TCP 6379) without authentication, letting anyone who connects read and overwrite all data and, via CONFIG SET plus SAVE, write arbitrary files to achieve remote code execution.
Redis was designed to live on a trusted, private network behind your application servers, so for years it shipped with no password and trusted every client that could open a socket. That design assumption breaks the moment the listener lands on a public interface. When a Redis port answers from the open internet, the attacker does not need an exploit or a stolen credential. The protocol itself, working exactly as documented, hands them your cache, your session store, and frequently a shell on the host.
Reviewed by Ameya Lambat
Security Research Contributor, Legba
Reviewed 2026-05-28 · Updated 2026-05-28
What it is
Redis (REmote DIctionary Server) is an in-memory key-value data store used for caching, session storage, queues, rate limiting, and pub/sub messaging. It speaks the RESP (REdis Serialization Protocol) over TCP, conventionally on port 6379. By default Redis has no authentication system: any client that can reach the port may issue any of its 200-plus commands. An exposed Redis instance is one where that port is reachable from an untrusted network segment (the internet, a guest VLAN, or a co-tenant cloud subnet) without a requirepass password or an ACL (Access Control List) gating access. Redis added protected mode in version 3.2 to refuse external connections when no password is set and the server is not bound to loopback, but operators routinely disable it, set requirepass to an empty or weak value, or bind to 0.0.0.0 with an open firewall, all of which re-expose the service.
Treat an internet-facing Redis with no auth as an already-conceded host, not a future risk. Everything in the keyspace, including session tokens, cached personal data, and queued jobs, can be exfiltrated or silently altered, so an attacker can hijack live user sessions or poison cached authorization decisions without tripping a login alarm. Worse, Redis can be turned into a code-execution primitive: using CONFIG SET to redirect the data directory and dump filename, then SAVE or BGSAVE, an attacker writes attacker-controlled bytes to disk, classically an SSH authorized_keys file, a cron entry, or a web shell, converting a data leak into full server takeover. The same path is the workhorse of mass cryptojacking campaigns documented by Trend Micro, where exposed Redis servers are conscripted to mine cryptocurrency and pivot deeper. If your Redis is on a Debian or Ubuntu package, the actively exploited Lua sandbox escape CVE-2022-0543 (CVSS 10.0, listed in the CISA Known Exploited Vulnerabilities catalog) gives unauthenticated RCE with a single EVAL command. The loss is not abstract: data theft, ransomware staging, regulatory exposure for leaked personal data, and a compromised host inside your network are the realistic outcomes of leaving this open.
At a glance
How attackers find and exploit it
- Discover the listener at internet scale by scanning TCP 6379 (and common alternates like 6380 or container-mapped high ports) with masscan or zmap, then confirm Redis with an unauthenticated INFO or PING probe; search engines such as Shodan and Censys already index responsive instances.
- Send INFO over RESP and read the unauthenticated banner: fields like redis_version, os, run_id, and connected_clients fingerprint the exact build and OS, and the absence of a NOAUTH error confirms no password is required.
- Enumerate the data directly with KEYS *, SCAN, DBSIZE, and type-specific reads (GET, HGETALL, LRANGE) to exfiltrate session tokens, cached PII, API keys, and queued jobs, or run FLUSHALL to destroy or ransom the keyspace.
- Pivot to file write for RCE: issue CONFIG SET dir /root/.ssh, CONFIG SET dbfilename authorized_keys, set a key to an attacker SSH public key, then SAVE so the RDB dump lands an authorized_keys file; alternate targets are /var/spool/cron for a reverse-shell cron job or a web root for a PHP/JSP shell.
- On Debian/Ubuntu packages, skip the file-write dance and exploit CVE-2022-0543 by sending a crafted EVAL Lua script that escapes the sandbox via package.loadlib for direct unauthenticated code execution.
- Escalate persistence and lateral movement with master-slave (SLAVEOF/REPLICAOF) replication abuse and MODULE LOAD to load a malicious .so module, a well-documented technique for loading attacker code into Redis 4.x/5.x, then deploy a cryptominer or C2 implant.
How to detect it on your surface
- Inventory every host and container that runs Redis (or compatible forks like KeyDB and Valkey) and map which network interface each binds to; flag any bound to 0.0.0.0 or a routable address rather than 127.0.0.1 or a private cluster interface.
- From an untrusted vantage point (an external scanner or a separate cloud account), attempt a TCP connection to 6379 and the alternate ports your deployments use, and record any that complete the handshake.
- On each reachable instance, send PING and INFO without credentials; a +PONG reply or a populated INFO block means authentication is not enforced for at least some commands.
- Audit configuration as code: grep redis.conf, Docker Compose files, Kubernetes manifests, and cloud security groups for protected-mode no, empty or default requirepass, missing ACLs, and ingress rules that allow 6379 from 0.0.0.0/0.
- Cross-check external scan engines (Shodan, Censys) for your IP ranges and ASNs to find instances exposed outside your sanctioned inventory, including shadow IT and orphaned cloud resources.
Detection signals
- An unauthenticated INFO command returns server fields such as redis_version, redis_mode, os, arch_bits, and run_id instead of a -NOAUTH Authentication required. error.
- PING returns +PONG and AUTH is reported as not set, or commands succeed before any AUTH is issued.
- The RESP banner and response framing on 6379 (CRLF-delimited replies prefixed with +, -, :, $, or *) identify a Redis-family server even when the version string is suppressed.
- INFO output shows protected_mode is absent or disabled, no configured requirepass, and connected clients from external IPs in CLIENT LIST.
- Anomalous keyspace artifacts that indicate prior abuse: keys whose values are SSH public keys or cron syntax, a dbfilename or dir reconfigured away from defaults, or unexpected loaded modules in MODULE LIST.
Validate before you report
- Confirm reachability and identity: open a RESP connection from outside the trust boundary and verify the server responds to PING with +PONG, distinguishing a live unauthenticated Redis from a closed or filtered port.
- Prove the missing-auth condition non-destructively by issuing a read-only command such as INFO server or CONFIG GET maxmemory; if it succeeds without AUTH, authentication is genuinely absent rather than merely suspected.
- Demonstrate write capability safely by setting and reading back a single benign canary key (for example SET legba:recon:canary <random-token> then GET), proving full read-write access without altering production data or invoking CONFIG SET/SAVE.
- Establish RCE potential without exploiting it: read CONFIG GET dir and CONFIG GET dbfilename to confirm the file-write parameters are settable and the process can reach a sensitive path, and check CONFIG GET requirepass returns an empty value, capturing these as evidence rather than writing any file.
- Record the full INFO fingerprint, the originating external IP, the reachable port, and timestamps as evidence so the finding is reproducible and attributable to a specific asset.
What looks like this but isn't
- A port that accepts TCP but immediately returns -NOAUTH Authentication required. to INFO or PING is authenticated, not exposed; the open socket alone is not the finding.
- A honeypot or a deliberately deployed canary Redis can mimic an open instance; correlate the run_id and host metadata against your real inventory before treating it as a production exposure.
- Some forks and proxies (KeyDB, Valkey, Twemproxy, or a TLS-only listener) answer on 6379 with different handshakes; verify you are talking to an actual command-accepting Redis rather than a TLS terminator that rejects plaintext RESP.
- An instance reachable only from a trusted bastion or VPN-scoped subnet that merely appears in a broad scan is not internet-exposed; confirm the reachable path actually originates from an untrusted network.
Remediation
- Immediately restrict the network path: bind Redis to 127.0.0.1 or a private cluster interface, and set firewall and cloud security-group rules to deny 6379 from all untrusted sources; this stops the active bleed before any further hardening.
- Enable authentication: set a long, random requirepass (or, on Redis 6+, define ACL users with least-privilege command and key permissions) and rotate any credentials, tokens, or session data that lived in the exposed keyspace, since you must assume it was read.
- Keep protected-mode yes enabled so a future misbinding cannot silently re-expose the service without a password.
- Patch the engine: upgrade to a current supported Redis release and, on Debian/Ubuntu, ensure the package fix for CVE-2022-0543 is applied; verify no malicious modules are loaded with MODULE LIST.
- Disable or rename dangerous commands for untrusted contexts using ACLs or rename-command (CONFIG, FLUSHALL, FLUSHDB, KEYS, EVAL, MODULE, SLAVEOF/REPLICAOF, DEBUG) so a future foothold cannot pivot to file write or replication abuse.
- Enable TLS for client and replication links and run Redis as an unprivileged, non-root user with a data directory that cannot reach SSH, cron, or web-root paths, limiting blast radius if write access is regained.
- Hunt for compromise on any instance that was exposed: inspect authorized_keys, cron tables, loaded modules, and running processes for miners or implants, and rebuild the host if tampering is confirmed.
Operational checklist
- Maintain an authoritative inventory of every Redis-family instance with its bound interface, version, and auth mode, and reconcile it against external attack-surface scans on a recurring schedule.
- Enforce authentication and protected mode by default in golden images, Helm charts, and Terraform modules so new deployments cannot ship without a password.
- Gate 6379 (and any alternates) at the network layer with deny-by-default security groups and microsegmentation, allowing only named application sources.
- Continuously monitor for unauthenticated INFO/PING success from external probes and alert on CONFIG SET dir/dbfilename changes, MODULE LOAD, and SLAVEOF/REPLICAOF to an unknown master.
- Track Redis CVEs and the CISA Known Exploited Vulnerabilities catalog, and apply engine and OS-package patches within your defined SLA.
- Rehearse credential and session rotation so that if an instance is found exposed, secrets that transited the cache can be revoked quickly.
What to do next
An exposed Redis on 6379 is not a finding you can schedule for next quarter: with no password, the protocol gives an attacker your data on the first connection and a path to a shell on the second. The job is not to know Redis exists, it is to know, with evidence, whether a specific instance is reachable, unauthenticated, and writable right now. Pull your external Redis inventory today, confirm each instance returns -NOAUTH from outside your trust boundary, and close any that do not before a scanner finds them first.
Methodology
Each finding-type guide is built from Legba Recon's real detection and validation logic, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.
FAQs.
References.
- 01Redis securityRedis
- 02CVE-2022-0543 DetailNIST National Vulnerability Database
- 03Known Exploited Vulnerabilities CatalogCybersecurity and Infrastructure Security Agency (CISA)
- 04
