AKS RunCommand Vulnerability Enables Cross-Cluster Privilege Escalation

A newly disclosed weakness in Azure Kubernetes Service’s RunCommand feature created a path for attackers to intercept a privileged Entra ID access token during command execution and replay it against other AKS clusters in the same tenant. 

The issue, discovered by Ben Zamir from Cymulate Research Labs, showed how a token intended for a single administrative RunCommand operation could become a tenant-wide lateral movement primitive. Because the token was broadly scoped and not bound to a specific cluster or host, an attacker with local node access or existing cluster-admin privileges could use it to impersonate the invoking administrator across other AKS environments. 

This research highlights a growing cloud security problem: once attackers gain access to identity material, traditional boundaries such as clusters, resource groups, subscriptions, VNets, and environments may no longer provide meaningful isolation. 

Executive Summary 

 A chain of weaknesses was identified in the Azure Kubernetes Service (AKS) RunCommand feature when used with Microsoft Entra ID authentication. These issues allowed an attacker with either local node access or existing cluster-admin privileges to intercept a valid Entra ID access token during RunCommand execution. 

Because the token was broadly scoped at the tenant level and was not bound to a specific cluster, host, or request, it could be replayed in a pass-the-token attack. This allowed the attacker to impersonate the administrative user and gain cluster-admin access to other AKS clusters within the same tenant, based on that user’s permissions. 

Following responsible disclosure, Microsoft acknowledged the issue and deployed a cloud-side fix, which has been automatically applied to AKS clusters. This blog post outlines the technical details, exploitation paths, and recommended mitigations.  

Check out the practical, actionable advice for CISOs and organizations currently utilizing AKS at the end of this blog. 

AKS RunCommand Privilege & Token Security Weaknesses 

Our research identified three key findings of sensitive credentials exposure, improper access control and improper authorization. 

Sensitive Credentials Exposure 

When using the RunCommand feature over an Entra ID managed AKS cluster, an Entra ID access token is injected into the RunCommand pod’s filesystem where it is accessible to processes within the node or identities with cluster-based access, enabling token theft and cross-cluster lateral movement. 

Improper Access Control

RunCommand pods are not restricted to system node pools, they are scheduled on user nodes. This enables a low-privileged user node compromise to escalate to cluster-admin and then move laterally across clusters. 

Improper Authorization

RunCommand injects tokens that carry a broad scope granting access to every AKS cluster in the tenant based on the impersonated user's privileges. 

Building Blocks of the Exposure and Attack 

What is Azure Kubernetes Service (AKS)?  

Azure Kubernetes Service is Microsoft's managed Kubernetes offering on Azure. AKS abstracts away control-plane management, Microsoft operates the API server, etcd, and scheduler, while customers manage their workloads across one or more node pools. Node pools come in two flavors: system node pools, which run core Kubernetes components, and user node pools, which host application workloads. In Entra ID auth type deployments, both cluster access and administrative operations are authenticated through Azure Active Directory, tying Kubernetes RBAC directly to Azure identity. 

What is the RunCommand feature?  

Run Command allows administrators to execute commands on an AKS cluster without requiring direct network connectivity from their local machine to the Kubernetes API server. This is especially useful for private clusters where the API server is not publicly accessible. However, the feature still relies on Azure’s control plane being able to reach the cluster nodes, so it does not work in fully isolated environments. 

When a user invokes RunCommand, whether from the Azure Portal, the Azure CLI (az aks command invoke), or the Azure SDK, the following happens under the hood: 

1. Azure creates a short-lived pod inside the aks-command namespace of the target cluster. That pod will execute the command inside the cluster’s network. 

2. The invoking user requests an Entra ID access token which is automatically injected into the pod as a Kubernetes secret volume before the command runs. 

3. The command is executed inside the pod. Using the injected credentials, the pod can execute authenticated commands with the same permissions the administrator holds in the cluster. 

4. The pod terminates once execution is complete and results are returned to the caller. 

The Run Command pod isn’t restricted to system node pools and may be scheduled on user nodes instead. This introduces additional risk, since user nodes typically host primary and sometimes externally exposed workloads. If such a node is compromised (for example, via a pod-to-node escape), it could provide a path to interact with the sensitive Run Command pod. More on that below. 

Why AKS RunCommand tokens can be reused across clusters 

In Entra ID-integrated AKS deployments, the token injected into the RunCommand pod is scoped to the tenant’s AKS service and not to any individual cluster. This means the same credential is valid across every AKS cluster in the tenant that the authenticating user has access to. The token is also a plain bearer token with no Proof-of-Possession binding, meaning it can be replayed freely by anyone who obtains a copy of it. 

Individually, these design choices might be acceptable trade-offs. The problem arises when the token is accessible to anything other than the intended command execution, which is exactly what the vulnerabilities described below enable. 

What is a Proof-Of-Possession type token and how Arc-joined clusters use them?  

 A Proof-of-Possession (PoP) token is a security token that is cryptographically bound to a key controlled by the client. It is also scoped to a specific request and includes a one-time nonce, which prevents reuse. 

When RunCommand is executed on an Arc-enabled cluster, it uses PoP tokens. This means that even if a token is intercepted, it cannot be replayed. 

Azure Arc–enabled clusters rely on PoP tokens to ensure that only the legitimate client can use a token for a specific request. In contrast, standard AKS RunCommand does not provide the same level of protection against token replay. 

Exploitation Walkthrough 

Two distinct attack paths were validated during research, each reflecting realistic threat scenarios in enterprise Azure environments. 

Option A: From a Cluster-Admin Starting Point 

An attacker who already holds cluster-admin in an Entra ID authentication integrated AKS cluster can intercept the administrator's token by targeting the RunCommand execution pod lifecycle. 

1. Set an Interception Trap.  

The attacker deploys a Kubernetes admission webhook or a policy rule (e.g., via Kyverno) within the aks-command namespace that intercepts newly created execution pods and pauses them before they complete. Because RunCommand pod lifecycles are tightly coupled to command execution duration, pausing ensures the pod remains alive long enough for token extraction. 

2. Wait for a Legitimate RunCommand Invocation.  

The attacker waits for an administrative user to invoke RunCommand through the Azure Portal, CLI, or SDK as part of normal operations. This is a routine action for platform engineers and cluster administrators. 

3. Token Automatically Injected Into the Pod.  

When the RunCommand pod is created, AKS automatically injects the administrative user's Entra ID access token into the pod's Kubernetes secret file before executing the command. This token is the same one used to authenticate the administrator against the AKS cluster API. 

4. Exec Into the Pod and Extract the Token.  

Using kubectl exec, the attacker drops into the paused pod and reads the injected secret from the pod's filesystem. Inspection of the token reveals it is bound only to the tenant, not to a specific cluster or resource group. 

Note: This process can be fully automated. An attacker can deploy a silent "trap" that extracts the token and immediately releases the execution pod, making the attack subtle and nearly instantaneous. 

5. Pass-the-Token Across Clusters.  

Because the extracted token carries tenant-level scope and is not Proof-of-Possession bound, it can be replayed directly. The attacker uses the token to impersonate the administrative user and execute commands with full cluster-admin authority on any other AKS cluster in the tenant that the user has access to. This includes clusters in different resource groups or intended to represent different environments (e.g., production). 

Option B: From a Compromised User Node 

Because the RunCommand flow was not restricted to system nodes, it could also be abused from user nodes, which as noted above, typically host application workloads and are significantly more likely to be compromised through exposed containers such as public-facing web applications. This attack path shows that node-level access (a relatively common foothold) is sufficient to escalate into tenant-wide cluster-admin access. 

1. RunCommand Pods Land on User Nodes by Default.  

During testing, all RunCommand execution pods were observed scheduling exclusively onto user node pools rather than system node pools. Users have no control over this scheduling behavior. This is a critical design gap: a pod carrying a privileged Entra ID token may run on the same node as a compromised, externally-facing workload container. 

2. Deploy a Listening Exploit on the Compromised Node.  

With root access on the user node, the attacker deploys an automated exploit process. The exploit monitors the node's container runtime for new pods being created in the aks-command namespace, and upon detecting a RunCommand execution pod, automatically reads and exfiltrates the injected Entra ID access token from its secret volume. 

3. Token Is Captured Without Any User Interaction.  

When an administrator invokes RunCommand from the Azure Portal, the execution pod may be scheduled on the compromised user node. The exploit silently captures the token the moment it is injected. From the victim's perspective, the RunCommand operation completes normally. 

4. Escalate Across the Tenant.  

With the token in hand, the attacker proceeds as in Option A: replaying the token in a pass-the-token attack against other AKS clusters in the tenant, inheriting all privileges of the impersonated administrator. 

Impact 

The combined exploitation of these weaknesses breaks multiple security boundaries simultaneously. Because the tenant-scoped bearer token is not bound to any specific cluster or audience, a single interception event can enable: 

• Logical boundary bypass, resource groups, environments (dev/staging/prod), and subscriptions can all be crossed using a single stolen token 
• Network segmentation bypass, different VNet configurations offer no protection. Token replay works against any reachable AKS API endpoint 
• Workload compromise, cluster-admin access on production clusters enables reading secrets, exfiltrating data, deploying backdoored containers, and disrupting services 
• Compounding risk with managed identities, cluster workloads frequently carry managed identity credentials. Cross-cluster access multiplies the blast radius significantly 

Microsoft Fix 

To mitigate this issue, Microsoft appears to have changed how AKS RunCommand handles authentication. In the current implementation, AKS requires a managed identity to be assigned to the cluster. When RunCommand is invoked, the token and resulting Kubernetes privileges originate from the attached managed identity rather than from the invoking user. 

As a result, RunCommand no longer exposes or reuses the administrator’s own Entra ID token. Instead, organizations must explicitly configure the managed identity with the permissions required for operational tasks.  

This shifts privilege scoping back to the customer. If the identity is granted broad access, RunCommand remains powerful, but the blast radius is now determined by the permissions assigned to that managed identity rather than by the privileges of the user who initiated the command. 

Practical Guidance for CISOs and Organizations 

Microsoft's cloud-side fix closes this specific token-binding gap, but the broader pattern (broadly scoped Entra ID tokens crossing cluster and tenant boundaries) is not unique to AKS RunCommand. Treat identity as a first-class security boundary and assume any token reachable from a workload or node might be replayed elsewhere in the tenant. 

Organizations operating Azure Kubernetes Service environments should:  

• Evaluate and assign only the necessary permissions to the attached managed identity, following the principle of least privilege. 
• Prioritize identity-centric monitoring and standard hardening practices. 
• Constrain how privileged identities authenticate and consider Conditional Access policies 
• Hunt for token reuse anomalies. 
• Validate detections, do not just deploy them. Confirm your SIEM, XDR, and Microsoft Defender for Cloud rules actually fire. Cymulate's identity and cloud attack scenarios are designed for continuous end-to-end validation. 

Conclusion  

This issue highlights how identity-based attack paths can bypass traditional isolation boundaries in cloud environments. A single exposed token was enough to move across clusters and escalate privileges. 

As identity becomes the primary security boundary, detecting and preventing these attacks requires strong identity-focused monitoring and correlation across services. 

With Cymulate, security teams can continuously validate their ability to detect and respond to identity-based attack paths and ensure their controls are working as intended. 

To see how Cymulate helps organizations uncover privilege escalation paths, validate cloud identity security controls, and continuously assess exposure across hybrid environments, request a personalized demo with our team.