P2PInfect Botnet Exploits Exposed Redis to Compromise Kubernetes Clusters

Key Takeaways

• The P2PInfect botnet is now strategically targeting Kubernetes clusters by exploiting misconfigured Redis instances.
• The malware establishes a persistent, dormant foothold within cloud environments, making detection challenging.
• Initial entry often abuses Redis’s replication feature or leverages CVE-2022-0543, a critical Lua sandbox escape vulnerability (CVSS 10.0).
• Compromised Kubernetes nodes join a decentralized peer-to-peer network, awaiting further instructions from botnet operators.

P2PInfect Botnet Shifts Focus to Kubernetes Clusters via Exposed Redis

The P2PInfect botnet, a sophisticated peer-to-peer malware written in Rust and active since mid-2023, has evolved its attack methodology to specifically target cloud infrastructure. Recent observations indicate the botnet is now actively compromising Kubernetes clusters by exploiting Redis instances that are left exposed to the internet.

This development signifies a strategic escalation for P2PInfect, moving beyond typical server infections to establish persistent and often dormant footholds within managed cloud environments. This shift poses a significant threat, as a single misconfiguration can silently open the door to a long-term compromise of critical cloud resources.

Exploiting Redis for Cloud Infiltration

P2PInfect has a documented history of targeting Redis, an in-memory data store frequently deployed in web applications and cloud settings. The malware capitalizes on misconfigured Redis setups, often by manipulating the database’s built-in replication feature to enroll compromised nodes into its peer-to-peer mesh network. Once integrated, these infected hosts communicate with other botnet peers, expanding the network while awaiting further commands.

Additionally, the botnet leverages CVE-2022-0543, a severe Lua sandbox escape vulnerability boasting a perfect CVSS score of 10.0, to achieve code execution on susceptible Redis instances.

Researchers at Fortinet’s FortiGuard Labs detailed their analysis of several P2PInfect compromises within Google Kubernetes Engine (GKE) clusters. Their findings revealed a multi-stage infection process that commences with an accessible Redis service and culminates in a dormant, yet fully enrolled, botnet member. This underscores how seemingly minor misconfigurations can lead to significant and enduring threats within cloud ecosystems.

The Infection Chain: From Exposure to Dormancy

The compromise initiates when a Redis instance within a Kubernetes cluster is made accessible without appropriate access controls. Attackers connect to this exposed service and issue the SLAVEOF command, effectively turning the legitimate Redis node into a follower of a malicious server controlled by the threat actors. This manipulation tricks the node into loading arbitrary modules from the attacker’s infrastructure, granting them a direct avenue for code execution within the container.

Between November 2025 and February 2026, FortiGuard Labs observed compromised Redis hosts establishing outbound peer-to-peer mesh connections to various external nodes. This decentralized network is utilized by the botnet to distribute payloads, collect environmental data, and maintain communication without relying on a centralized command-and-control server. This distributed architecture significantly complicates disruption efforts, as there is no single point to block or shut down.

Upon enrollment into the P2P mesh, infected nodes typically enter a quiescent state, characterized by minimal activity—a behavior Fortinet researchers described as “dormant.” These bots appear to lie in wait, prepared to receive tasks from operators at any moment. This patient approach suggests the campaign may be focused on building a substantial infrastructure for future, potentially more impactful, exploitation rather than immediate deployment of payloads like ransomware or cryptocurrency miners.

Detection Challenges and Broader Implications

The dormant phase of P2PInfect within Kubernetes environments presents a significant detection challenge. Conventional security tools are often designed to flag high-volume or “noisy” activities. However, a quietly enrolled bot with limited outbound traffic can evade detection for extended periods. Within a bustling cluster running numerous services, an infected container can seamlessly blend in without triggering immediate alarms.

P2PInfect has a well-documented history of escalating its capabilities. Previous versions of the malware have been observed deploying ransomware, which encrypted files and demanded Monero for decryption, as well as cryptocurrency miners that silently consumed compute resources from infected hosts. Even in its dormant state, an enrolled node exposes organizations to severe risk, as a damaging payload could be delivered at any time.

Given that Kubernetes clusters frequently power critical business applications and store sensitive workload data, a compromised node represents a serious and escalating risk. Organizations operating GKE or similar managed platforms without robust network controls are particularly susceptible to this type of covert, long-term infection.

What You Should Do

• Isolate Redis Instances: Never directly expose Redis instances to the internet. Implement strict network policies to ensure Redis is only accessible from trusted internal services.
• Enforce Network Segmentation: Apply granular network policies within Kubernetes clusters to limit pod-to-pod communication, adhering to the principle of least privilege.
• Regular Audits: Conduct frequent audits for unauthorized outbound connections from pods and services within your clusters.
• Deploy Runtime Security: Utilize runtime security tools that can detect and flag abnormal container behavior, even for dormant or low-activity threats.
• Patch and Update: Keep Redis fully patched to mitigate known vulnerabilities, including CVE-2022-0543.
• Restrict Replication: In production environments, restrict or disable the Redis replication feature if it is not explicitly required, as it is a primary vector for P2PInfect.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.