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

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

A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.

References: https://groups.google.com/g/kubernetes-security-announce/c/QHmx0HOQa10 https://github.com/kubernetes/kubernetes/issues/118690