Notice of Kubernetes Security Vulnerability (CVE-2025-5187)

The Kubernetes community recently disclosed a security vulnerability (CVE-2025-5187), where nodes can be unintentionally deleted if OwnerReferences are added to them.

Description

**Table 1** Vulnerability details
Type	CVE-ID	Severity	Discovered
Resource management flaw	CVE-2025-5187	Medium	2025-08-12

The Kubernetes NodeRestriction admission controller contains a vulnerability that allows a node user to manipulate its OwnerReferences. Specifically, a user can add OwnerReferences pointing to a cluster-scoped resource. If the referenced resource is deleted or does not exist, the node will be deleted via garbage collection.

By default, node users have create and patch permissions on their node objects, but not delete permissions. However, NodeRestriction does not prohibit patch operations on OwnerReferences. An attacker can exploit this vulnerability to delete the original node and create a new node after a node is compromised. In this way, they can bypass NodeRestriction's safeguards on taint or label modifications and create a node with malicious taints or labels. As a result, the Kubernetes scheduler may place targeted pods onto the compromised node, enabling node hijacking or workload manipulation.

Impact

According to the community, the affected kube-apiserver versions are:

kube-apiserver: ≤ v1.31.11
kube-apiserver: ≤ v1.32.7
kube-apiserver: ≤ v1.33.3

For Huawei Cloud CCE, the affected cluster versions are v1.27.16-r40, v1.28.15-r30, v1.29.13-r10, v1.30.10-r10, v1.31.6-r10, and versions earlier than v1.32.5-r0.

The certificate and key (in /opt/cloud/cce/kubernetes/kubelet/pki/kubelet-client-current.pem), which grant user permissions on a node, are encrypted. So, the potential risk impact is considered controllable.

Identification Method

Log in to the CCE console, click the name of the target cluster to access the cluster console, and check the cluster version on the Overview page.

Click to enlarge

If a cluster version is not one of the affected versions, the cluster is not affected by the vulnerability.

If a cluster version is one of the affected versions, you can enable the function of collecting audit logs, switch to the Logging > Kubernetes audit logs tab, search for the following content, and check whether the vulnerability is exploited in the cluster.
```
content : patch AND content : nodes AND content : OwnerReferences
```
If information similar to that shown in the figure below is displayed, it means that no log is found and there is no abnormal operation.

Solution

We have fixed this vulnerability. Pay attention to update in Patch Versions and upgrade your clusters to a version that have this vulnerability fixed. For clusters that have reached EOS, upgrade them to versions under maintenance.

Cluster versions that have this vulnerability fixed: v1.27.16-r40, v1.28.15-r30, v1.29.13-r10, v1.30.10-r10, v1.31.6-r10, v1.32.5-r0, and later