CVE-2026-92393 in YuniKorn
Summary
by MITRE • 10/07/2026
Apache YuniKorn 1.9.0 and earlier does not implement label and user annotation checks for workload UPDATE action bypassing all checks. Workloads in YuniKorn are defined as the following Kubernetes objects: "deployments", "replicasets", "statefulsets", "daemonsets", "jobs", "cronjobs". The CREATE action correctly enforces the checks for all object types.
The bypass allows any user to specify an arbitrary user info annotation. The same bypass also allows changing the application ID for the workload. The combination of the two applied in one UPDATE could allow access to a queue that the user normally would not have access to. Quota usage for the queue might be impacted if the application runs in the incorrect queue. User based quota enforcement is also based on the user annotation. User quota tracking could be side stepped even if the application runs in the correct queue.
Users are recommended to upgrade to version 1.10.0, which fixes this issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/07/2026
Apache YuniKorn versions 1.9.0 and earlier contain a critical authorization bypass vulnerability within its workload management logic that allows unauthorized users to manipulate resource allocation by circumventing label and user annotation validation during update operations. This flaw specifically affects the handling of Kubernetes objects such as deployments, replicasets, statefulsets, daemonsets, jobs, and cronjobs when they are subjected to an UPDATE action. While the CREATE action for these workload types correctly enforces strict checks on labels and user annotations, the UPDATE operation fails to perform equivalent validation. This inconsistency creates a significant security gap where authenticated users can modify existing workloads without triggering the necessary authorization controls that would normally restrict their actions based on predefined policies or identity attributes.
The technical nature of this vulnerability centers on the failure to validate critical metadata fields during state changes. Specifically, an attacker with write access to any workload object in the cluster can inject arbitrary values into user info annotations and alter the application ID associated with the workload. In a properly secured environment, these annotations serve as the primary mechanism for identity verification and resource partitioning within YuniKorn's scheduling framework. By bypassing these checks during an update, a malicious actor can effectively impersonate another user or shift their computational resources into a different administrative domain than intended by the cluster administrators. This behavior aligns with CWE-284 Improper Access Control, as the system fails to enforce required security boundaries for specific API operations despite having them in place for others.
The operational impact of this vulnerability is severe due to its direct effect on resource isolation and quota enforcement mechanisms within multi-tenant Kubernetes clusters. YuniKorn relies heavily on user annotations to determine which queue a workload should be scheduled into, ensuring that different teams or projects are isolated from one another. By manipulating the application ID and user annotation via an UPDATE request, an attacker can force their workloads to run in queues they do not have permission to access. This leads to unauthorized resource consumption by high-priority tenants, potentially causing denial of service for legitimate users who rely on those resources. Furthermore, because quota enforcement is tied directly to the user identity defined in these annotations, attackers can bypass per-user quotas entirely. Even if a workload remains within an acceptable queue boundary, the ability to spoof the user ID allows it to consume shared pool limits without being counted against the attacker's actual allocated budget, leading to resource exhaustion and financial overages for cloud providers or internal cost centers.
From a threat modeling perspective, this vulnerability facilitates privilege escalation through misconfiguration exploitation rather than code execution flaws. It maps closely to MITRE ATT&CK technique T1078 Valid Accounts, where an adversary uses legitimate credentials but manipulates context to gain unauthorized access to resources. The ability to change the application ID also touches upon CWE-269 Improvement of Privileges if the queue manipulation grants administrative capabilities or higher-tier resource tiers that are normally restricted. The combination of these two bypasses creates a compound risk scenario where an attacker not only gains access to forbidden queues but also obscures their activity from quota-based monitoring and alerting systems, making detection significantly more difficult for cluster operators who rely on accurate usage metrics for capacity planning and security auditing.
To mitigate this vulnerability, organizations running Apache YuniKorn must immediately upgrade to version 1.10.0 or later, which implements the necessary validation logic for UPDATE operations consistent with CREATE actions. Until an upgrade is feasible, administrators should implement strict NetworkPolicy rules to limit who can send update requests to workload resources and consider using admission controllers such as OPA Gatekeeper or Kyverno to enforce policy checks on metadata modifications at the API server level. Additionally, auditing logs for frequent updates to user annotations or application IDs in production environments can help detect potential exploitation attempts. It is also advisable to review RBAC policies to ensure that only highly privileged service accounts have write access to workload objects, thereby reducing the attack surface available to lower-privileged users who might attempt this bypass.