[Security Advisory] CVE-2025-4563: Nodes can bypass dynamic resource allocation authorization checks

[Rita Zhang]

Hello Kubernetes Community,

A vulnerability exists in the NodeRestriction admission controller where nodes can bypass dynamic resource allocation authorization checks. When the DynamicResourceAllocation feature gate is enabled, the controller properly validates resource claim statuses during pod status updates but fails to perform equivalent validation during pod creation. This allows a compromised node to create mirror pods that access unauthorized dynamic resources, potentially leading to privilege escalation.

This issue has been rated Low (2.7) CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L, and assigned CVE-2025-4563.

Am I vulnerable?

All clusters that are using the DynamicResourceAllocation feature (disabled by default) and static pods together may be vulnerable.

Affected Versions

• kube-apiserver: v1.32.0 - v1.32.5

• kube-apiserver: v1.33.0 - 1.33.1

How do I mitigate this vulnerability?

This issue can be mitigated by:

• If you're not actively using the DynamicResourceAllocation features, the safest and simplest action is to turn off the feature on the API server.

Fixed Versions

• kube-apiserver >= v1.32.6 

• kube-apiserver >= v1.33.2

Detection

All clusters that are using the DynamicResourceAllocation feature and static pods may be vulnerable.  Run the following command to see if the feature is in use:

kubectl get ResourceClaim --all-namespaces

and 

kubectl get pods --all-namespaces -o json | jq -r '

  .items[] 

  | select(.metadata.annotations["kubernetes.io/config.mirror"] == "true") 

  | "\(.metadata.namespace)/\(.metadata.name)"'

If you find evidence that this vulnerability has been exploited, please contact secu...@kubernetes.io

Thank You,

Rita Zhang on behalf of the Kubernetes Security Response Committee

Additional Details

See the GitHub issue for more details:

https://github.com/kubernetes/kubernetes/issues/132151

Acknowledgements

This vulnerability was reported by @amitschendel

The issue was fixed and coordinated by: 

Patrick Ohly @pohly

Jordan Liggitt @liggitt

Balaji @SaranBalaji90

Rita Zhang @ritazh

Marko Mudrinić @xmudrii

Thank You,

Rita Zhang on behalf of the Kubernetes Security Response Committee

[Rita Zhang]

Thanks for the analysis Abhishek. Below are the rationales for the low CVSS score.

AV:N - The Kubernetes API server is accessible over the network.
AC:L - No special conditions are required; a compromised node can initiate the attack directly.
PR:H - The attacker must have control over a node. Nodes are considered high privileged. They can read secrets, create SA tokens, etc which has far more access than a user that has admin level access to a single namespace, for example.
UI:N - No user interaction is needed to exploit the issue.
S:U - If claim access control is fully enforced, no cross-boundary effects.
C:N - The kubelet won't start the pod, thus not granting the attacker access to the devices behind the referenced resource claim.  
I:N - The kubelet won't start the pod, thus not granting the attacker access to the devices behind the referenced resource claim. Attacker cannot alter protected resources via the exploit.

A:L - Exploit cannot disrupt usage of the claim since the pod won't start. Another pod referencing the claim is ignored by the control plane

On Wed, Jun 18, 2025 at 11:32 PM Red Hat Product Security <seca...@redhat.com> wrote:

Hello!

INC3695208 ([Security Advisory] CVE-2025-4563: Nodes can bypass dynamic resource allocation authorization checks) is pending your review.

Opened for: rita.z...@gmail.com
Followers: kubernete...@googlegroups.com, d...@kubernetes.io, kubernetes-sec...@googlegroups.com, kubernetes-se...@googlegroups.com, distributo...@kubernetes.io

Abhishek Raj updated your request with the following comments:

Hi Rita,

 

After reviewing the upstream CVSS rating of 2.7 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L) for this vulnerability, we have determined that it significantly under-represents both the attack conditions and potential impact. The upstream vector incorrectly marks Privileges Required as High (PR:H) and Attack Complexity as Low (AC:L). In Kubernetes, a node which is the actor in this scenario has limited API permissions and does not require elevated (admin-level) privileges to exploit the vulnerability. Therefore, PR should be Low. Additionally, exploitation requires a specific and complex set of conditions: the cluster must have the DynamicResourceAllocation feature enabled (which is off by default), static pods must be in use, and the attacker must already have control of a node to craft a mirror pod with access to unauthorized resources. These prerequisites justify marking Attack Complexity as High (AC:H). Moreover, the vulnerability allows access to potentially sensitive dynamic resources, justifying a High Confidentiality impact (C:H) and a Low Integrity impact (I:L) if resources are writable. Availability is not meaningfully affected, as kubelet typically prevents unauthorized pods from running. Based on this analysis, we assess the CVSS vector to be CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N, with a Base Score of 5.9 (Medium), which better reflects the true security implications.

 

Let me know your thoughts accordingly will proceed with our analysis on this .

 

Thanks,

Abhishek

How can I track and update my request?

To respond, reply to this email. You may also create a new email and include the request number (INC3695208) in the subject.

Thank you,
Product Security

 

Ref:MSG107332575

--

Rita Zhang