Redis (internet-exposed, no authentication)

Attacker logs show 3,562 internet-exposed Redis servers with no authentication taken over via rogue replication (Redis)

Hunt.io's parse of the attacker's own logs shows this is not theoretical volume: 22–26% of a 12,966-host internet sweep fell, and nearly three quarters of hosts already known to accept unauthenticated commands were taken over, with the operator's tooling live as recently as late June 2026 and the same Monero wallet traced back to February 2026 — every unauthenticated Redis on a public IP is on somebody's target list right now.

Hunt.io recovered a cryptomining operator's full working directory and parsed the campaign logs directly: 3,562 distinct Redis servers were compromised out of 12,966 targeted, using the SLAVEOF/replicaof rogue-replication technique to load attacker content, then cron injection to run XMRig. Victims ran everything from Redis 2.8.17 to 7.2.0 on old and current Linux, so the enabling weakness is not a version-specific bug but Redis exposed to the internet with no password or ACL — anyone who can reach port 6379 can issue administrative commands and obtain code execution as the Redis user. Secondary branches (AOF-based SSH authorized_keys injection, MongoDB db.eval() sandbox probing) returned nothing at scale, and a WordPress credential-spray-to-webshell chain was recovered but not quantified. There is no CVE and no vendor flaw to patch; the fix is configuration and network exposure.

Affected: Redis instances reachable on TCP/6379 without authentication; confirmed victims ran Redis 2.8.17 through 7.2.0 on Linux from EOL RHEL/CentOS 6 to current Ubuntu kernels.; MongoDB hosts with legacy db.eval() enabled (468 scriptable, 0 confirmed compromised).; WordPress sites targeted via credential spraying to webshell (not quantified).

From outside your network run `redis-cli -h ping` and `redis-cli -h info server` — a PONG or version output without AUTH means you are in the exact target population; also scan your ranges for open 6379/16379. On each instance check `CONFIG GET requirepass`, `CONFIG GET protected-mode`, `CONFIG GET bind`, `CONFIG GET dir`/`dbfilename` (attackers repoint these at /var/spool/cron) and `INFO replication` for an unexpected master_host. For compromise: look for cron entries in /var/spool/cron/* and /etc/cron.d fetching remote scripts, unexpected keys in the Redis keyspace, entries appended to ~/.ssh/authorized_keys for the redis or root user, high-CPU miner processes (XMRig or renamed), and outbound connections to mining pools; Hunt.io lists indicators including the staging host 188.245.99.156 and an earlier kit at 194.48.248.105.

Set `bind 127.0.0.1` (or a private address), keep `protected-mode yes`, set a long `requirepass` and per-application ACL users, and firewall 6379/16379 to explicit client IPs; never expose Redis through a public load balancer or 0.0.0.0. Disable or rename the dangerous administrative commands with `rename-command` (SLAVEOF/REPLICAOF, CONFIG, MODULE LOAD, DEBUG, EVAL) where your application does not need them, run Redis as an unprivileged user with no cron or SSH write access, and upgrade off end-of-life Redis and end-of-life host OSes. Any instance found reachable without auth should be rebuilt rather than cleaned: remove attacker cron jobs and SSH keys, rotate credentials and keys stored in the keyspace, and check for other footholds.