CVE-2025-5187
BaseFortify
Publication date: 2025-08-27
Last updated on: 2025-08-29
Assigner: Kubernetes
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| kubernetes | kube-apiserver | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the NodeRestriction admission controller of Kubernetes clusters. Normally, node users can create and patch their own node objects but cannot delete them. However, due to improper handling of OwnerReferences, a node user can patch their node object by adding an OwnerReference to a cluster-scoped resource. If that referenced resource does not exist or is deleted, Kubernetes garbage collection will delete the node object. This allows a compromised node to delete its own node object and then recreate it with altered taints or labels, which can affect cluster behavior and pod scheduling. [1, 2]
How can this vulnerability impact me? :
The vulnerability allows a compromised node user to delete and recreate their own node object with modified taints or labels, which are normally restricted. This manipulation can impact cluster behavior by affecting pod scheduling on the compromised node. It can lead to unauthorized changes in the cluster, potentially compromising confidentiality and integrity of the cluster's operation. The CVSS score indicates a medium severity with high impact on confidentiality and integrity. [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection can be performed by analyzing Kubernetes API audit logs for patch requests from node users that modify OwnerReferences. Such patch requests are abnormal because Kubelets do not normally patch their own OwnerReferences. You can use commands like 'kubectl logs' to retrieve API server audit logs and then grep or filter for patch operations on node objects that include modifications to OwnerReferences by node users. [1, 2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading the kube-apiserver to patched versions (v1.31.12 or later, v1.32.8 or later, or v1.33.4 or later) which enhance the NodeRestriction admission controller to block node users from modifying their own OwnerReferences. Alternatively, you can enable the OwnerReferencesPermissionEnforcement admission controller, which enforces strict permission checks on OwnerReferences modifications and prevents unauthorized changes. [1, 2]