A security issue was discovered in the Kubernetes Java client library where a compromised pod may be able to create new files in arbitrary locations on the client machine executing copy operations via non-tar copyDirectoryFromPod when enableTarCompressing is false.

A flaw was found in HyperShift's hosted control plane konnectivity-server configuration. The proxy-server is started without the --cluster-ca-cert flag, which means the agent-facing TLS listener is set to tls.NoClientCert and does not request or verify client certificates at all. An attacker with network access to the externally-exposed konnectivity cluster endpoint can connect with an arbitrary or self-signed certificate (or no certificate) and be added to the agent routing pool. Once in the routing pool, the attacker can intercept, modify, or drop control-plane-to-node traffic that the server routes through their connection, including kubectl exec/logs streams, kubelet API calls with pod specs containing secrets, service account tokens, and ConfigMap/Secret data. The fix adds --cluster-ca-cert referencing the existing per-cluster konnectivity CA bundle that is already mounted in the container.

Esri Portal for ArcGIS versions 12.1 and earlier on Windows, Linux and Kubernetes have a missing authentication for critical function vulnerability allows a remote, unauthenticated attacker to access an unprotected API.

A Weak Password Recovery Mechanism for Forgotten Password exists in Esri Portal for ArcGIS versions 12.1 and earlier on Windows, Linux and Kubernetes. A remote, unauthorized attacker may assume ownership of a user’s account by manipulating this mechanism. ArcGIS Administrators should configure an email server with ArcGIS Enterprise to facilitate user self-service password recovery. The ability for an administrator to reset a user’s password remains unchanged.

An incorrect authorization vulnerability exists in Esri Portal for ArcGIS 11.4, 11.5 and 12.0 on Windows, Linux and Kubernetes that did not correctly check permissions assigned to developer credentials.

Summary: Possible DOS in SPDY streaming code, used for attach, exec and port forwarding.

Requirements To Exploit: Access to the kubelet's endpoint (granted through nodes/proxy) or access to any of portforward, exec, or attach to pods. These all can be represented by the cluster roles

pods/portforward (create)

pods/exec (create)

pods/attach (create)

nodes/proxy (get/create)

Component Affected: Kubelet, CRI-O, kube-apiserver

Version Affected: Openshift 4.21.4 and below

Patch Available: yes

Version Fixed: none yet

Cvss: (Based on [https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator]). Please note that only the Base Score Metrics are required by the incident response team.

Impact: Based on the https://access.redhat.com/security/updates/classification , what do you think would be the impact and why? This helps a lot the analyst to understand why such a report must be or not considered Moderate/Important or even Critical.

Steps To Reproduce: apply:

— apiVersion: v1 kind: ServiceAccount metadata: name: poc-sa-portforward namespace: default — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: Role metadata: name: poc-role-portforward namespace: default rules:

apiGroups: [""] resources: ["pods/portforward"] verbs: ["create"] — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: RoleBinding metadata: name: poc-rb-portforward namespace: default subjects:

kind: ServiceAccount name: poc-sa-portforward namespace: default roleRef: kind: Role name: poc-role-portforward apiGroup: rbac.authorization.k8s.io — apiVersion: v1 kind: Pod metadata: name: poc-target namespace: default spec: containers:

name: nginx image: nginx:alpine

set env:

export APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}' | sed 's|https://||')

export TOKEN=$(kubectl create token poc-sa-portforward)

export POD=poc-target

run attached pocportforward.py

Mitigation: disable the above cluster roles from untrusted users.

Embargo Reason: Coordination with three upstream communities: containerd, CRI-O, kubernetes

Original Report: https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2

Hello Kubernetes Community,

A vulnerability was identified in the Kubernetes CSI Driver for SMB where insufficient validation of the subDir parameter in volume identifiers could allow path traversal. A malicious user with the ability to create a PersistentVolume referencing the SMB CSI driver could craft a volumeHandle containing traversal sequences (for example ../). When the driver performs cleanup operations during volume deletion, these sequences may cause the driver to operate on unintended directories on the SMB server.

An attacker exploiting this flaw could cause deletion or modification of directories outside the intended managed subdirectory within the SMB export.

This issue has been rated Medium (6.5) with CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H <https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H> and assigned CVE-2026-3865.

Am I vulnerable?

You may be vulnerable if:

-

You run the CSI Driver for SMB (smb.csi.k8s.io) -

Your cluster allows users to create PersistentVolumes referencing the SMB CSI driver -

Your CSI driver version does not validate traversal sequences in the subDir field

Affected Versions

-

All versions of the CSI Driver for SMB prior to the v1.20.1 release containing the fix for traversal validation are affected.

How do I mitigate this vulnerability?

This issue can be mitigated by:

-

Upgrading the CSI Driver for SMB to a patched version -

Restricting PersistentVolume creation privileges to trusted administrators -

Reviewing SMB exports to ensure only intended directories are writable by the driver

As a best practice, untrusted users should not be granted permission to create arbitrary PersistentVolumes referencing external storage drivers.

Fixed Versions

-

CSI Driver for SMB versions >= v1.20.1

Detection

To determine if your cluster may be affected:

-

Inspect PersistentVolumes using the SMB CSI driver and review the volumeHandle field. -

Look for traversal sequences such as: ../ -

Review CSI controller logs for unexpected directory operations. e.g. “Removing subPath: /tmp/mount-uuid/legitimate/../../../exports/subdir”

If you find evidence that this vulnerability has been exploited, please contact security () kubernetes io

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/138319

Acknowledgements

This vulnerability was reported by @Shaul Ben Hai, Senior Staff Security Researcher from SentinelOne.

The issue was fixed by the CSI Driver for SMB maintainers and the Kubernetes Security Response Committee.

Andy Zhang @andyzhangx

Vinayak Goyal @vinayakankugoyal

Thank You,

Vinayak Goyal on behalf of the Kubernetes Security Response Committee

A security issue was discovered in ingress-nginx where a combination of Ingress annotations can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

Hello Kubernetes Community,

A security issue was discovered in ingress-nginx where a combination of Ingress annotations can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

This issue has been rated HIGH (CVSS calculator, score: 8.8), and assigned CVE-2026-4342

Am I vulnerable?

This issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx.

Affected Versions

- ingress-nginx: < v1.13.9 - ingress-nginx: < v1.14.5 - ingress-nginx: < v1.15.1

How do I mitigate this vulnerability?

Fixed Versions

- ingress-nginx: v1.13.9 - ingress-nginx: v1.14.5 - ingress-nginx: v1.15.1

How to upgrade?

To upgrade, refer to the documentation: Upgrading Ingress-nginx

Detection

Suspicious data within the rules.http.paths.path field of an Ingress resource could indicate an attempt to exploit this vulnerability.

If you find evidence that this vulnerability has been exploited, please contact security () kubernetes io

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/137893

Acknowledgements

This vulnerability was reported by wooseokdotkim.

Thank You,

Tabitha Sable on behalf of the Kubernetes Security Response Committee

A vulnerability was discovered in the Kubernetes CSI Driver for NFS where the subDir parameter in volume identifiers was insufficiently validated. Attackers with the ability to create PersistentVolumes referencing the NFS CSI driver could craft volume identifiers containing path traversal sequences (../). During volume deletion or cleanup operations, the driver could operate on unintended directories outside the intended managed path within the NFS export. This may lead to deletion or modification of directories on the NFS server.

Hello Kubernetes Community,

A vulnerability was identified in the Kubernetes CSI Driver for NFS where insufficient validation of the subDir parameter in volume identifiers could allow path traversal. A malicious user with the ability to create a PersistentVolume referencing the NFS CSI driver could craft a volumeHandle containing traversal sequences (for example ../). When the driver performs cleanup operations during volume deletion, these sequences may cause the driver to operate on unintended directories on the NFS server.

An attacker exploiting this flaw could cause deletion or modification of directories outside the intended managed subdirectory within the NFS export.

This issue has been rated Medium (6.5) with CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H <https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H> and assigned CVE-2026-3864.

Am I vulnerable?

You may be vulnerable if:

-

You run the CSI Driver for NFS (nfs.csi.k8s.io) -

Your cluster allows users to create PersistentVolumes referencing the NFS CSI driver -

Your CSI driver version does not validate traversal sequences in the subDir field

Affected Versions

-

All versions of the CSI Driver for NFS prior to the v4.13.1 release containing the fix for traversal validation are affected.

How do I mitigate this vulnerability?

This issue can be mitigated by:

-

Upgrading the CSI Driver for NFS to a patched version -

Restricting PersistentVolume creation privileges to trusted administrators -

Reviewing NFS exports to ensure only intended directories are writable by the driver

As a best practice, untrusted users should not be granted permission to create arbitrary PersistentVolumes referencing external storage drivers.

Fixed Versions

-

CSI Driver for NFS versions >= v4.13.1

Detection

To determine if your cluster may be affected:

-

Inspect PersistentVolumes using the NFS CSI driver and review the volumeHandle field. -

Look for traversal sequences such as: ../ -

Review CSI controller logs for unexpected directory operations. e.g. “Removing subPath: /tmp/mount-uuid/legitimate/../../../exports/subdir”

If you find evidence that this vulnerability has been exploited, please contact security () 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/137797

Acknowledgements

This vulnerability was reported by @Shaul Ben Hai, Senior Staff Security Researcher from SentinelOne.

The issue was fixed by the CSI Driver for NFS maintainers and the Kubernetes Security Response Committee.

Andy Zhang @andyzhangx

Rita Zhang @ritazh

Thank You,

Rita Zhang on behalf of the Kubernetes Security Response Committee

A security issue was discovered in ingress-nginx where the nginx.ingress.kubernetes.io/rewrite-target Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

A vulnerability exists in F5 BIG-IP Container Ingress Services that may allow excessive permissions to read cluster secrets.

Hello Kubernetes Community,

A half-blind Server Side Request Forgery (SSRF) vulnerability exists in kube-controller-manager when using the in-tree Portworx StorageClass. This vulnerability allows authorized users to leak arbitrary information from unprotected endpoints in the control plane’s host network (including link-local or loopback services).

The in-tree Portworx StorageClass has been disabled by default starting in version v1.31 from the CSIMigrationPortworx feature gate. As a result, currently supported versions greater than or equal to v1.32 are not impacted unless the CSIMigrationPortworx feature gate is disabled with an override.

This issue has been rated Medium (5.8) CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N <https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N>, and assigned CVE-2025-13281.

Am I vulnerable?

You may be vulnerable if all of the following are true:

-

You are running a vulnerable version and have manually disabled the CSIMigrationPortworx feature gate. -

There are unprotected endpoints normally only visible from the control plane’s host network (including link-local metadata endpoints, unauthenticated services listening on localhost, or other services in the control plane’s private network). -

Untrusted users can create pods with the affected Portworx volume type.

Affected Versions

The CSIMigrationPortworx feature gate was enabled by default starting on version v1.31. As a result, EOL versions <= v1.30 are more likely to be vulnerable because the CSIMigrationPortworx feature is disabled by default.

-

kube-controller-manager: <= v1.30.14 -

kube-controller-manager: <= v1.31.14 -

kube-controller-manager: <= v1.32.9 -

kube-controller-manager: <= v1.33.5 -

kube-controller-manager: <= v1.34.1

How do I mitigate this vulnerability?

This issue can be mitigated by upgrading to a fixed kube-controller-manager version or by enabling the CSIMigrationPortworx feature gate (if it was overridden from its default value in versions greater than equal to v1.31).

Fixed Versions

-

kube-controller-manager: >= v1.32.10 -

kube-controller-manager: >= v1.33.6 -

kube-controller-manager: >= v1.34.2

Detection

This issue can be detected on clusters which have the CSIMigrationPortworx feature gate disabled on impacted versions by analyzing ProvisioningFailed events from kube-controller-manager which may contain sensitive information from the control plane’s host network.

If you find evidence that this vulnerability has been exploited, please contact security () kubernetes io

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/135525

Acknowledgements

The issue was fixed and coordinated by:

Ankit Gohil @gohilankit

Thank You,

Nathan Herz on behalf of the Kubernetes Security Response Committee

A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This vulnerability allows a remote, unauthenticated attacker to execute arbitrary SQL commands via a specific ArcGIS Feature Service operation. Successful exploitation can potentially result in unauthorized access, modification, or deletion of data from the underlying Enterprise Geodatabase.

A vulnerability exists in the Kubernetes C# client where the certificate validation logic accepts properly constructed certificates from any Certificate Authority (CA) without properly verifying the trust chain. This flaw allows a malicious actor to present a forged certificate and potentially intercept or manipulate communication with the Kubernetes API server, leading to possible man-in-the-middle attacks and API impersonation.

Hello Kubernetes Community,

A vulnerability exists in the Kubernetes C# client where the certificate validation logic accepts properly constructed certificates from any Certificate Authority (CA) without properly verifying the trust chain. This flaw allows a malicious actor to present a forged certificate and potentially intercept or manipulate communication with the Kubernetes API server, leading to possible man-in-the-middle attacks and API impersonation.

This issue has been rated Med (6.8) CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N <https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N>, and assigned CVE-2025-9708.

Am I vulnerable?

You are vulnerable if:

- You use the Kubernetes C# client to connect to a Kubernetes API server over TLS/HTTPS with custom CA certificates in your kubeconfig file and your connection occurs over an untrusted network.

Affected Versions

-

All versions of the Kubernetes C# client prior to the next release <=17.0.13

How do I mitigate this vulnerability?

This issue can be mitigated by:

-

Deploy the patch version of the Kubernetes C# client as soon as possible. -

Moving the CA certificates into the system trust store instead of specifying them in the kubeconfig file. Note: This approach may introduce new risks, as all processes on the system will begin to trust certificates signed by that CA. If you must use an affected version, you can disable custom CA and add the CA to the machine's trusted root.

Fixed Versions

-

Kubernetes C# client >= v17.0.14

Detection

To determine if your applications are affected:

-

Review your usage of the Kubernetes C# client and inspect certificate validation logic. -

Review your kubeconfig files and determine if you use a custom CA certificate (the certificate-authority field in the clusters section). -

Review client logs for unexpected or untrusted certificate connections.

If you find evidence that this vulnerability has been exploited, please contact security () 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/134063

Acknowledgements

This vulnerability was reported by @elliott-beach

The issue was fixed and coordinated by:

Boshi Lian @tg123

Brendan Burns @brendandburns

Rita Zhang @ritazh

Thank You,

Rita Zhang on behalf of the Kubernetes Security Response Committee

Hello Kubernetes Community,

A security issue was discovered in secrets-store-sync-controller where an actor with access to the controller logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when there is a specific error marshaling the parameters sent to the providers.

Am I vulnerable?

To check if tokens are being logged, examine the manager container log:

bash kubectl logs -l 'app.kubernetes.io/part-of=secrets-store-sync-controller' -c manager -f | grep --line-buffered "csi.storage.k8s.io/serviceAccount.tokens"

Affected Versions

- secrets-store-sync-controller < v0.0.2

How do I mitigate this vulnerability?

Upgrade to secrets-store-sync-controller v0.0.2+

Fixed Versions

- secrets-store-sync-controller >= v0.0.2

Detection

Examine cloud provider logs for unexpected token exchanges, as well as unexpected access to cloud vault secrets.

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

Acknowledgements

This vulnerability was reported by Reem Rotenberg and Kas Dekel from Microsoft.

A vulnerability exists in the NodeRestriction admission controller in Kubernetes clusters where node users can delete their corresponding node object by patching themselves with an OwnerReference to a cluster-scoped resource. If the OwnerReference resource does not exist or is subsequently deleted, the given node object will be deleted via garbage collection.

A security issue was discovered in the Kubernetes Image Builder where default credentials are enabled during the Windows image build process when using the Nutanix or VMware OVA providers. These credentials, which allow root access, are disabled at the conclusion of the build. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project and the vulnerability was exploited during the build process, which requires an attacker to access the build VM and modify the image while the build is in progress.

Hello Kubernetes Community,

A security issue was discovered in Kubernetes where an unauthorized user may be able to ssh/RDP/WINRM to a Windows node VM which uses a VM image built with the Kubernetes Image Builder project ( https://github.com/kubernetes-sigs/image-builder).

For Windows images built with Nutanix, OVA, this issue has been rated High

( https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H )(8.1)

Am I vulnerable?

Clusters using virtual machine images built with Kubernetes Image Builder ( https://github.com/kubernetes-sigs/image-builder) version v0.1.44 or earlier are affected.

CVE-2025-7342: VMs using Windows images built with Nutanix, OVA were confirmed vulnerable.

VMs using images built with all other providers are not affected.

Affected Versions

Kubernetes Image Builder versions <= v0.1.44

To determine the version of Image Builder you are using, use one of the following methods:

For git clones of the image builder repository: cd <local path to image builder repo>

make version

For installations using a tarball download: cd <local path to install location>

grep -o v0\\.[0-9.] RELEASE.md | head -1

For a container image release:

docker run --rm <image pull spec> version or podman run --rm <image pull spec> version

or look at the image tag specified, in the case of an official image such as registry.k8s.io/scl-image-builder/cluster-node-image-builder-amd64:v0.1.44

How do I mitigate this vulnerability?

Rebuild any affected images using a fixed version of Image Builder. Re-deploy the fixed images to any affected VMs or use image-builder v0.1.41 (February 2025) or later, and set the adminpassword JSON variable.

Prior to upgrading, this vulnerability can be mitigated by changing the password of the Administrator account on affected VMs:

net user Administrator <new-password>

Fixed Versions

Kubernetes Image Builder versions >= v0.1.45

Detection

Get-LocalUser -Name Administrator | Select-Object Name,Enabled,SID,Lastlogon | Format-List

If you find evidence that this vulnerability has been exploited, please contact security () kubernetes io

Additional Details

See the GitHub issues for more details:

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

Acknowledgements

This vulnerability was reported by Abdel Adim Oisfi, Davide Silvetti, Nicolò Daprelà, Paolo Cavaglià, Pietro Tirenna from Shielder.

The issue was fixed and coordinated by Matt Boersma of the Image Builder project.

Thank You,

Rita Zhang on behalf of the Kubernetes Security Response Committee

Headlamp is an extensible Kubernetes web UI. A command injection vulnerability was discovered in the codeSign.js script used in the macOS packaging workflow of the Kubernetes Headlamp project. This issue arises due to the improper use of Node.js's execSync() function with unsanitized input derived from environment variables, which can be influenced by an attacker. The variables ${teamID}, ${entitlementsPath}, and ${config.app} are dynamically derived from the environment or application config and passed directly to the shell command without proper escaping or argument separation. This exposes the system to command injection if any of the values contain malicious input. This vulnerability is fixed in 0.31.1.

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.

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 <https://www.first.org/cvss/calculator/3-1#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 security () 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

Hello Kubernetes Community,

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Am I affected?

Kubernetes built with Go versions prior to 1.21.11 or 1.22.4 are affected.

Affected Versions

- <1.30.2

- <1.29.6

- <1.28.11

- <1.27.15

How do I mitigate this issue?

Upgrade to a fixed (or newer) version of Kubernetes.

Fixed Versions

- 1.30.2+

- 1.29.6+

- 1.28.11+

- 1.27.15+

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/

Detection

This issue could be detected by looking for unexpected file deletions on a Node.

If you find evidence that this vulnerability has been exploited, please contact security () kubernetes io

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/132267

Acknowledgements

This issue was reported by Addison Crump

Thank You,

Craig Ingram on behalf of the Kubernetes Security Response Committee

On Mon, Mar 24, 2025 at 02:38:17PM -0500, Tabitha Sable wrote: Hello oss-sec,

Multiple issues have been discovered in ingress-nginx that can result in arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

The most serious of these issues has been rated Critical ( CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H>) (Score: 9.8), and assigned CVE-2025-1974. Am I vulnerable?

-

This issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. -

You can check this by running kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Affected Versions

-

All versions prior to v1.11.0 -

v1.11.0 - 1.11.4 -

v1.12.0

How do I mitigate this vulnerability?

ACTION REQUIRED: The following steps must be taken to mitigate these vulnerabilities: Upgrade ingress-nginx to v1.11.5, v1.12.1, or any later version.

Before applying the patch, these issues can be partially mitigated by disabling the Validating Admission Controller functionality of ingress-nginx. Fixed Versions

-

v1.11.5 -

v1.12.1 Apparently these versions have not been released yet[0]. So for the moment, only the partial mitigation can be done.

[0]: https://github.com/kubernetes/kubernetes/issues/131005#issuecomment-2749372605 To upgrade, refer to the documentation: Upgrading Ingress-nginx <https://kubernetes.github.io/ingress-nginx/deploy/upgrade/> Detection

If you find evidence that these vulnerabilities have been exploited, please contact security () kubernetes io Additional Details

See these GitHub issues for more details: CVE-2025-24513: https://github.com/kubernetes/kubernetes/issues/131005

CVE-2025-24514: https://github.com/kubernetes/kubernetes/issues/131006

CVE-2025-1097: https://github.com/kubernetes/kubernetes/issues/131007

CVE-2025-1098: https://github.com/kubernetes/kubernetes/issues/131008

CVE-2025-1974: https://github.com/kubernetes/kubernetes/issues/131009 Acknowledgements

These vulnerabilities were reported by Nir Ohfeld, Ronen Shustin, Sagi Tzadik, and Hillai Ben Sasson, from Wiz

These issues were fixed and coordinated by Marco Ebert, James Strong, Tabitha Sable, and the Kubernetes Security Response Committee

Thank You,

Tabitha Sable, on behalf of the Kubernetes Security Response Committee

A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced.

Hello Kubernetes Community,

A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced.

This issue has been rated Low (3.1) CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N>, and assigned CVE-2024-7598.

Am I vulnerable?

All clusters that rely on the NetworkPolicy API may be vulnerable. Run the following command to see if network policies are in use:

kubectl get networkpolicies.networking.k8s.io --all-namespaces

Affected Versions

-

kube-apiserver >= v1.3

How do I mitigate this vulnerability?

This issue can be mitigated by:

-

Manually deleting pods and workload resources that orchestrate pods before starting namespace deletion -

Adding finalizers to network policies to prevent them from being deleted until the pods that they protect have been deleted first. The following proof-of-concept controller automates this process:

-

https://github.com/kubernetes-sigs/network-policy-finalizer

Fixed Versions

-

None. A longer term comprehensive fix is proposed in the following KEP: -

https://github.com/kubernetes/enhancements/pull/5095

Detection

Users of network policies may be able to detect abuse via network logs. The exact details of this process are environment specific.

If you find evidence that this vulnerability has been exploited, please contact security () kubernetes io

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/126587

Acknowledgements

This vulnerability was reported by John McGuinness @s1xtw03 and Aaron Coffey @aaroncoffey.

The issue was coordinated by:

Antonio Ojea @aojea

Tim Hockin @thockin

Dan Winship @danwinship

Shane Utt @shaneutt

David Eads @deads2k

Clayton Colemon @smarterclayton

Mo Khan @enj

Craig Ingram @cji

Thank You,

Craig Ingram on behalf of the Kubernetes Security Response Committee