CVE-2026-120656 in kruise-manager
Summary
by MITRE • 11/02/2026
OpenKruise kruise-manager exposes an unauthenticated ppof endpoint when enabled, opening it on 0.0.0.0:8090, which can enable a DoS attack triggerable by any RBAC pod.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in OpenKruise involves the exposure of an unauthenticated profiling endpoint within the kruise-manager component. When specific configuration flags are enabled to facilitate debugging or performance analysis, the application binds this service interface to all available network interfaces on port 8090. This binding behavior results in the endpoint being accessible from any source that can reach the host machine's IP address space, effectively removing local-only restrictions and exposing internal management tools to potential external actors or lateral movement within a compromised cluster environment.
From a technical perspective, this flaw represents an insecure default configuration where sensitive diagnostic interfaces are made publicly accessible without implementing authentication mechanisms or network-level access controls. The endpoint in question is typically designed for developers to gather runtime metrics such as CPU profiles and heap dumps using standard profiling tools like pprof. However, by exposing it on 0.0.0.0 rather than restricting it to localhost or a secure management network, the system violates the principle of least privilege regarding service exposure. This misconfiguration allows any entity with network connectivity to the host to interact directly with these diagnostic functions without providing credentials.
The operational impact of this vulnerability is primarily centered on Denial of Service capabilities and potential information disclosure. An attacker who gains access to a pod within the Kubernetes cluster, particularly one that has RBAC permissions allowing it to communicate with the kruise-manager service, can trigger resource-intensive profiling operations. By repeatedly requesting CPU or memory profiles, an adversary can consume significant amounts of CPU cycles and memory on the host running the manager component. This sustained abuse leads to resource exhaustion, causing performance degradation for other critical workloads sharing the same node or potentially crashing the management plane entirely, thereby disrupting cluster orchestration capabilities.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as it fails to restrict access to a functional component that should be protected by authentication and authorization checks. Furthermore, in the context of the MITRE ATT&CK framework for Kubernetes, this scenario relates to techniques involving resource hijacking or denial of service through API abuse. The ability for any RBAC pod to trigger these actions highlights a gap in how internal traffic is authenticated between components that are not strictly required to share such sensitive diagnostic access.
To mitigate this risk, administrators should ensure that the profiling endpoint is disabled in production environments unless absolutely necessary for troubleshooting. If enabled, it must be bound exclusively to localhost or a dedicated management network interface rather than 0.0.0.0. Additionally, implementing strict NetworkPolicy rules within the Kubernetes cluster can restrict ingress traffic to port 8090 only from trusted administrative sources. Enabling authentication mechanisms on diagnostic endpoints and regularly auditing RBAC permissions for pods that require access to manager services are also critical steps in reducing the attack surface associated with this configuration flaw.