Apache YuniKorn EUVD-2026-94257

Exploitation requires a multi-tenant YuniKorn deployment on Kubernetes where the admission controller enforces user-annotation restrictions and queue/user-based quotas, and requires the attacker to be able to submit pod specs to that cluster. The concrete prerequisite is the attacker's ability to set a pod label 'app=yunikorn' together with a forged 'user info' annotation - the presence of that specific label is what causes the user-annotation content checks to be skipped. Limiting factors: the attacker must already hold pod-submission access to the cluster (so this is not anonymous/external), the impact is confined to queue access and quota accounting (no data disclosure or direct service outage), and clusters not using YuniKorn's user-annotation enforcement or user-based quotas gain little benefit from the bypass. All affected deployments run Apache YuniKorn 1.9.0 or earlier (before 1.10.0).

This is a genuine but modest-priority issue, not a top-tier emergency. The vendor-supplied CVSS 4.0 score is 4.8 (medium) with vector AV:N/AC:L/AT:N/PR:H/UI:P/VC:N/VI:L/VA:N, indicating network reach but requiring privileges and yielding only low integrity impact with no confidentiality or availability loss. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so all three real-world exploitation signals point to low urgency. The practical risk is a multi-tenant integrity/governance problem: a user who can submit pods forges the 'app=yunikorn' system label to bypass user-annotation validation and impersonate arbitrary user info, defeating queue access control and user-based quota enforcement. Note a discrepancy worth verifying: the description states 'any user' can perform the bypass (implying only the ability to submit a pod, i.e. a low-privilege authenticated tenant), yet the vendor vector encodes PR:H - this tension suggests the real privilege bar may be lower than PR:H implies, so treat PR:H as possibly conservative. The UI:P component in the vendor vector is also unexplained since the attacker crafts their own pod; no victim interaction is obviously required. Overall: a legitimate access-control/quota-integrity flaw in multi-tenant clusters, but no evidence of widespread exploitation and no data exposure.

A tenant with the ability to submit workloads to a shared YuniKorn-scheduled Kubernetes cluster crafts a pod spec that includes the label 'app=yunikorn' alongside a forged user-info annotation. Because the admission controller skips user-annotation validation for pods bearing that identifying label, the forged identity is accepted, letting the attacker route the job into a privileged or higher-quota queue they should not access or sidestep per-user quota tracking. No public exploit code is identified at time of analysis; exploitation requires only standard pod-submission access and a one-line label/annotation addition.