P2PInfect botnet targets Kubernetes clusters through exposed Redis servers

P2PInfect is now being seen inside Kubernetes environments after attackers abused exposed Redis instances to gain a foothold in cloud clusters. FortiGuard Labs said the activity affected Google Kubernetes Engine environments and showed how one exposed Redis service can turn into a long-running botnet infection.

The botnet did not need a loud second-stage attack in the cases Fortinet examined. Instead, infected systems stayed enrolled in a peer-to-peer network and continued beaconing, giving attackers a quiet way to maintain access while waiting for future instructions.

According to FortiGuard Labs, one compromise lasted about six months. That makes the campaign especially concerning for teams that run Redis inside Kubernetes without strict network exposure controls.

How exposed Redis opened the door

The attack starts with a Redis instance reachable from the internet or from a network segment that attackers can access. Redis is widely used for caching, queues, session data, and fast application storage, but it can become dangerous when it runs without proper authentication and network restrictions.

The Redis security documentation warns that Redis is designed for trusted environments and should not be exposed directly to untrusted networks. That warning matters here because P2PInfect depends on weak exposure and misconfiguration to spread.

In the observed infection chain, attackers used Redis functionality to make a legitimate node follow a malicious server. That allowed the botnet to load attacker-controlled content and enroll the compromised system into its peer-to-peer mesh.

Attack stage	What happens
Initial exposure	A Redis instance inside or connected to a Kubernetes environment is reachable without enough access control.
Redis abuse	Attackers use Redis replication behavior to pull in malicious modules or payloads.
Bot enrollment	The infected node joins the P2PInfect peer-to-peer network.
Beaconing	The compromised system communicates with other peers instead of relying on one central command server.
Dormant stage	The bot remains available for future operator commands while generating limited noise.

Why Kubernetes makes the risk worse

A single exposed Redis instance can affect more than one workload when it sits inside a Kubernetes environment. Clusters often connect many services, containers, secrets, service accounts, and internal APIs, so one weak entry point can create a path toward broader discovery.

The Kubernetes network policy documentation explains how teams can control traffic between pods and network endpoints. Without those controls, an infected workload may have more internal reach than it should.

This is why the P2PInfect activity matters even when it appears quiet. A dormant bot inside a cloud cluster can still give attackers a foothold for later payloads, reconnaissance, or movement when they decide to activate it.

P2PInfect has targeted Redis for years

P2PInfect is not a new malware family. Unit 42 first detailed the Rust-based peer-to-peer worm in 2023, noting that it targeted Redis and could infect both Linux and Windows systems.

The older Unit 42 analysis described P2PInfect as scalable and cloud-friendly because of its peer-to-peer design. That design still matters today, since infected systems can communicate with other peers without depending on one easy-to-remove command-and-control server.

The malware has also evolved beyond simple propagation. Fortinet notes that P2PInfect has previously been associated with ransomware, cryptomining, and other follow-on activity, although those payloads were not seen in the GKE cases discussed in the latest research.

CVE-2022-0543 remains part of the Redis threat picture

P2PInfect has also been linked to Redis exploitation involving CVE-2022-0543, a Lua sandbox escape vulnerability that affected certain Debian-based Redis packages. The flaw has a CVSS score of 10.0, which places it in the critical category.

The CVE record describes the issue as a Redis vulnerability involving the Lua library packaging on Debian and Ubuntu systems. Attackers have abused it in the past because it can allow remote code execution when Redis is exposed and vulnerable.

For Kubernetes operators, the lesson is broader than one CVE. Patching matters, but patching alone does not fix public exposure, weak authentication, unrestricted replication, or missing network segmentation.

What makes the botnet hard to remove

P2PInfect uses a peer-to-peer model, which makes it harder to disrupt than malware that depends on one central command server. Blocking a single domain or IP address may not stop communication if the infected node can reach other peers.

Fortinet observed outbound mesh connections from compromised Redis hosts over several months. The Fortinet report also said the activity was repeatedly flagged by FortiCNAPP composite alerts, showing that cloud behavior monitoring can catch long-running infections when network traffic looks unusual.

The dormant behavior also makes detection harder. Security tools often prioritize noisy activity, but a bot that only sends periodic peer traffic can blend into a busy cluster unless teams monitor egress patterns closely.

How teams can reduce the risk

Organizations should first make sure Redis never faces the public internet unless a specific architecture truly requires it. Even then, access should be limited with authentication, network rules, encryption, and strict allowlists.

The Redis project guidance recommends placing Redis in trusted networks and using security controls such as authentication and command restrictions. Kubernetes teams should combine those controls with namespace isolation and limited pod-to-pod access.

• Remove public access to Redis services unless there is a documented business need.
• Require authentication and restrict dangerous Redis commands in production.
• Patch Redis and underlying base images regularly.
• Use Kubernetes NetworkPolicies to limit pod-to-pod and pod-to-internet traffic.
• Monitor outbound connections from Redis pods and worker nodes.
• Rotate credentials if a Redis container or node shows signs of compromise.
• Inspect Kubernetes service accounts, secrets, and workloads after any Redis exposure.

Why this campaign matters for cloud security

The latest P2PInfect activity shows how attackers now treat cloud-native systems as long-term infrastructure targets. They do not always need to deploy ransomware immediately to create serious risk. A quiet foothold inside a cluster can be enough.

Teams should review Kubernetes traffic rules with the same care they apply to internet-facing firewalls. The Kubernetes NetworkPolicy model gives defenders a way to narrow what each workload can reach, reducing the damage when one service gets exposed.

The campaign also shows why older botnet research still matters. The P2PInfect research from Unit 42 identified the malware’s Redis focus early, while the newer Kubernetes findings show how that same foundation now affects managed cloud environments.

Security teams should also keep CVE-2022-0543 in their Redis audit plans. The CVE-2022-0543 entry remains a useful reminder that exposed Redis services can turn packaging flaws, misconfigurations, and weak network design into remote code execution paths.

For now, the strongest defense is clear: keep Redis private, segment Kubernetes workloads, monitor outbound connections, and treat any unexplained peer-to-peer traffic from Redis pods as a possible compromise.

FAQ