Critical Chaos Mesh Vulnerabilities Allow Attackers to Take Over Kubernetes Clusters

Chaos engineering platform Chaos Mesh has been rocked by Chaotic Deputy, a series of four vulnerabilities—CVE-2025-59358, CVE-2025-59359, CVE-2025-59360, and CVE-2025-59361—disclosed on September 15, 2025.

The latter three flaws carry a critical severity rating of CVSS 9.8 and allow any in-cluster attacker to run arbitrary code on any pod, even under default configurations.

Users are urged to upgrade to Chaos-Mesh 2.7.3 immediately or apply workarounds to mitigate the risk.

Attack Surface and Prerequisites

Chaos Mesh consists of three main components: the Chaos Dashboard (web UI and RBAC management), the Chaos Controller Manager (schedules and orchestrates fault injections), and the Chaos Daemon (executes faults with privileged permissions).

The controller exposes a debugging GraphQL server on port 10082 without authentication (CVE-2025-59358), enabling cluster-wide denial-of-service by issuing killProcess mutations against critical system pods. Because the controller uses ClusterIP type, any pod in the cluster may reach this endpoint.

In-cluster access is required to exploit these flaws—a scenario common in multi-tenant environments or clusters compromised via supply-chain and pod escape attacks.

Once inside, attackers can interact with the GraphQL server to trigger native fault injections or inject crafted OS commands through command-injection mutations (CVE-2025-59359, CVE-2025-59360, CVE-2025-59361).

Command-injection flaws reside in three GraphQL mutations: cleanTcs (removing traffic control on specified devices), killProcesses (terminating arbitrary PIDs), and cleanIptables (flushing specified chains).

In each case, user-controlled inputs are concatenated directly into shell commands before being executed via the ExecBypass method.

Attackers exploit this to execute additional shell operations, such as copying service-account tokens from other pods into their own filesystem, facilitating privilege escalation and lateral movement.

Because the Chaos Daemon mounts every pod’s filesystem under /proc/<PID>/root, attackers can harvest tokens for total cluster takeover.

Detection and Workarounds

Operators can detect vulnerable deployments by querying Chaos-Mesh pods and inspecting their image version and the open port:

textkubectl get pods -A --selector app.kubernetes.io/name=chaos-mesh -o=jsonpath="{range .items[*]}{.metadata.name}{': '}{.spec.containers[*].image}{'\n'}{end}"
kubectl describe pod chaos-controller-manager -n chaos-mesh | grep "CTRL_ADDR:"

If the image version is earlier than 2.7.3 and port 10082 is exposed, the cluster is vulnerable.

As a temporary measure, redeploy the Helm chart with the control server disabled:

texthelm install chaos-mesh chaos-mesh/chaos-mesh -n=chaos-mesh --version 2.7.x --set enableCtrlServer=false

JFrog Security reported these issues to Chaos-Mesh developers on May 6, 2025. A short-term mitigation was released on August 21, 2025, and full fixes landed in version 2.7.3 on September 15, 2025.

Users of managed services like Azure Chaos Studio for AKS should verify their underlying Chaos-Mesh versions.

Bookmark the JFrog Security Research Center for future advisories and ensure timely upgrades to defend against Chaotic Deputy.

Staying on the latest Chaos-Mesh release is critical to preventing total cluster compromise. Users unable to upgrade should disable the control server and monitor for suspicious GraphQL requests on port 10082.

Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant Updates