Kubernetes on Windows Vulnerability: What You Should Know

Table of Contents

• Module 1: The Kubernetes Windows Node Privilege Escalation Vulnerability
  • Kubernetes and Container Orchestration Overview
  • Vulnerability Discovery and Disclosure Timeline
  • Technical Root Cause: Insufficient Input Sanitization in Volume Mounts
  • Exploitation Mechanics and Privilege Escalation Flow
  • Affected Versions and Exploitation Prerequisites
  • Real-World Exploitation Likelihood
  • CVSS Scoring Breakdown
  • Organizational Risk Assessment Framework
  • Detection Guidance
  • Remediation: Patching
  • Mitigating Controls Beyond Patching
• Summary

Module 1: The Kubernetes Windows Node Privilege Escalation Vulnerability

Kubernetes and Container Orchestration Overview

Organizations that run containerized workloads at scale frequently rely on Docker containers to package services or applications. Once an environment grows to include hundreds or thousands of containers spread across many hosts, manually managing each of them becomes impractical. Kubernetes is a container orchestration platform designed to solve this problem: it applies consistent configuration across an entire fleet of containers, and it provides self-healing behavior so that if a container crashes, Kubernetes automatically brings it back up. This centralizes and simplifies configuration management across large, distributed deployments.

A useful illustration of this pattern is a large multi-location retail chain (the kind of organization that operates a Kubernetes cluster spanning every physical store location nationwide). Each store location functions as an individual node in the cluster, running point-of-sale software and other local services. Metrics and operational data from each node are reported back to a centralized location for monitoring and management. For an organization operating at that scale, having to manage each store’s endpoint individually, or having local staff perform configuration changes at each site, would be extremely complex and error-prone. Kubernetes removes that burden by allowing centralized configuration and orchestration across every node, regardless of physical location.

Some Kubernetes clusters include Windows nodes — worker nodes running the Windows operating system rather than Linux — to support workloads that require Windows-specific services or applications. The vulnerability discussed in this module is specific to how Kubernetes handles certain configuration operations on these Windows nodes.

mindmap
  root((Why Kubernetes?))
    Container Sprawl
      Hundreds or thousands of Docker containers
      Multiple locations/endpoints
    Orchestration Benefits
      Consistent configuration across the fleet
      Self-healing / auto-restart
      Centralized management
    Real-World Pattern
      Nationwide retail chain example
      Each store = a node
      Point-of-sale + metrics reported centrally
    Windows Nodes
      Some clusters mix Linux and Windows workers
      Windows-specific vulnerability surface

Vulnerability Discovery and Disclosure Timeline

This vulnerability followed a responsible disclosure process:

• July 13: Akamai security researchers discovered the vulnerability and reported it to the Kubernetes project.
• July 19: A CVE identifier was formally assigned to the issue.
• August 23: The Kubernetes project released fixes for the vulnerability. At the same time, the project also patched two additional, closely related CVEs that addressed similar underlying weaknesses in the same function area.
• September 13: Akamai published a public blog post disclosing further technical details, along with a working Proof of Concept (PoC), and a demonstration video of the exploit in action.

timeline
    title Disclosure and Patch Timeline
    July 13 : Akamai discovers the vulnerability
            : Reported to the Kubernetes project (responsible disclosure)
    July 19 : CVE identifier formally assigned
    August 23 : Kubernetes releases fixes
              : Two additional related CVEs patched in the same release
    September 13 : Akamai publishes blog post
                 : Proof of Concept (PoC) and exploit video released publicly

Technical Root Cause: Insufficient Input Sanitization in Volume Mounts

At its core, this is an insufficient input sanitization vulnerability. An attacker who can submit or modify a Kubernetes YAML configuration file can inject content into that file which is later executed as code, resulting in privilege escalation.

To understand how this happens, it helps to walk through what occurs when a pod is created. A pod is simply a set of one or more Docker containers scheduled and managed together. As part of creating a pod, Kubernetes supports volume mounting — attaching a shared storage location that is accessible both to the host system and to the container running inside it. Volume mounts are an extremely common and legitimate part of everyday Kubernetes configuration.

The component responsible for validating pod configuration on a node — including the configuration governing volume mounts — is the kubelet service. The kubelet runs on every node and is responsible for applying and enforcing the configuration submitted for that node before a pod is actually started.

The vulnerability exists in how the kubelet validates the volume mount configuration on Windows nodes, specifically involving the subPath field used when mounting a volume (volume.subPath). The validation logic does not properly sanitize the input tied to this field, and this gap allows a user to embed a PowerShell command inside the YAML configuration for the volume mount. This was not an intended capability — it is the unintended side effect of incomplete input validation in the code path that processes subPath values on Windows.

Critically, the kubelet service on the Windows node runs with SYSTEM-level privileges. Because the kubelet is the process that ultimately processes and executes the injected PowerShell content as part of applying the pod’s configuration, any user who can submit a YAML file with this crafted subPath value can cause arbitrary system-level command execution on that Windows node — regardless of what privileges that user was actually granted inside the Kubernetes cluster itself.

flowchart TD
    A[Legitimate pod configuration feature:\nvolume mounting] --> B[Uses the volume.subPath field]
    B --> C[Kubelet validates the configuration\nbefore applying it]
    C --> D{Is subPath input\nproperly sanitized?}
    D -->|No - the flaw| E[Attacker embeds a PowerShell\ncommand inside the subPath value]
    D -->|Yes - patched behavior| F[Malicious subPath value\nis rejected]
    E --> G[Kubelet runs as SYSTEM\non the Windows node]
    G --> H[Embedded PowerShell command\nis executed with SYSTEM privileges]
    H --> I[Full privilege escalation /\nsystem-level code execution]

Exploitation Mechanics and Privilege Escalation Flow

The end-to-end exploitation flow can be summarized as a sequence of steps performed by an attacker who already has some level of access to submit configuration to the cluster:

1. The attacker crafts (or reuses the public PoC) a Kubernetes pod YAML manifest.
2. Inside that manifest, the attacker adds a volume mount that uses the subPath field, embedding a PowerShell command as part of the subPath value.
3. The attacker applies this manifest to the cluster (for example, via kubectl apply), targeting a pod scheduled to run on a Windows node.
4. The kubelet service on the target Windows node processes the pod creation request and validates the configuration, including the volume mount.
5. Because the subPath input is not properly sanitized, the embedded PowerShell command is passed through to execution rather than being rejected or escaped.
6. Since the kubelet process runs as SYSTEM on the Windows node, the injected PowerShell command executes with SYSTEM-level privileges.
7. The attacker now has arbitrary code execution at the highest privilege level on that Windows node, entirely independent of whatever Kubernetes RBAC permissions were actually granted to their user account.

sequenceDiagram
    participant Attacker
    participant K8sAPI as Kubernetes API Server
    participant Kubelet as Kubelet (Windows Node, runs as SYSTEM)
    participant Windows as Windows Node OS

    Attacker->>Attacker: Craft malicious pod YAML\n(volume.subPath with embedded PowerShell)
    Attacker->>K8sAPI: kubectl apply -f malicious-pod.yaml
    K8sAPI->>Kubelet: Schedule pod creation on Windows node
    Kubelet->>Kubelet: Validate pod configuration\n(insufficient input sanitization on subPath)
    Kubelet->>Windows: Process volume mount / subPath value
    Windows-->>Kubelet: Embedded PowerShell command executed
    Note over Kubelet,Windows: Kubelet runs as SYSTEM,\nso the command runs with SYSTEM privileges
    Kubelet-->>Attacker: Arbitrary system-level code execution achieved

The following illustrates, at a conceptual level, the type of manifest structure involved in the public Proof of Concept — a YAML pod definition containing a volume mount whose subPath value is manipulated to smuggle in a PowerShell command that executes when the kubelet processes the mount on the Windows node:

apiVersion: v1
kind: Pod
metadata:
  name: malicious-pod
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: payload-container
      image: mcr.microsoft.com/windows/nanoserver:ltsc2022
      volumeMounts:
        - name: shared-data
          mountPath: C:\data
          # The subPath value is where insufficiently sanitized input
          # allows an embedded PowerShell command to be smuggled through
          # and ultimately executed by the kubelet (running as SYSTEM).
          subPath: "..\\..\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command IEX(malicious-payload)"
  volumes:
    - name: shared-data
      hostPath:
        path: C:\shared
        type: Directory

This is a representative illustration of the exploitation technique described in the disclosure (crafted subPath traversal/command-injection input), not a literal reproduction of Akamai’s exact published PoC file.

Affected Versions and Exploitation Prerequisites

Two conditions determine whether an environment is exploitable:

1. Kubernetes version. Clusters running Kubernetes 1.28.0 or earlier (i.e., versions prior to the patched releases issued on August 23) are affected.
2. User permissions. The attacker needs a user account within the environment that has apply rights to the Kubernetes cluster — the ability to submit or modify pod/YAML configuration. In many, if not most, real-world environments, this turns out to be any authenticated user, since apply permissions to submit workloads are frequently granted broadly rather than tightly scoped.

Real-World Exploitation Likelihood

As of the disclosure, there had been no public reporting of this vulnerability being exploited by an adversary in the wild. However, several factors point to a high likelihood of future exploitation:

• The level of effort required is low. An adversary can take the publicly released Proof of Concept and adapt it for malicious use with minimal additional work.
• The technique is straightforward to test: an attacker (or a defender validating exposure) can simply run the PoC against a standard user account on a standard endpoint in the environment and observe whether it succeeds.
• Given the low complexity and the public availability of a working PoC, it is reasonable to expect adversaries to incorporate this technique into their playbooks going forward, even though it had not yet been observed in active campaigns at the time of disclosure.

CVSS Scoring Breakdown

The vulnerability carries a CVSS score of 8.8, reflecting both low attack complexity and a low privilege requirement for the attacker.

Organizational Risk Assessment Framework

Five practical questions can help an organization gauge its exposure and prioritize its response to this vulnerability:

flowchart TD
    Q1[Q1: What is the CVSS score?] --> A1[8.8 - High]
    Q2[Q2: Internet-facing application?] --> A2{Exposed to the internet?}
    A2 -->|Yes| R1[Broader exposure problem\nbeyond this CVE]
    A2 -->|No, expected| R2[Attacker needs existing\ninternal access - mitigating factor]
    Q3[Q3: What is the PoC?] --> A3[Public YAML file with\nembedded PowerShell in subPath]
    Q4[Q4: Exploitable in your environment?] --> A4{Run PoC against a\nstandard user/endpoint}
    A4 -->|Succeeds| R3[Vulnerable - proceed to remediation]
    A4 -->|Blocked| R4[Mitigating control already in place]
    Q5[Q5: Priority level?] --> A5[Very High for most\nWindows-node Kubernetes clusters]

Detection Guidance

If patching has not yet been completed, or if an organization wants to validate whether it has already been targeted, detection should focus on the Kubernetes audit logs. Specifically, defenders should look for:

• Pod creation events that contain embedded PowerShell commands within the configuration (particularly within volume mount / subPath fields).
• This pattern is highly irregular for legitimate workloads and is a strong indicator that something malicious is taking place.

# Example of the type of audit log entry pattern worth alerting on:
# a pod creation ("create") event whose requestObject contains a
# subPath value with embedded PowerShell content.
- kind: Event
  verb: create
  objectRef:
    resource: pods
    subresource: ""
  requestObject:
    spec:
      containers:
        - volumeMounts:
            - subPath: "..\\..\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command <suspicious-payload>"
  annotations:
    detection.note: "Embedded PowerShell command inside subPath - irregular for legitimate workloads"

As with most vulnerabilities of this type, standard foundational security best practices — timely patching, monitoring, and access control — remain the most effective overall defense.

Remediation: Patching

The immediate action for any organization that is not already on a patched release (the fixes issued on August 23) is to patch as soon as possible. As with most vulnerabilities of this nature, applying the vendor-provided fix promptly is the single most important remediation step.

# Check the current Kubernetes control-plane and kubelet versions
kubectl version --short

# Check kubelet version specifically on each node (including Windows nodes)
kubectl get nodes -o wide

# After patching, verify nodes are running a fixed release
kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET_VERSION:.status.nodeInfo.kubeletVersion

Mitigating Controls Beyond Patching

Patching is not always an option that can be applied immediately — organizational constraints or other factors may delay it. The Kubernetes project’s own disclosure states that, outside of applying the provided patch, there are no known mitigations for this vulnerability. In practice, however, there are several effective mitigating controls organizations can apply while working toward a full patch:

1. Open Policy Agent (OPA). OPA is an open-source policy engine that can be used to inspect and block YAML configuration submissions based on a defined rule set. A rule set can be written to detect and block YAML files that contain embedded PowerShell commands before they are ever applied to the cluster.

   package kubernetes.admission
   
   # Deny pod creation if any subPath value appears to contain
   # an embedded PowerShell invocation.
   deny[msg] {
       input.request.kind.kind == "Pod"
       some i
       volume_mount := input.request.object.spec.containers[_].volumeMounts[i]
       contains(lower(volume_mount.subPath), "powershell")
       msg := sprintf("Blocked: subPath contains an embedded PowerShell command (%v)", [volume_mount.subPath])
   }
   

2. Role-Based Access Control (RBAC). Restricting which users are permitted to apply configuration changes to the cluster — rather than granting broad “apply” rights to every user across the enterprise — directly reduces the pool of accounts that could exploit this vulnerability. Not every user across an organization needs the ability to apply configuration changes to a Kubernetes cluster, and tightening this is a control most organizations should already have in place regardless of this specific CVE.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: production
     name: restricted-pod-applier
   rules:
     - apiGroups: [""]
       resources: ["pods"]
       verbs: ["get", "list", "watch"]   # no "create"/"update"/"patch" for general users
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: restricted-pod-applier-binding
     namespace: production
   subjects:
     - kind: Group
       name: general-users
       apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: restricted-pod-applier
     apiGroup: rbac.authorization.k8s.io
   

3. Disabling the subPath feature. The specific function call at the root of the vulnerability is volume.subPath. Disabling this feature closes off the vulnerable code path entirely, though it does come at the cost of losing certain legitimate volume-mounting capabilities that rely on subPath. This same mitigation approach was previously used to address related Kubernetes vulnerabilities disclosed in 2021 and 2022 — organizations that already disabled subPath in response to those earlier issues may have inadvertently pre-mitigated themselves against this vulnerability as well.

   # Example: disabling the VolumeSubpath feature gate on the kubelet
   # (kubelet configuration / command-line flag)
   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   featureGates:
     VolumeSubpath: false
   

flowchart LR
    subgraph Mitigation Architecture
        direction TB
        M1[Open Policy Agent\nblocks YAML with embedded PowerShell]
        M2[RBAC restricts who can\napply cluster configuration]
        M3[Disable volume.subPath\nfeature gate]
    end
    YAML[Incoming pod YAML manifest] --> M1
    M1 -->|Blocked if malicious pattern found| Blocked1[Rejected before admission]
    M1 -->|Passes policy check| M2
    M2 -->|User lacks apply rights| Blocked2[Rejected by RBAC]
    M2 -->|User authorized| M3
    M3 -->|subPath disabled| Blocked3[subPath feature unavailable\nvulnerable path closed]
    M3 -->|subPath enabled, patched kubelet| Applied[Pod applied safely\non patched kubelet]

Summary

This vulnerability is an insufficient input sanitization flaw in how the kubelet service validates the volume.subPath field when processing pod configuration on Windows nodes in a Kubernetes cluster. Because the kubelet runs with SYSTEM-level privileges on those nodes, an attacker who can submit a crafted YAML manifest — requiring only “apply” rights to the cluster, which are commonly granted broadly — can embed a PowerShell command that executes with full system privileges, achieving privilege escalation and arbitrary code execution across any affected Windows endpoint in the cluster.

The issue was responsibly disclosed by Akamai in July, patched by the Kubernetes project on August 23 alongside two related CVEs, and followed by a public Proof of Concept and technical write-up in September. It carries a CVSS score of 8.8, driven by low attack complexity and low required privileges, and affects Kubernetes 1.28.0 and earlier. While no in-the-wild exploitation had been publicly reported at the time of disclosure, the low effort required to weaponize the public PoC makes future adversary adoption likely.

Mitigation Checklist

• Patch immediately. Upgrade Kubernetes control plane and kubelet components on all Windows nodes to a release that includes the August 23 fixes (and the two related CVE fixes).
• Verify version exposure. Confirm no clusters remain on Kubernetes 1.28.0 or earlier.
• Review audit logs. Search Kubernetes audit logs for pod creation events containing embedded PowerShell commands in subPath or other volume mount fields.
• Deploy Open Policy Agent (or equivalent). Implement a policy rule set that inspects and blocks YAML submissions containing embedded PowerShell commands.
• Tighten RBAC. Ensure “apply” rights to the cluster are scoped to only the users and service accounts that genuinely require them, rather than granted broadly across the organization.
• Evaluate disabling subPath. Where the feature is not required, disable the volume.subPath feature gate as a defense-in-depth measure (also effective against related 2021/2022 Kubernetes vulnerabilities).
• Confirm no internet-facing exposure. Ensure the ability to apply cluster configuration is never directly reachable from the internet.
• Reassess priority. Treat this as a high-priority item for any organization operating Windows nodes within a Kubernetes cluster, given the low complexity and high impact of successful exploitation.

Search Terms

kubernetes · windows · vulnerability · know · briefings · networking · systems · security · exploitation · escalation · patching · privilege