Is port 6379 (Redis) exposed to the internet without a password?
Port 6379 is Redis's default port, and Redis ships with no password required to connect, on the assumption that only trusted clients inside a trusted network will ever reach it. A 2018 Imperva study of internet-reachable Redis servers found that roughly 75% of the open instances it scanned were already compromised with malware — a stark illustration of how quickly an exposed, unauthenticated instance gets found and abused.
By AdminKit team, Netbase JSC · Updated October 23, 2026
Why Redis has no password by default
Redis’s own security documentation is explicit that it’s “designed to be accessed by trusted clients inside trusted environments,” with the expectation that an application layer, not Redis itself, handles access control for untrusted users. That’s a reasonable default for a database meant to sit behind an application server on a private network — it stops being reasonable the moment the server running it gets a public IP and the firewall rule isn’t as restrictive as assumed.
A real, documented pattern of abuse
This isn’t a hypothetical risk. In a 2018 study, Imperva scanned internet-reachable Redis servers and found that roughly 75% of the open, unauthenticated instances it could reach were already infected with malware, with attackers repeatedly installing SSH keys on compromised servers for persistent later access — one specific malicious key was found on thousands of separate Redis installations across more than two years, indicating a long-running, automated campaign rather than a one-off attack. Since then, researchers at Censys and others have repeatedly found tens of thousands of unauthenticated Redis servers exposed at any given time, abused to deploy cryptomining malware using nothing more than Redis’s own built-in configuration and replication commands — no exploit required.
How to check your own exposure
AdminKit’s planned open ports check is designed to test whether port 6379 on your own public IP responds from outside your network. Since Redis’s own protected-mode default (added in version 3.2.0) only blocks non-loopback connections when no password is set and no bind address is configured, it’s worth confirming directly rather than assuming the default is still active on your instance.
How to fix it
- Set a strong password using Redis’s AUTH mechanism or newer Access Control Lists — this alone stops the unauthenticated-connection pattern the Imperva and Censys research both describe.
- Bind Redis to a private or loopback interface instead of all interfaces, so it isn’t reachable from outside your own network regardless of firewall rules.
- Add an explicit firewall rule restricting port 6379 to only the application servers that need it.
See Open Redis and other unauthenticated databases: a quick exposure check for the full self-check walkthrough and why this same no-auth-by-default pattern shows up in other data stores too, including PostgreSQL and Elasticsearch when their own protections are left off, and in non-database services like an unauthenticated Docker API.
Defensive use only
Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
Why does Redis ship without a password by default?
Redis's own documentation says it's "designed to be accessed by trusted clients inside trusted environments," expecting an application layer — not Redis itself — to handle access control for untrusted users.
Is this a theoretical risk or does it actually get exploited?
Documented and ongoing — a 2018 Imperva study found roughly 75% of open, unauthenticated Redis servers it scanned were already infected with malware, and researchers have continued finding tens of thousands of exposed instances since.
Doesn't Redis's 'protected mode' handle this automatically?
Partially — since version 3.2.0, Redis refuses non-loopback connections by default when no password is set, but an administrator can disable this, misconfigure the bind address, or set a password without realizing protected mode then stops applying.
What's the fastest fix if I find my own instance exposed?
Set a password with Redis's AUTH mechanism or newer Access Control Lists, bind Redis to a private or loopback interface, and add a firewall rule restricting the port — all three together, not just one.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.