A self-replicating, Rust-coded botnet has spent at least six months quietly enrolling enterprise Google Kubernetes Engine clusters through exposed Redis instances — not launching attacks, not stealing data, just waiting. A FortiGuard Labs report published May 20, 2026, documents how P2PInfect built a headless peer-to-peer fleet inside cloud-native infrastructure. FortiGuard characterizes the operation as “a botnet-for-hire platform, focusing heavily on scale and maximum network enrollment.”
The Redis Exploitation Chain
P2PInfect gains entry through Redis instances that Kubernetes administrators have left exposed outside cluster network boundaries — a misconfiguration that gives attackers direct network access to what should be an internal-only service. Once operators reach an exposed Redis node, they issue the SLAVEOF command, a legitimate Redis replication feature that instructs the node to treat an attacker-controlled server as its primary data source. That replication channel then pushes arbitrary modules to the victim node, achieving remote code execution without exploiting any flaw in Redis’s core networking logic.
CVE-2022-0543: A CVSS 10.0 Redis Flaw Still Present in Containerized Workloads
The primary vulnerability driving P2PInfect compromises is CVE-2022-0543, a Lua sandbox escape in Redis rated CVSS 10.0. The patch has been available since 2022, but FortiGuard found the flaw still present across enterprise containerized workloads. The reason: many organizations build container base images once and deploy them without running subsequent security patching cycles, meaning containers that were current at launch silently accumulate unpatched CVEs over time. Two additional vulnerabilities appear in different phases of the campaign: CVE-2025-11953, known as Metro4Shell, an unauthenticated remote code execution flaw in the React Native Metro development server; and CVE-2025-49844, named RediShell, a separate Redis Lua sandbox escape.
Inside the P2PInfect Peer-to-Peer Command Network
P2PInfect communicates through a decentralized peer-to-peer mesh rather than a traditional centralized command-and-control server. Nodes exchange instructions using ChaCha20 stream cipher with zero-byte keys and nonce — a configuration FortiGuard researchers describe as “purely decorative obfuscation.” It produces the appearance of encrypted traffic while providing no meaningful protection and no single endpoint that defenders can monitor or disrupt.
The structural consequence is that there is no command server to take down. Seizing or blocking one node, or even a cluster of nodes, leaves the wider fleet intact and capable of receiving future instructions. FortiGuard documented “significant indicator overlap” across multiple enterprise client compromises, confirming that the campaign operates with coordinated targeting rather than opportunistic mass scanning by unrelated actors.
P2PInfect’s Dormant Enrollment Strategy Inside GKE Clusters
Once a Kubernetes node is enrolled, it enters a sustained dormant state. During FortiGuard’s observation window, no second-stage payload was deployed to any enrolled node. The nodes sat inside enterprise GKE clusters generating no visible malicious activity — no file encryption, no miner processes, no anomalous outbound data transfers — which is exactly why one confirmed compromise ran for six months before detection. P2P mesh traffic blended with legitimate cluster-to-cluster communications and produced no behavioral signal that standard alerting thresholds are configured to catch.
Earlier P2PInfect variants deployed Monero cryptocurrency miners and ransomware payloads, per FortiGuard’s prior campaign analysis. FortiGuard’s botnet-for-hire framing suggests enrolled Kubernetes nodes may be staged for rental to third-party criminal operators — potentially ransomware groups that need cloud-native execution infrastructure at scale.
What an Activated Fleet Represents for Cloud Workloads
Kubernetes manages production compute for thousands of enterprises. A P2PInfect fleet activated with ransomware instructions could encrypt or destroy cloud-native workloads across multiple GKE cluster fleets in a single coordinated event. Unlike a traditional ransomware deployment that requires endpoint-level execution on each machine, a Kubernetes-native attack can target container orchestration itself — stopping workloads, destroying persistent volumes, or encrypting data across an entire cluster from inside its own network fabric.
The six-month dwell time points to a specific detection gap: cloud-native security monitoring configured to alert on active malicious behavior will not fire on a node that is doing nothing except maintaining P2P mesh membership. Detecting pre-positioned threats of this kind requires behavioral baselining on cluster network traffic, tracking unexpected module loads into Redis processes, and auditing which Redis instances are reachable from outside cluster-defined network policies.
Closing the entry path requires auditing all Redis deployments for external accessibility, patching CVE-2022-0543 and related Lua escape vulnerabilities across all container base images through a regular update cycle, and enforcing Kubernetes network policies that restrict Redis service ports to intra-cluster communication only.
