RedisRaider Cryptojacking Campaign Hijacks Thousands of Unauthenticated Redis Servers for Monero Mining
Researchers tracked a campaign (RedisRaider) that scanned 12,966 Redis hosts and hijacked unauthenticated servers — 2,342 per GBHackers, 3,562 per Cyber Security News (sources disagree) — using cron persistence to deploy XMRig Monero miners; defenders urged…
Researchers have detailed a large-scale cryptojacking campaign, tracked as RedisRaider by GBHackers, that scans IPv4 ranges for Redis services exposed on TCP port 6379 and hijacks instances that accept unauthenticated connections to deploy XMRig-based Monero miners. Both reports agree the operation scanned 12,966 candidate hosts and relied on cron-based persistence, but they diverge on scale and mechanism: GBHackers says 2,342 of the scanned hosts were confirmed to accept commands without authentication, while Cyber Security News reports 3,562 distinct Redis servers compromised; GBHackers describes abuse of native Redis commands (CONFIG SET dir/dbfilename, SET, BGSAVE) to write cron entries into /etc/cron.d or /var/spool/cron, while Cyber Security News describes master-replica replication (REPLICAOF) planting a cron task that downloaded and ran XMRig every five minutes. The miner reaches a Monero mining pool — pool.moneroocean.stream per GBHackers — over encrypted port 443 and hides among temporary files, per Cyber Security News. GBHackers also notes campaign branches including SSH authorized-key injection, Lua probing, and WordPress spraying, and lists C2 IP 188.245.99.156 as an IOC; Cyber Security News says researchers found an exposed operator directory with 147 files including logs. Impact includes high CPU usage, elevated cloud bills, and data-loss risk from altered Redis persistence settings. Cyber Security News says affected Redis versions span 2.8.17-7.2.0 and that the campaign exploited misconfiguration rather than a specific CVE; GBHackers separately cites CVE-2026-81934, a Redis TLS use-after-free enabling unauthenticated command execution fixed in 8.2.9, 8.4.6, 8.6.6, 8.8.2, and 8.10.1, as patching guidance. Defenders are advised to require Redis authentication, restrict REPLICAOF, inspect cron directories, and harden or patch exposed instances. Both reports were published 2026-09-09 and attribute the research to a team named 'Hunt.io' by GBHackers and 'Hunters.io' by Cyber Security News.
- Both reports agree the campaign scanned 12,966 candidate Redis hosts, targeting services on TCP port 6379 that accept unauthenticated connections (GBHackers; Cyber Security News).
- Compromised-host counts differ: GBHackers reports 2,342 of 12,966 hosts confirmed to accept commands without authentication; Cyber Security News reports 3,562 distinct Redis servers compromised.
- Both reports agree on cron-based persistence and an XMRig Monero payload, but disagree on mechanism: GBHackers describes abuse of CONFIG SET dir/dbfilename, SET, and BGSAVE to write cron entries into /etc/cron.d or /var/spool/cron; Cyber…
- Mining infrastructure: GBHackers lists pool.moneroocean.stream as the mining pool and 188.245.99.156 as C2; Cyber Security News says the miner connects to the pool over encrypted port 443 and hides among temporary files.
- Additional campaign branches per GBHackers: SSH authorized-key injection, Lua probing, and WordPress spraying.
- Cyber Security News reports researchers found an exposed operator directory containing 147 files, including logs.
- Per Cyber Security News, affected Redis versions span 2.8.17-7.2.0, and the campaign exploited misconfiguration rather than a specific CVE.
- GBHackers separately references CVE-2026-81934, a Redis TLS use-after-free allowing unauthenticated command execution, fixed in 8.2.9, 8.4.6, 8.6.6, 8.8.2, and 8.10.1, and advises patching — cited as hardening guidance, not necessarily the…
Coverage timelineoldest first · each row is one article
- · 7d agoMassive Redis Cryptojacking Campaign Hijacks Thousands of Linux Servers
GBHackers· 60
RedisRaider cryptojacking campaign compromises thousands of exposed, unauthenticated Linux Redis servers using cron persistence to deploy XMRig Monero miners.
Vulnerabilities in this storyAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-81934 | Use-After-Free in Redis TLS Pending-Data Handling Enables Unauthenticated RCE Redis contains a use-after-free flaw (CWE-416) in the tlsProcessPendingData() function, which manages the TLS pending-data list, and it affects only deployments that are configured with TLS support. A remote, unauthenticated attacker who can reach the TLS-enabled Redis service can trigger the flaw; the CVSS 4.0 vector scores it as high attack complexity with present attack requirements, suggesting timing- or condition-dependent exploitation. Successful exploitation may allow the attacker to execute arbitrary commands with the privileges of the Redis server process. Any Redis installation running with TLS enabled is in scope, though affected version ranges are not specified in the available data. No public proof-of-concept exists and the flaw is not in CISA KEV (EPSS 0.4%), but related headlines note a massive Redis cryptojacking campaign hijacking thousands of Linux servers, so Redis deployments are actively targeted in the wild even if this specific flaw's exploitation is not yet confirmed. Do: Identify Redis instances with TLS enabled (e.g., tls-port or cluster TLS configuration) and restrict network access to trusted clients, since only TLS-enabled deployments are affected. Upgrade to a patched Redis release when the vendor publishes one (affected version ranges are not specified in the available data). In the meantime, monitor Redis servers for indicators of the cryptojacking activity reported against Redis deployments in the wild. | 7.5 | <1% |
| massLikely hundreds of thousands of TLS-enabled deployments worldwide (Redis runs in millions of environments and public internet scans have shown hundreds of… |