Hi,

I'm disclosing a vulnerability in kubernetes/cloud-provider-gcp that I reported to Google Cloud VRP on 2026-06-14 (Issue #523808414). The 90-day disclosure deadline I communicated to the vendor (2026-10-06) has passed with no substantive response beyond automated queue acknowledgments and a priority reassignment to P2. I've independently reconfirmed the issue remains present in master as of 2026-10-11.

A CVE ID has been requested from MITRE's CNA-LR (CAN-2026-2039459, pending). I'll follow up with the CVE ID once assigned.

Affected component: pkg/gcpcredential/gcpcredential.go, line 314 Project: https://github.com/kubernetes/cloud-provider-gcp

Description:

auth-provider-gcp is a kubelet credential provider plugin deployed on every GKE node, invoked by kubelet on every image pull from GCR/Artifact Registry. ContainerRegistryProvider.Provide() unconditionally logs the raw GCE metadata server response body via klog.Errorf when JSON parsing of the token response fails:

if err := json.Unmarshal([]byte(tokenJSONBlob), &parsedBlob); err != nil { klog.Errorf("while parsing json blob %s: %v", tokenJSONBlob, err) return cfg }

tokenJSONBlob is the raw HTTP response from the GCE metadata server ( http://metadata.google.internal./computeMetadata/v1/instance/service-accounts/default/token), which contains a valid GCP OAuth2 access token. klog.Errorf logs at ERROR level regardless of kubelet's -v verbosity flag, guaranteeing the token reaches system/kubelet logs whenever a malformed or truncated JSON response is received (e.g. due to network issues, proxy truncation, or transient metadata service problems).

This is a regression of CVE-2020-8563. The same binary explicitly guards against this exact pattern elsewhere (cmd/auth-provider-gcp/app/getcredentials.go:130):

// The error from json.Marshal is intentionally not included so as to not leak credentials into the logs return fmt.Errorf("error marshaling credentials")

Attack preconditions: - GKE Standard cluster without Pod Security Standards enforcement (common default; GKE Autopilot is unaffected - hostPath blocked by policy) - Malformed/truncated JSON response from the metadata server (realistic via network timeout, proxy truncation, or transient metadata service issues) - Attacker controls a pod on the same node, with either a hostPath mount to the kubelet log location, or Cloud Logging read access for the node

Impact:

An attacker who controls a pod on a GKE Standard node can exfiltrate the node's GCE service account access token from system logs when a metadata server parse failure occurs, then authenticate to GCP APIs with that service account's privileges. Impact scales with the node SA's OAuth scope: - devstorage.readonly (minimum): unauthorized read access to GCR/Artifact Registry images across the project - cloud-platform (GKE default for non-hardened clusters): read/write access across all GCP services in the project - storage, compute, secrets, KMS

PoC and full reproduction steps (standalone Go harness + kind cluster integration test) were included in the original Cloud VRP report; happy to share on request.

Nebojša Jaćović

A path traversal vulnerability was discovered in the Kubernetes kubectl client's kubectl cp command on Windows. When copying files from a container, kubectl runs tar inside the container to build a tar archive, transfers it over the network, and unpacks it on the local machine. If the tar binary in the container is malicious, it can execute arbitrary code and emit unexpected output, allowing an attacker who controls container contents to write files to arbitrary paths on the user's local machine when kubectl cp is invoked, limited only by the system permissions of the local user. This issue only affects kubectl clients running on Windows.

Hello Kubernetes Community,

A security issue was discovered in Kubernetes where a malicious tar binary in a container may be able to write files to arbitrary paths on the local machine of a user running kubectl cp on Windows, limited only by the permissions of the local user.

This issue has been rated Medium (CVSS calculator: https://www.first.org/cvss/calculator/3.1) (score 6.5), and assigned CVE-2026-19444.

Am I vulnerable?

You are affected if you run the kubectl client on Windows and use kubectl cp to copy files from a container whose contents you do not fully control. This issue only affects clients on Windows platforms; Linux and macOS clients are not affected.

To determine whether your kubectl client is an affected version, run: kubectl version --client

Affected Versions

- kubectl v1.34.0 to v1.34.11 - kubectl v1.35.0 to v1.35.8 - kubectl v1.36.0 to v1.36.4

How do I mitigate this vulnerability?

Prior to upgrading, this vulnerability can be mitigated by only copying files from containers you trust, or by avoiding kubectl cp from untrusted containers on Windows.

Fixed Versions

- kubectl >= v1.34.12 - kubectl >= v1.35.9 - kubectl >= v1.36.5

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/141294

Acknowledgements

This vulnerability was reported by Moriel Harush.

The issue was fixed and coordinated by Marly Salazar, Maciej Szulik, and Vyom Yadav.

Thank You,

Vyom Yadav on behalf of the Kubernetes Security Response Committee

Hello Kubernetes Community,

An NTLM coercion vulnerability exists on Windows nodes when the subPath supplied in a pod's volumeMounts is set to a symbolic link that points to an attacker-controlled network share. When a kubelet resolves symlinks, it does not reject a target that resolves to a UNC path. As a result, the kubelet will transparently attempt to authenticate to the share using NTLM.

This allows an attacker to obtain the NetNTLMv2 hash of the account under which the kubelet is running. An attacker could then attempt to crack the hash to retrieve the corresponding password or relay it to impersonate the node, if the node is domain-joined.

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-2026-76654.

Affected Versions

-

kubelet: <= v1.34.11 -

kubelet: <= v1.35.8 -

kubelet: <= v1.36.4 -

kubelet: = v1.37.0

How do I mitigate this vulnerability?

This issue can be mitigated by upgrading to a fixed kubelet version. The fixed versions update kubelet to refuse UNC symlink targets on Windows.

Fixed Versions

-

kubelet: >= v1.34.12 -

kubelet: >= v1.35.9 -

kubelet: >= v1.36.5 -

kubelet: >= v1.37.1

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/142098

Acknowledgements

This vulnerability was reported by the Kubernetes Third-Party Security Audit subproject, OSTIF, and Shielder.

The issue was fixed and coordinated by:

Yuanliang Zhang @zylxjtu

Verónica López @Verolop

Jeremy Rickard @jeremyrickard

Nathan Herz @natherz97

Thank you,

Nathan Herz on behalf of the Kubernetes Security Response Committee

Hello Kubernetes Community,

A confused deputy attack exists in the StatefulSet controller that allows a user with namespace-scoped write permissions on StatefulSet and ControllerRevision objects to create a cross-namespace pod. An attacker exploiting this vulnerability would have full control over the resulting pod’s metadata and specification, including namespace selection. Note that the cross-namespace pod will be immediately deleted by the garbage collector unless the attacker is able to construct a valid StatefulSet OwnerReference. This would require referencing the UID of an existing StatefulSet in the victim’s namespace.

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

Affected Versions

-

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

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

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

kube-controller-manager: = v1.37.0

How do I mitigate this vulnerability?

This issue can be mitigated by upgrading to a fixed kube-controller-manager version. The fixed versions are patched to ensure that only the spec field in StatefulSets will be restored from ControllerRevisions.

Fixed Versions

-

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

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

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

kube-controller-manager: >= v1.37.1

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/142097

Acknowledgements

This vulnerability was reported by ImanOracle.

The issue was fixed and coordinated by:

Maciej Szulik @soltysh

Filip Křepinský @atiratree

Verónica López @Verolop

Jeremy Rickard @jeremyrickard

Nathan Herz @natherz97

Thank you,

Nathan Herz on behalf of the Kubernetes Security Response Committee

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. The following versions are known to be affected: Portal for ArcGIS 12.1 and earlier. Other unsupported versions may also be affected. Esri recommends that users apply the Portal for ArcGIS Security 2026 Update 2 Patch to remediate this vulnerability.

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.