The official record is one sentence: an "authorized attacker," a local path traversal in Azure Kubernetes Service, 8.8 CVSS. The researchers who found the bug headlined it differently: "From AKS node root vulnerability to Microsoft Copilot hijack." Same vulnerability. The distance between those two descriptions is the story, and the aggregators missed it.
Context matters here. June 2026 brought a 206-vulnerability Patch Tuesday with three disclosed zero-days, the largest on record. A "local" traversal with an EPSS of 0.00336 sinks in that noise. The two most visible public writeups are openly machine-generated, and one claims no vendor fix exists in the same entry that recommends the Microsoft update. The actual chain never got told.
The chain, with the honest part labeled
The flaw is CWE-22 in AKS file path handling: input is not canonicalized against a restricted base directory, so ../ sequences and absolute paths escape the intended root. The fixed line is node image build v0.20260213.5, delivered through the AKS update channel. Both facts point at Microsoft-built node-side components, not upstream Kubernetes.
The load-bearing character in the CVSS vector is S:C, scope changed. The traversal is the lockpick. The scope change is the container-to-host escape. Root on a managed node hands you the kubelet's credentials, every projected service account token on the box, the runtime socket, and whatever cloud identity material the node can fetch.
Worth noting: Microsoft's own title says "Remote Code Execution" while the vector says AV:L and cvefeed flatly states "Remotely Exploit: No." My read: "local" is measured from the node. An authenticated tenant running code in their own pod already holds that position. That's a normal Tuesday with a working deployment, not a high bar.
Stage four, the Copilot hop, is public only as a title, and I'm flagging that instead of pretending otherwise. The shape of this attack class is standard, though. Assistants wired into control planes act through identities holding API permissions, usually broad ones, because the product promise is that the assistant does things for you. From a compromised node, the attacker shops for whatever identity material the node can reach. If any of it can call APIs the assistant trusts or touch resources the assistant operates on, node root stops being a node problem.
Assistant identities are tier-0 now
An assistant with cloud API permissions is a privilege concentrator by design: one identity with standing permissions, acting for many users. Its activity blends into legitimate automation, so audit entries look normal until someone asks why it was enumerating node credentials at 3 a.m.
The attacker doesn't need a vulnerability in the assistant. They need to reach something the assistant trusts. A node-side escape plus an over-scoped identity is exactly that, and it generalizes well past this one CVE. Model assistant identities like tier-0 accounts, because that's what they are.
Checks for this week
Patch every pool past the fixed build, then verify each pool's reported image version. Don't assume the system pool's fix propagated.
az aks nodepool upgrade --resource-group <rg> --cluster-name <cluster> \
--name <pool> --node-image-only
Then find 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 hit, pull the Azure role assignments on the backing identity and cut anything it can't justify.
Takeaways for today:
- Fixed line is v0.20260213.5. Run node image upgrades on every pool, then verify each one reports patched.
- Hunt for ../ and %2e%2e%2f pointed at /etc, /var/lib/kubelet, or /host mounts, plus unexpected child processes under kubelet.
- Alert on your assistant's identity doing anything node-adjacent or outside normal hours. If you
Top comments (0)