Impact A malicious container can affect the host by taking advantage of code cri-o added to show the container mounts on the host.

A workload built from this Dockerfile: FROM docker.io/library/busybox as source RUN mkdir /extra && cd /extra && ln -s ../../../../../../../../root etc

FROM scratch

COPY --from=source /bin /bin COPY --from=source /lib /lib COPY --from=source /extra .

and this container config:

{ "metadata": { "name": "busybox" }, "image":{ "image": "localhost/test" }, "command": [ "/bin/true" ], "linux": { } }

and this sandbox config { "metadata": { "name": "test-sandbox", "namespace": "default", "attempt": 1, "uid": "edishd83djaideaduwk28bcsb" }, "linux": { "securitycontext": { "namespaceoptions": { "network": 2 } } } }

will create a file on host /host/mtab

Patches 1.30.1, 1.29.5, 1.28.7

Workarounds Unfortunately not

References Are there any links users can visit to find out more?

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.

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 kubernetes. Users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different kind in the same API group they are not authorized to read.

A security issue was discovered in kube-apiserver that allows an aggregated API server to redirect client traffic to any URL. This could lead to the client performing unexpected actions as well as forwarding the client's API server credentials to third parties.

Node address isn't always verified when proxying

Impact It is possible to craft an environment variable with newlines to add entries to a container's /etc/passwd. It is possible to circumvent admission validation of username/UID by adding such an entry.

Note: because the pod author is in control of the container's /etc/passwd, this is not considered a new risk factor. However, this advisory is being opened for transparency and as a way of tracking fixes.

Patches 1.26.0 will have the fix. More patches will be posted as they're available.

Workarounds Additional security controls like SELinux should prevent any damage a container is able to do with root on the host. Using SELinux is recommended because this class of attack is already possible by manually editing the container's /etc/passwd

References

A flaw introduced in CRI-O version 1.19 which an attacker can use to bypass the safeguards and set arbitrary kernel parameters on the host. As a result, anyone with rights to deploy a pod on a Kubernetes cluster that uses the CRI-O runtime can abuse the “kernel.corepattern” kernel parameter to achieve container escape and arbitrary code execution as root on any node in the cluster.

Description An ExecSync request runs a command in a container and returns the output to the Kubelet. It is used for readiness and liveness probes within a pod. The way CRI-O runs ExecSync commands is through conmon. CRI-O asks conmon to start the process, and conmon writes the output to disk. CRI-O then reads the output and returns it to the Kubelet.

If the output of the command is large enough, it is possible to exhaust the memory (or disk usage) of the node. The following deployment is an example yaml file that will output around 8GB of ‘A’ characters, which would be written to disk by conmon and read by CRI-O.

yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment100 spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 lifecycle: postStart: exec: command: ["/bin/sh", "-c", "seq 1 50000000; do echo -n 'aaaaaaaaaaaaaaaa'; done"]

Impact It is possible for the node to be exhausted of memory or disk space, depending on the node the command is being run on. What is further problematic is that the memory and disk usage aren't attributed to the container, as this file and its processing are implementation details of CRI-O. The consequence of the exhaustion is that other services on the node, e.g. other containers, will be unable to allocate memory and thus causing a denial of service.

Patches This vulnerability will be fixed in 1.24.1, 1.23.3, 1.22.5, v1.21.8, v1.20.8, v1.19.7

Workarounds At the time of writing, no workaround exists other than ensuring only trusted images are used.

References https://github.com/containerd/containerd/security/advisories/GHSA-5ffw-gxpp-mxpf

For more information If you have any questions or comments about this advisory: Open an issue in the CRI-O repo To make a report, email your vulnerability to the private cncf-crio-security@lists.cncf.io list with the security details and the details expected for all CRI-O bug reports.

Credits Disclosed by Ada Logics in a security audit sponsored by CNCF and facilitated by OSTIF.

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with ephemeral containers.

This issue affects kube-apiserver. Clusters are impacted by this vulnerability if:

1. The ServiceAccount admission plugin is used. Most clusters should have this on by default as recommended in https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount 2. The kubernetes.io/enforce-mountable-secrets annotation is used by a service account. This annotation is not added by default. 3. Pods using ephemeral containers.

A security issue was discovered in kube-apiserver that could allow node updates to bypass a Validating Admission Webhook. Clusters are only affected by this vulnerability if they run a Validating Admission Webhook for Nodes that denies admission based at least partially on the old state of the Node object. Validating Admission Webhook does not observe some previous fields.

A flaw was found in Kubernetes, where the amount of disk space the /etc/hosts file can use is unconstrained . This flaw can allow attacker-controlled pods to cause a denial of service if they have permission to write to the node's /etc/hosts file.

A server side request forgery (SSRF) flaw was found in Kubernetes. The kube-controller-manager allows authorized users with the ability to create StorageClasses or certain Volume types to leak up to 500 bytes of arbitrary information from the master's host network. This can include secrets from the kube-apiserver through the unauthenticated localhost port (if enabled).

A flaw was found in the Kubernetes API server, where it allows an attacker to escalate their privileges from a compromised node. This flaw allows an attacker who can intercept requests on a compromised node, to redirect those requests, along with their credentials, to perform actions on other endpoints that trust those credentials (including other clusters), allowing for escalation of privileges. The highest threat from this vulnerability is to confidentiality, integrity, and system availability.

Cloud Native Computing Foundation (CNCF) CNI (Container Networking Interface) 0.7.4 has a network firewall misconfiguration which affects Kubernetes. The CNI 'portmap' plugin, used to setup HostPorts for CNI, inserts rules at the front of the iptables nat chains; which take precedence over the KUBE- SERVICES chain. Because of this, the HostPort/portmap rule could match incoming traffic even if there were better fitting, more specific service definition rules like NodePorts later in the chain. The issue is fixed in CNI 0.7.5 and Kubernetes 1.11.9, 1.12.7, 1.13.5, and 1.14.0.

The Kubernetes API server mistakenly allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced. Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges).

A third issue was discovered with the Kubernetes kubectl cp command that could enable a directory traversal such that a malicious container could replace or create files on a user’s workstation. The vulnerability is a client-side defect and requires user interaction to be exploited.

This vulnerability allows a malicious container to cause a file to be created or replaced on the client computer when the client uses the kubectl cp operation. The vulnerability is a client-side defect and requires user interaction to be exploited.

Upstream Issue:

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

External References:

https://groups.google.com/forum/#!topic/kubernetes-security-discuss/Vf31dXp0EJc

A flaw was found kubernetes. The parsing of YAML manifests by the Kubernetes API server could lead to a denial-of-service attack leaving it vulnerable to an instance of a "billion laughs" attack. The highest threat from this vulnerability is to system availability.

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.

As mitigations to a report from 2019 and CVE-2020-8555, Kubernetes attempts to prevent proxied connections from accessing link-local or localhost networks when making user-driven connections to Services, Pods, Nodes, or StorageClass service providers. As part of this mitigation Kubernetes does a DNS name resolution check and validates that response IPs are not in the link-local (169.254.0.0/16) or localhost (127.0.0.0/8) range. Kubernetes then performs a second DNS resolution without validation for the actual connection. If a non-standard DNS server returns different non-cached responses, a user may be able to bypass the proxy IP restriction and access private networks on the control plane.

A security issue was discovered in Kubernetes where actors that control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the apiserver. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack.

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.

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.

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.

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.

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

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.

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