CVE-2025-5187: Kubernetes Privilege Escalation Vulnerability

CVE-2025-5187 Overview

A vulnerability exists in the NodeRestriction admission controller in Kubernetes clusters that allows node users to delete their corresponding node object through an improper authorization bypass. By patching themselves with an OwnerReference pointing to a cluster-scoped resource, attackers with node-level access can trigger garbage collection deletion of the node object. If the referenced OwnerReference resource does not exist or is subsequently deleted, the Kubernetes garbage collector will automatically delete the given node object.

This vulnerability represents an Improper Access Control weakness (CWE-863) where the NodeRestriction admission controller fails to properly validate OwnerReference patches, allowing nodes to establish unauthorized ownership relationships that can be exploited for node deletion.

Critical Impact

Attackers with node credentials can force deletion of node objects through garbage collection bypass, potentially disrupting cluster operations and workload availability.

Affected Products

• Kubernetes clusters with NodeRestriction admission controller enabled
• Kubernetes API Server with default admission controller configuration
• Multi-tenant Kubernetes environments with shared node access

Discovery Timeline

• 2025-08-27 - CVE CVE-2025-5187 published to NVD
• 2025-08-29 - Last updated in NVD database

Technical Details for CVE-2025-5187

Vulnerability Analysis

The vulnerability resides in the NodeRestriction admission controller, a critical Kubernetes security component designed to limit what node and pod objects kubelet processes can modify. The admission controller is intended to prevent nodes from modifying certain fields of their own node objects to maintain cluster integrity.

The core issue stems from insufficient validation of OwnerReference patches. In Kubernetes, OwnerReferences define parent-child relationships between objects, and when a parent object is deleted, the garbage collector automatically removes dependent child objects. The NodeRestriction admission controller fails to properly restrict nodes from setting arbitrary OwnerReferences on their own node objects.

An attacker who has compromised node credentials or has kubelet-level access can exploit this by patching the node object to include an OwnerReference pointing to a non-existent or soon-to-be-deleted cluster-scoped resource. When that resource doesn't exist or gets deleted, Kubernetes' garbage collection mechanism interprets the node object as orphaned and schedules it for deletion.

Root Cause

The root cause is improper authorization validation in the NodeRestriction admission controller (CWE-863 - Incorrect Authorization). The controller does not adequately restrict modifications to the metadata.ownerReferences field of node objects, allowing nodes to establish unauthorized parent-child relationships with cluster-scoped resources. This oversight enables abuse of the garbage collection mechanism for unauthorized object deletion.

Attack Vector

The attack is network-accessible and requires high privileges (node-level credentials). An attacker must have access to valid kubelet credentials or equivalent node authentication to make API requests on behalf of a node. The attacker then submits a PATCH request to the Kubernetes API server to modify their node object's metadata.ownerReferences field, pointing to either a non-existent cluster-scoped resource or a resource they know will be deleted. Once the garbage collector processes this relationship and finds the parent missing, it will delete the node object as part of its normal orphan cleanup procedures.

The attack does not require user interaction and has a contained scope, primarily impacting the availability of the targeted node and any workloads scheduled on it.

Detection Methods for CVE-2025-5187

Indicators of Compromise

• Unexpected modifications to node object metadata.ownerReferences fields in API audit logs
• Node objects suddenly acquiring OwnerReferences to cluster-scoped resources
• Unusual node deletions triggered by garbage collection rather than explicit delete requests
• API audit entries showing PATCH requests to node objects from kubelet credentials modifying ownerReferences

Detection Strategies

• Enable and monitor Kubernetes API audit logs for PATCH operations on node objects that modify metadata.ownerReferences
• Create alerting rules for node deletions that correlate with recent OwnerReference modifications
• Implement Open Policy Agent (OPA) Gatekeeper policies to detect and alert on suspicious OwnerReference patterns on node objects
• Monitor garbage collector logs for unexpected node object orphan deletions

Monitoring Recommendations

• Configure audit policy to log all node object mutations at the RequestResponse level
• Set up SIEM alerts for OwnerReference modifications on node-type Kubernetes objects
• Implement continuous monitoring for node count anomalies that may indicate unauthorized deletions
• Review kubelet authentication and authorization configurations to ensure least-privilege access

How to Mitigate CVE-2025-5187

Immediate Actions Required

• Review Kubernetes API audit logs for any suspicious PATCH operations on node objects involving OwnerReference modifications
• Implement additional admission controller policies (e.g., OPA Gatekeeper) to restrict OwnerReference modifications on node objects
• Audit node credential distribution and ensure kubelet credentials are properly protected
• Consider network policies to limit API server access from node networks where possible

Patch Information

Organizations should monitor the Kubernetes Security Announcements mailing list and the GitHub Issue Discussion for official patch releases. Apply Kubernetes updates as they become available from the Kubernetes project.

Consult your Kubernetes distribution vendor (e.g., GKE, EKS, AKS, OpenShift) for distribution-specific patch availability and guidance.

Workarounds

• Deploy OPA Gatekeeper or Kyverno policies that explicitly deny modifications to metadata.ownerReferences on node objects from node-level service accounts
• Implement strict RBAC policies limiting which principals can modify node objects
• Enable additional audit logging to detect exploitation attempts before patches are applied
• Consider implementing network segmentation to restrict kubelet access to the API server from untrusted network segments

# Example: Monitor for suspicious OwnerReference patches on nodes via audit logs
kubectl get events --field-selector reason=OwnerReferencePatch --all-namespaces

# Review recent modifications to node objects
kubectl get nodes -o json | jq '.items[].metadata.ownerReferences // empty'