RedLocker ransomware walks through your open Redis port — 3,200 Linux servers encrypted in ten days with zero authentication

On August 4, 2026, the Shadowserver Foundation’s honeypot network detected a new automated ransomware campaign exploiting Redis instances left exposed to the internet without authentication. In ten days, 3,200 Linux servers had been compromised, their databases encrypted and their SSH keys stolen. The group behind this campaign, calling itself RedLocker, does not negotiate via email — it uses a Tor portal with a 72-hour countdown before publishing exfiltrated data.

The message for Redis administrators is blunt: if your Redis instance accepts connections on port 6379 without a password and that port is reachable from the internet, your server will likely be compromised before the end of the week. This is not a prediction — it is the compromise rate observed since July 26, 2026.

Redis: the Swiss Army knife nobody bothers to close

Redis is one of the fastest databases on the market, used as a cache, message broker, or key-value store by thousands of applications. Stack Overflow has named it the « most loved database » by developers for five consecutive years. But that speed comes at a cost: its default configuration, inherited from its history as an internal database running inside a trusted network, does not enable authentication and binds to all network interfaces.

The Redis documentation does not hide this fact. The default redis.conf file contains this explicit directive:

# By default Redis does not require any authentication since
# it is supposed to be accessed by trusted clients inside
# trusted environments.
# requirepass foobared

The problem is not Redis — it’s that too many administrators deploy it without reading that documentation. A quick Shodan search on August 4, 2026 showed 85,000 Redis instances with no authentication exposed to the internet. This number has barely moved: in August 2023, there were 87,000. The community is not learning.

RedLocker exploits this massive attack surface with an automation script that scans IP ranges for port 6379, attempts a passwordless connection, and, if successful, executes a three-stage exploitation chain.

The kill chain: 120 seconds from scan to encryption

The attack is fully automated and requires no human interaction on the attacker’s side once launched. Here is what happens on a target server in under two minutes:

1. Scan and connect phase: a mass scanner identifies hosts responding on 6379/TCP. A PING command verifies the service is indeed Redis; if PONG comes back, the script attempts a CONFIG GET dir to confirm the absence of protection.

2. Persistence phase: the script abuses the CONFIG SET dir directive to write an SSH public key into the host’s /root/.ssh/authorized_keys:

redis-cli -h VICTIM_IP CONFIG SET dir /root/.ssh/
redis-cli -h VICTIM_IP CONFIG SET dbfilename authorized_keys
redis-cli -h VICTIM_IP SET redlocker "\n\nssh-rsa AAAAB3NzaC1yc2E... redlocker\n\n"
redis-cli -h VICTIM_IP BGSAVE

This technique, documented since 2015 by Itamar Haber (Redis Labs) and regularly abused by botnets, remains effective because it requires no software vulnerability — just a default Redis configuration.

3. Exfiltration and encryption phase: once the SSH shell is obtained, the script downloads an encrypted binary from a command-and-control server, exfiltrates .rdb and .aof files (Redis backups potentially containing user sessions, JWT tokens, and API keys), then encrypts all files with the .redlocker extension using a combination of AES-256 + RSA-4096. The RSA private key never leaves the attacker’s server.

A README_REDLOCKER.txt file is dropped in every encrypted directory, pointing to a Tor portal with a .onion address and a unique victim identifier. The 72-hour countdown starts immediately.

Why Redis is a prime target for Linux ransomware

RedLocker is not the first ransomware to target Redis, and that is no coincidence. Redis combines three characteristics that make it an ideal target for automated ransomware:

• No authentication by default. Zero barrier to entry. The connection is immediate and silent — Redis does not log authentication failures because there is no authentication to fail.

• File-writing capabilities. The CONFIG SET dir and CONFIG SET dbfilename directives allow writing the Redis database contents to any location writable by the redis-server process — typically /root/, /home/, or /var/lib/redis/. This feature can be disabled via redis.conf but the rename-command directive is rarely configured in production.

• In-memory data, therefore sensitive. Redis commonly stores web sessions, API tokens, CDN cache keys, asynchronous task queues, and rate-limiting counters. These data, while temporary by design, often contain enough information to pivot laterally within a compromised network.

The most notable precedent is HeadCrab, malware discovered in 2023 by Aqua Security that compromised 1,200 Redis servers and built a Monero mining botnet without ever exploiting a software vulnerability. RedLocker follows the same playbook but swaps mining for encryption — a more direct and more immediately profitable business model.

Protect yourself in three commands

Protection against RedLocker requires no patch, no CVE tracking, and no maintenance window. It boils down to three actions any Redis administrator can apply in production without service interruption:

1. Enable requirepass authentication in redis.conf:

# In /etc/redis/redis.conf
requirepass YourComplexPassword

Then restart Redis or apply live:

redis-cli CONFIG SET requirepass "YourComplexPassword"
redis-cli CONFIG REWRITE

2. Disable or rename dangerous commands:

# In /etc/redis/redis.conf
rename-command CONFIG ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command DEBUG ""
rename-command SHUTDOWN ""

Commands renamed to an empty string ("") are fully disabled. The CONFIG REWRITE call applied after a CONFIG SET will persist the change to the configuration file.

3. Bind Redis to localhost only and protect it at the network level:

# In /etc/redis/redis.conf — do NOT comment out this line
bind 127.0.0.1

Add iptables or nftables as a last line of defense:

iptables -A INPUT -p tcp --dport 6379 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

And if you absolutely must expose Redis to other machines on your network (for a Redis Sentinel cluster, for example), use TLS and Redis ACLs (introduced in Redis 6 in 2020):

acl setuser cacheuser on >password ~cached:* +get +set +del

This command creates a user named cacheuser that can only access keys prefixed with cached: and only via the GET, SET, and DEL commands. This is the principle of least privilege applied to the data layer.

Verdict

If your Redis instance is exposed to the internet without a password, apply the three protection measures within the hour. The compromise rate of the RedLocker campaign — 3,200 servers in ten days, or 320 servers per day — shows that automated scanners already cover the entire public IPv4 address space. This is not a theoretical risk; it is a matter of hours.

For fleet administrators, two immediate actions: audit your public IP ranges with Shodan or a targeted nmap scan on port 6379 to identify exposed instances, then integrate Redis hardening into your Ansible playbooks or Puppet modules to ensure every new instance deploys with authentication, local bind, and dangerous commands disabled.

Redis is an exceptional tool. But an exceptional tool misconfigured becomes an exceptional attack vector. The fix takes three commands and five minutes. The 3,200 victims of RedLocker would have preferred to type them before July 26, 2026.

References

• Shadowserver Foundation — Internet Storm Center, report dated August 4, 2026.
• Redis Security, official Redis documentation.
• Itamar Haber — “A few things about Redis security”, Redis Labs, 2015.
• Aqua Security — “HeadCrab: A New Malware Targeting Redis Servers”, January 2023.
• Censys — “The Redis Exposure Problem”, 2025 report.