P2Pinfect Kubernetes Compromise — Exposed Redis Enables Persistent GKE Botnet Enrollment with Six-Month Dormancy (CVE-2022-0543, CVE-2025-11953, CVE-2025-49844)

P2Pinfect Kubernetes Compromise (TL-2026-0537), also tracked as Misconfigured Enrolled and Dormant Campaign, is a high-severity malware campaign scored CVSS 8.8, first published 2026-05-21. It is attributed to P2Pinfect Operator with low confidence, affects Redis Ltd. / Redis OSS Redis, references 3 CVEs (CVE-2022-0543, CVE-2025-11953, CVE-2025-49844), maps to 33 MITRE ATT&CK techniques (T1027, T1036, T1046), and is covered by 9 detection rules and 31 indicators of compromise.

Key facts for TL-2026-0537

Threat ID
TL-2026-0537
Also known as
Misconfigured Enrolled and Dormant Campaign, P2Pinfect GKE Campaign, P2Pinfect-K8s
Severity
HIGH
CVSS
8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Status
ACTIVE
Category
MALWARE
First published
2026-05-21
Last reviewed
2026-05-21
Attribution
P2Pinfect Operator
Attribution confidence
LOW
Motivation
FINANCIAL
Target sectors
technology, financial, ecommerce, saas, media, healthcare, manufacturing
Target regions
Global, North America, Europe, Asia-Pacific
Detection rules
9
Indicators of compromise
31

Malware and tooling in P2Pinfect Kubernetes Compromise

Malware and tooling: P2Pinfect, P2Pinfect gossip mesh (custom), UPX (mangled magic), XMRig, rsagen

FortiGuard Labs documented persistent P2Pinfect botnet presence in Google Kubernetes Engine (GKE) clusters across multiple client environments, with one compromise dormant for six months before discovery. Initial access was achieved via Internet-exposed Redis pods accepting unauthenticated commands, abused for Lua sandbox escape (CVE-2022-0543) and SLAVEOF / CONFIG SET module-loading primitives. The Rust-written, UPX-packed P2Pinfect client enrolled compromised pods into the gossip-based peer mesh and remained operationally silent, awaiting an operator push. Fortinet telemetry shows the campaign expanding beyond Redis to React Native Metro dev servers (CVE-2025-11953, 'Metro4Shell') and credible incorporation of the RediShell Redis Lua use-after-free (CVE-2025-49844, Wiz, Oct 2025) into the worm's exploit toolkit.

How P2Pinfect Kubernetes Compromise works

**Campaign overview.** P2Pinfect is a self-replicating, Rust-based botnet first publicly documented by Palo Alto Networks Unit 42 in July 2023 and continuously tracked by Cado Security, Akamai SIRT, and Cisco Talos. The botnet uses a permissioned gossip protocol over a flat peer-to-peer mesh — every infected host can both receive and rebroadcast new binaries — and has historically been used to drop XMRig Monero miners and an opportunistic ransomware module (rsagen). The May 2026 FortiGuard Labs report (Misconfigured, Enrolled and Dormant) is the first public confirmation that the operator is targeting managed-Kubernetes runtime environments at scale, with confirmed long-dwell footholds in multiple Google Kubernetes Engine (GKE) tenants. One environment was compromised for approximately six months before detection — the host had been enrolled, beaconed back to the mesh on its expected jitter, and was never tasked with a second-stage payload, which made it invisible to signature-based EDR controls watching for cryptominer or ransomware behavior.

**Initial access — exposed Redis.** Across all confirmed GKE intrusions Fortinet documents the same root cause: a Redis Deployment exposed to the public Internet through a permissive Service or Ingress, accepting commands without requirepass. The operator drives initial code execution by chaining classical Redis abuse primitives: (1) CONFIG SET dir /var/spool/cron/, CONFIG SET dbfilename root, then SAVE to drop a cron entry; (2) MODULE LOAD of an attacker-supplied shared object delivered via SLAVEOF / replication; and (3) on Debian-derived images, the Debian-specific Lua sandbox escape CVE-2022-0543 (package.loadlib reachable from inside the sandbox) for direct RCE. The Lua escape is preferred because it works against pods that have hardened cron and disabled module loading. Fortinet observed the operator probing for all three primitives in sequence and falling back if any single technique was blocked.

**Implant — the Rust P2Pinfect client.** The dropper is a statically-linked Rust binary, UPX-packed, with the upper-case UPX magic deliberately mangled to defeat naive header scanning (upx -d fails; manual fix-up restores the section table). Unpacked, the binary exposes the canonical P2Pinfect strings (p2pinfect, botnet_v3, gossip_round), a libtor-style Tor bundle for fallback C2, and a randomized 30-day-jitter beacon scheduler. Once running, the client (a) enumerates the host (kubelet token, service-account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/, network interfaces, kernel version, container runtime), (b) opens a listener on a high TCP port (observed 60100-60300 random) for inbound gossip peers, (c) connects out to 3-8 hard-coded bootstrap peers and learns additional peers via gossip, and (d) waits. It does not in itself escalate, drop a miner, or move laterally — those actions are operator-tasked over the mesh and were never observed in the six-month dormant case.

**Persistence and dormancy.** P2Pinfect installs persistence at every layer it can reach: a systemd user-unit if /run/systemd is writable, a crontab -e entry inside the pod, a renamed copy of itself in /tmp/.{random}/ plus an LD_PRELOAD shim hooking getuid(), and — most importantly in the GKE case — an in-cluster persistence path. Where the compromised pod runs with a service account that has create pods or patch deployments RBAC, the implant creates a new Deployment in the kube-system namespace mimicking a benign DaemonSet (commonly node-local-cache or metrics-server-helper) whose pod template re-launches the implant. This survives node reboots, pod evictions, and even cluster autoscaler scale-down events. The six-month dormancy case is a direct consequence of this design: nothing the implant does on a dormant peer touches disk I/O, network egress (beyond expected jitter), or process trees in a way that crosses normal EDR thresholds.

**Expansion to React Native Metro (CVE-2025-11953, Metro4Shell).** Fortinet telemetry between February and April 2026 shows P2Pinfect peers initiating scans for React Native Metro development servers exposed on TCP 8081. CVE-2025-11953, disclosed in November 2025, is an unauthenticated remote code execution in the Metro bundler /open-stack-frame-in-editor endpoint, exploitable on any Metro instance reachable on the network and present in @react-native-community/cli-server-api versions <= 20.0.0-alpha.2. The vulnerability allows an attacker to supply an editor command and have the development host execute it; the operator chains it to spawn a curl that retrieves the same Rust dropper used for Redis foothold, indicating the worm now has a multi-vector self-propagation primitive. Targeting Metro on TCP 8081 makes ephemeral CI runners and developer laptops attractive secondary footholds for moving deeper into corporate networks.

**Possible incorporation of RediShell (CVE-2025-49844).** RediShell, disclosed by Wiz Research on 6 October 2025, is a 13-year-old use-after-free in Redis Lua scripting that yields authenticated remote code execution against any Redis instance on which an attacker can issue EVAL. Fortinet did not directly confirm RediShell exploitation in the documented GKE intrusions (the unauthenticated Redis exposure made CVE-2022-0543 sufficient), but the Wiz advisory and follow-on industry tracking note that mass-exploitation kits incorporated RediShell within weeks. Two Fortinet-observed sample variants contain string artifacts (lua_uaf, EVAL_LUA_UAF_POC) that strongly suggest the operator has at minimum staged the exploit, even if active use against the GKE victims was unnecessary. Defenders should treat RediShell as part of the campaign's exploit toolbox.

**Strategic implication.** The compromised peers are a botnet-for-hire substrate. Operator tasking is asynchronous and silent: a single signed gossip message can convert thousands of dormant Kubernetes peers into a coordinated ransomware deployment, a credential-harvesting wave against cloud metadata services, or a coin-mining cluster within minutes. Defenders cannot wait for second-stage payload behavior to detect this campaign — by the time the second stage fires, the entire mesh has executed in parallel. Detection must focus on initial-access primitives (exposed Redis CONFIG SET, SLAVEOF, MODULE LOAD; Metro /open-stack-frame-in-editor), the dropper's network signature (TCP 60100-60300 listener on a pod), and Kubernetes-control-plane persistence (kube-system DaemonSets impersonating node-local-cache or metrics-server).

MITRE ATT&CK techniques used in TL-2026-0537

Defense Evasion

T1027 Obfuscated Files or Information; T1036 Masquerading; T1070 Indicator Removal

Discovery

T1046 Network Service Discovery; T1526 Cloud Service Discovery; T1613 Container and Resource Discovery

Persistence

T1053 Scheduled Task/Job; T1543 Create or Modify System Process

Execution

T1059 Command and Scripting Interpreter; T1203 Exploitation for Client Execution; T1609 Container Administration Command; T1610 Deploy Container

Privilege Escalation

T1068 Exploitation for Privilege Escalation; T1611 Escape to Host

Command and Control

T1071 Application Layer Protocol; T1090 Proxy; T1105 Ingress Tool Transfer; T1571 Non-Standard Port

Initial Access

T1133 External Remote Services; T1190 Exploit Public-Facing Application

Lateral Movement

T1210 Exploitation of Remote Services; T1570 Lateral Tool Transfer

Impact

T1486 Data Encrypted for Impact; T1496 Resource Hijacking

Credential Access

T1528 Steal Application Access Token; T1552 Unsecured Credentials

stealth

T1574 Hijack Execution Flow

Resource Development

T1583 Acquire Infrastructure; T1587 Develop Capabilities; T1588 Obtain Capabilities

Reconnaissance

T1590 Gather Victim Network Information; T1595 Active Scanning

defense-impairment

T1685 Disable or Modify Tools

Affected products and versions in P2Pinfect Kubernetes Compromise

  • Redis Ltd. / Redis OSS — Redis
    Vulnerable versions: all versions before 7.4.6 / 7.2.10 / 6.2.18 (CVE-2025-49844); Debian-packaged Redis without CVE-2022-0543 backport
    Fixed in: 7.4.6; 7.2.10; 6.2.18
  • Meta / React Native Community — @react-native-community/cli-server-api (Metro)
    Vulnerable versions: <= 20.0.0-alpha.2
    Fixed in: >= 20.0.0-alpha.3
  • Google Cloud — Google Kubernetes Engine (GKE)
    Vulnerable versions: any GKE cluster hosting unauthenticated Redis exposed via LoadBalancer/NodePort or with overly-broad pod RBAC
    Fixed in: N/A — configuration-level remediation required
  • Kubernetes — Kubernetes (upstream)
    Vulnerable versions: clusters running workloads with overly-broad service-account RBAC enabling kube-system Deployment creation
    Fixed in: N/A — apply Pod Security Admission and least-privilege RBAC

Remediation for P2Pinfect Kubernetes Compromise

Patches

  • Redis 7.4.6 / 7.2.10 / 6.2.18 (CVE-2025-49844 RediShell)
  • Redis Debian package >= 5:5.0.14-1+deb11u4 or vendor backport for CVE-2022-0543
  • @react-native-community/cli-server-api >= 20.0.0-alpha.3 (CVE-2025-11953 Metro4Shell)

Immediate actions

  • Identify all Redis Services / Pods in your Kubernetes clusters; confirm none have ExternalIP, LoadBalancer with 0.0.0.0/0, or NodePort exposure to the Internet
  • Set requirepass on every Redis instance and disable dangerous commands via rename-command CONFIG "", rename-command MODULE "", rename-command SLAVEOF "", rename-command EVAL ""
  • Patch all Redis instances to versions addressing CVE-2025-49844 (RediShell): 7.4.6, 7.2.10, 6.2.18 or later
  • Patch React Native projects to @react-native-community/cli-server-api >= 20.0.0-alpha.3 to remediate CVE-2025-11953 (Metro4Shell); never expose Metro (TCP 8081) outside localhost
  • Audit kube-system namespace for unexpected Deployments/DaemonSets — particularly any named node-local-cache, metrics-server-helper, kube-proxy-helper that you did not author
  • Hunt for outbound TCP connections from worker nodes / pods to the known P2Pinfect bootstrap peer ranges and on listener ports TCP 60100-60300

Workarounds

  • If immediate patching is impossible, restrict Redis to bind 127.0.0.1 or to in-cluster ClusterIP only; remove ANY LoadBalancer/NodePort exposure
  • Disable Lua scripting via rename-command EVAL "" and rename-command EVALSHA "" until CVE-2025-49844 patches are deployed
  • Block egress from worker nodes to known P2Pinfect bootstrap peer IPs at perimeter firewall; rate-limit egress to non-corporate destinations
  • Force-bind Metro dev server to 127.0.0.1 by passing --host 127.0.0.1 to npx react-native start; firewall TCP 8081 inbound on developer laptops and CI runners

Longer-term hardening

  • Adopt Pod Security Admission baseline or restricted profile cluster-wide; forbid hostPath, hostNetwork, privileged, and overly-broad service-account RBAC by default
  • Apply NetworkPolicy default-deny egress at the namespace level; allow only required egress to package mirrors, image registries, and known dependencies
  • Deploy runtime EDR with eBPF visibility into containers (Falco, Tetragon, or equivalent commercial) with rules for Redis-spawned shells, suspicious MODULE LOAD, and Metro /open-stack-frame-in-editor invocations
  • Treat managed Kubernetes service accounts as identity boundaries: rotate tokens, audit RBAC quarterly, ensure no default-namespace pod runs with cluster-admin or kube-system write
  • Subscribe to CISA KEV and Wiz / Fortinet advisory feeds for Redis, React Native, and container-runtime CVEs; treat any Redis Lua or module-loading CVE as treat-as-RCE

CVEs associated with P2Pinfect Kubernetes Compromise

CVE-2022-0543, CVE-2025-11953, CVE-2025-49844

Weaknesses (CWE) in P2Pinfect Kubernetes Compromise

CWE-269, CWE-416, CWE-94, CWE-78, CWE-863, CWE-306

Timeline of P2Pinfect Kubernetes Compromise

  • CVE-2022-0543 published — Debian-specific Redis Lua sandbox escape allowing unauthenticated RCE on default Debian/Ubuntu Redis packages.
  • CISA adds CVE-2022-0543 to Known Exploited Vulnerabilities catalog after observing in-the-wild exploitation.
  • Palo Alto Unit 42 publishes the first public analysis of P2Pinfect — a Rust-written peer-to-peer worm targeting exposed Redis, using CVE-2022-0543 and SLAVEOF replication for foothold.
  • Cado Security observes P2Pinfect adding XMRig Monero miner and a ransomware module (rsagen) staged through operator-pushed gossip messages.
  • Akamai SIRT reports a MIPS variant of P2Pinfect targeting embedded Linux and IoT devices, demonstrating cross-architecture cross-compilation by the operator.
  • Wiz Research discloses CVE-2025-49844 (RediShell) — a 13-year-old Lua use-after-free RCE in Redis affecting versions prior to 7.4.6 / 7.2.10 / 6.2.18.
  • CVE-2025-11953 (Metro4Shell) disclosed by Meta and the React Native maintainers — unauthenticated RCE in Metro bundler /open-stack-frame-in-editor endpoint on TCP 8081.
  • Fortinet IR data places the earliest confirmed GKE foothold in the documented campaign at approximately this date (six months before public disclosure).
  • FortiGuard Labs telemetry begins observing P2Pinfect peers initiating mass scans for React Native Metro dev servers on TCP 8081, indicating CVE-2025-11953 incorporation.
  • Two P2Pinfect dropper variants captured by FortiGuard contain string artifacts (lua_uaf, EVAL_LUA_UAF_POC) indicating staged or operational use of CVE-2025-49844 (RediShell).
  • FortiGuard Labs publishes Misconfigured, Enrolled and Dormant — first public confirmation of P2Pinfect at-scale persistence in GKE customer environments, including the six-month dormancy case.
  • Threadlinqs Intelligence publishes TL-2026-0537 with full MITRE mapping, detections, and simulations for the P2Pinfect Kubernetes compromise campaign.
  • As of 2026-05-29, this P2Pinfect Kubernetes campaign remains ACTIVE: the takedown-resistant P2P botnet has no recorded sinkhole or arrest and is actively expanding via Metro4Shell (CVE-2025-11953, added to CISA KEV Feb 2026, exploited Dec 2025-Feb 2026). RediShell (CVE-2025-49844) and CVE-2022-0543 are patched but exploitation persists against ~60k unauth-exposed Redis instances.

Sources cited for P2Pinfect Kubernetes Compromise

Threats related to P2Pinfect Kubernetes Compromise

Detection coverage for TL-2026-0537

As of 2026-05-21, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0537 across Splunk SPL, Microsoft KQL and Sigma, covering 31 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats