CVE-2026-32193 was published on June 9, 2026 carrying an 8.8 CVSS score and an EPSS of 0.00336. Its entire official description is one sentence, so the aggregator sites repeated that sentence and recycled the same patch-and-RBAC advice. The researchers behind the bug picked a very different headline: "From AKS node root vulnerability to Microsoft Copilot hijack (CVE-2026-32193)." That second story is the one almost nobody told.
What the CVE record actually says
Microsoft's description, republished by NVD:
"Improper limitation of a pathname to a restricted directory ('path traversal') in Microsoft Azure Kubernetes Service allows an authorized attacker to execute code locally."
The vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base score 8.8, contributed by Microsoft as CNA. Local attack vector, low privileges required, no user interaction, scope changed, and High impact across confidentiality, integrity and availability. The subscores are 2.0 exploitability and 6.0 impact. NVD provides no CVSS 4.0 or 2.0 assessment, so 8.8 is the only number on the tin.
The affected range runs from version 1.0 up to but excluding v0.20260213.5, which NIST's CPE configuration renders as "2026-02-13.5". That looks like a node image build stamp rather than an upstream Kubernetes semver, and the fix arrives through the AKS update channel as node image upgrades. Both point the same direction: this flaw lives in Microsoft-built node-side components, not in upstream Kubernetes. That part is inference, but it fits everything Microsoft published.
Then there is the naming fight nobody covered. Microsoft's CNA title calls this an "Azure Kubernetes Service (AKS) Remote Code Execution Vulnerability." The vector says local. cvefeed's entry flatly states "Remotely Exploit: No." Nobody reconciled these, so here is my read: on a managed service, "local" is measured from the node's perspective. An authenticated tenant with code execution inside their own pod already occupies the position the vector describes. They never needed node shell. "Authorized attacker" in Microsoft's own wording lines up with PR:L. Call it local if it helps you triage; the attacker calls it a normal Tuesday with a working deployment.
The public coverage is thinner than it looks
Two of the main public write-ups on this CVE are openly machine-written. OpenCVE labels its entry "Generated by OpenCVE AI on June 9, 2026" and manages to claim "No vendor fix or workaround currently provided" in one breath while recommending the Microsoft update in the next. SentinelOne's database entry carries the disclaimer "This content was generated using AI... please verify critical information with official sources," and it is still the most technically useful page available. That tells you something about the rest of the field.
Context explains the neglect. June 2026 was, per a CrowdStrike headline surfaced by cvefeed, a 206-vulnerability Patch Tuesday with three publicly disclosed zero-days and 37 Criticals, and per TheCyberThrone the largest Patch Tuesday ever, passing the record of 167 set in October 2025. In a month like that, a "local" path traversal with an EPSS under one percent sinks without a bubble.
The kill chain, with the honest parts labeled
Here is the state of the public record. The r/netsec post announcing the research exists, but its body was not retrievable when I went looking, and the repost circulating under the same title (an RSS repost dated August 17) contains no technical content at all. So stages one through three below are grounded in the CVE record and SentinelOne's analysis. Stage four is public only as a title. I will flag that line instead of pretending it away.
Stage 1: the traversal
CWE-22. Per SentinelOne's analysis, the flaw sits in AKS file path handling where input is not canonicalized against a restricted base directory, so ../ sequences or absolute path overrides escape the intended root. cvefeed maps the CVE to CAPEC patterns 64, 76, 78, 79 and 126, the usual family of path traversal and encoding-bypass attacks, which is why encoded indicators like %2e%2e%2f appear in the detection guidance.
Stage 2: out of the container
The S:C in the vector is the load-bearing character. SentinelOne's summary: "Successful exploitation crosses a security scope boundary, meaning the impact extends beyond the privileges of the initially compromised component. This is consistent with container-to-host or pod-to-node escapes commonly observed in Kubernetes path-handling flaws." The traversal is the lockpick; the scope change is the door. A read or write that lands outside the container filesystem, aimed at the right host path, is the difference between a pod bug and a node bug.
Stage 3: root on the node
PR:L means the attacker needs a low-privilege starting position, not that they keep it. Code execution in the node's own context is root-adjacent, and root on an AKS node is a position rather than a prize. A managed node holds the kubelet's credentials, the projected service account tokens of every pod scheduled to it, the container runtime socket, and whatever cloud identity material the node is allowed to fetch. Every workload on that node just inherited the attacker.
Stage 4: the Copilot hop (reconstruction, not reporting)
Public detail ends at the word "hijack." What follows is the standard shape of this attack class, stated as such.
AI assistants wired into cloud control planes do not act on their own authority. They act through identities holding cloud API permissions, frequently broad ones, because the product promise is that the assistant can do things for you. From a compromised node, the attacker's shopping list is whatever identity material is reachable: projected workload identity tokens, pod service account credentials, node-level managed identity access. If any identity in that reach can call APIs the assistant's control plane trusts, touch the resources the assistant operates on, or assume a role in that path, then node root stops being a node problem. It becomes a question of what the assistant is allowed to do, and whether anyone notices when "the assistant" does it.
Why assistant identities are now escalation targets
This is the part the CVE aggregators missed entirely. An assistant wired into a cloud control plane is a privilege concentrator by design: one identity, standing permissions, acting for many users. Its activity blends into legitimate automation, so its audit entries read as normal until someone asks why it was enumerating node credentials at 3 a.m. The attacker does not need a vulnerability in the assistant. They need to reach something the assistant trusts. A node-side container escape plus an over-scoped identity is exactly that, and it generalizes far beyond this one CVE. Model assistant identities like tier-0 accounts, because that is what they are.
Tenant checks for this week
Confirm every node pool is past the fixed build
The fixed line is v0.20260213.5, and Microsoft shipped the fix through the AKS update channel:
az aks get-upgrades --resource-group <rg> --name <cluster> --output table
az aks upgrade --resource-group <rg> --name <cluster> \
--kubernetes-version <patched-version>
az aks nodepool upgrade --resource-group <rg> --cluster-name <cluster> \
--name <pool> --node-image-onlyRun the node image upgrade across every pool, not just the system pool, then verify each pool's reported image version. Do not assume one pool's fix propagated to the others.
Hunt for the traversal and the escape
Patching closes the hole; it says nothing about whether someone used it. SentinelOne's detection ideas, which I endorse:
- Traversal sequences (../, ..\. %2e%2e%2f) or absolute paths pointed at /etc, /var/lib/kubelet, or /host mounts
- Unexpected child processes spawned by kubelet or AKS system components
- Writes to /etc/kubernetes, /var/lib/kubelet, or container runtime sockets from non-system principals
- Workload identities performing operations against host-scoped resources
Forward kube-audit and kube-audit-admin logs somewhere central, and have Azure Monitor and Defender for Containers actually enabled, not just licensed.
Shrink what a compromised node can hand out
Enforce Pod Security Admission baselines, disable privileged containers, and restrict hostPath volume mounts. Put network policy on east-west traffic toward AKS management endpoints. None of this is exotic, and all of it raises the cost of stage two.
Audit RBAC and workload identity reach
# Who holds cluster-admin?
kubectl get clusterrolebindings -o json | \
jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
.metadata.name, (.subjects[]? | "\(.kind)/\(.name)")'
# Which service accounts are federated to Azure identities?
kubectl get serviceaccounts -A -o json | \
jq -r '.items[] |
select(.metadata.annotations["azure.workload.identity/client-id"] != null) |
"\(.metadata.namespace)/\(.metadata.name)"'For every federated account that comes back, pull the Azure role assignments on the backing identity and cut anything it does not provably need. Least-privilege RBAC is boring advice until a node escape turns a wildcard binding into a control-plane incident.
Treat your assistant's identity like tier-0
Inventory every AI assistant with cloud API permissions in your tenant. Document which identity each one uses, what Azure roles and Kubernetes bindings that identity holds, and whether any credential reachable from cluster-scheduled workloads sits in its trust path. Then alert on the assistant's identity doing anything node-adjacent or outside its normal operating hours. If you cannot answer "what could a compromised node do with our assistant's permissions?" today, that is the finding.
The case for ignoring this, and why it fails
The skeptic's version: EPSS 0.00336 ("Very Low"), not in the CISA KEV catalog, CISA's SSVC enrichment (added June 10) says exploitation "none" and automatable "no", SentinelOne confirms no public PoC, and the Copilot stage is an unpublished title. Why spend cycles?
The facts are right and the conclusion is wrong. EPSS measures the chance someone gets caught exploiting a thing, not the blast radius when they do, and SSVC's own enrichment rates technical impact "total." A scope-crossing primitive on a managed node converts any foothold, a vulnerable dependency or a leaked CI credential, into node root, and node root into whatever identities were left within reach. The node image upgrade takes an afternoon. The identity audit is the part you will be glad you finished if a PoC ever drops.
Key takeaways
- CVE-2026-32193 is a node-side path traversal (CWE-22) with a scope change in the vector. The fixed build is v0.20260213.5, delivered via node image upgrades. Patch every pool and verify.
- The chain is confirmed through container-to-host escape; the Copilot stage is public only as a research title. Take the reconstruction seriously anyway, because the identity path from node to control plane is standard Azure plumbing, not speculation.
- EPSS 0.00336 and no KEV listing describe observed exploitation, not blast radius. SSVC rates the technical impact "total."
- After patching, hunt: traversal strings in logs, kubelet child processes, writes to /etc/kubernetes and /var/lib/kubelet, workload identities touching host-scoped resources.
- Map every AI assistant identity holding cloud API permissions and scope it like a tier-0 account. The next chain will not need a Copilot vulnerability. It will only need Copilot's permissions.
