CVE-2026-97146 in YuniKorn
Summary
by MITRE • 10/07/2026
Apache YuniKorn 1.9.0 and earlier allows bypassing the check for the user annotation by setting a secondary label on the pod. If the pod has the label 'app=yunikorn' the checks limiting the user annotation content are not run. The label is used to identify the YuniKorn application itself in the deployments.
The bypass allows any user to specify an arbitrary user info annotation. The arbitrary user information 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 the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/07/2026
Apache YuniKorn versions 1.9.0 and earlier contain a critical authorization bypass vulnerability that stems from an insufficient validation of user identity annotations within pod specifications. The core technical flaw lies in the application's logic for identifying its own managed workloads versus those submitted by external users or other systems. Specifically, when processing incoming pods, YuniKorn checks for specific labels to determine if it should enforce strict constraints on the user annotation field. If a pod is tagged with the label app=yunikorn, which is intended to identify applications deployed and controlled directly by the YuniKorn scheduler itself, the system skips the validation routines that restrict the content of the user info annotation. This logic error creates an unintended code path where any entity capable of submitting pods with this specific label can effectively disable the security controls designed to verify user identity claims.
The operational impact of this vulnerability is significant in multi-tenant Kubernetes environments where YuniKorn manages resource allocation and queueing policies. Because the validation check is bypassed, a malicious or misconfigured actor can inject arbitrary values into the user info annotation field without restriction. This capability allows an attacker to impersonate other users within the cluster's scheduling framework. By spoofing the identity of another user, the attacker gains unauthorized access to resource queues that are restricted to specific individuals or groups based on their assigned roles. This misrepresentation leads directly to privilege escalation in the context of resource management, as the scheduler treats the pod as if it belongs to a different, potentially more privileged entity than its actual submitter.
Beyond direct queue access violations, this vulnerability severely compromises quota enforcement mechanisms which are fundamental to fair resource distribution and cost control in shared clusters. YuniKorn relies on accurate user annotations to track individual or group usage against predefined quotas. When an attacker bypasses the annotation validation, they can execute workloads under a different identity, thereby circumventing per-user quota limits. This results in inaccurate accounting of resource consumption, where one entity consumes resources billed to another. In environments with strict financial or operational budgeting tied to queue utilization and user-specific caps, this flaw undermines governance policies and can lead to resource exhaustion for legitimate users whose quotas are silently exceeded by the impersonated identity.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to correctly verify the claimed identity of the pod submitter before granting access to protected resources. It also relates to CWE-915 Improvement Incorrectly Control Modification of Dynamically-Determined Object Attributes, since the user annotation is a dynamic attribute that should be strictly controlled based on context but remains modifiable by unauthorized parties due to flawed conditional logic. In terms of MITRE ATT&CK tactics, this represents an Initial Access technique where attackers exploit misconfigured permissions or trust relationships within container orchestration systems to gain foothold and move laterally across resource queues without detection.
To mitigate this risk, organizations running Apache YuniKorn must immediately upgrade to version 1.10.0 or any subsequent release that addresses the label-based validation logic error. The patch corrects the conditional checks to ensure that user annotation constraints are applied consistently regardless of pod labels, preventing unauthorized identity spoofing. Until an upgrade is feasible, administrators should implement strict network policies and RBAC rules in Kubernetes to limit which service accounts can create pods with the app=yunikorn label. Additionally, monitoring tools should be configured to alert on anomalies in queue usage patterns or unexpected spikes in resource consumption that may indicate active exploitation of this annotation bypass vulnerability.