Apache YuniKorn EUVD-2026-94253

Exploitation requires an authenticated Kubernetes user who holds UPDATE/patch permission on workload objects (deployments, replicasets, statefulsets, daemonsets, jobs, or cronjobs) in a cluster where YuniKorn (≤1.9.0) performs admission control for queue placement and quota. The attacker must first create a workload and then modify it via UPDATE - the CREATE path correctly enforces label and user-annotation checks, so the bypass only exists on the UPDATE action (the vendor's UI:P/AT:P reflect this staged, update-triggered precondition). The attack has practical value only in multi-tenant deployments that rely on YuniKorn queues and user-based quota as an isolation/governance boundary; in single-tenant or fully trusted-user clusters there is no meaningful boundary to cross. Limiting factors: requires existing RBAC to update workloads, impact is confined to queue placement and quota accounting (no host/data compromise), and clusters on 1.10.0+ are not affected.

This is a low-severity authorization/admission-control bypass in Apache YuniKorn, not a code-execution or data-disclosure flaw. The only severity signal provided is the vendor's CVSS 4.0 base score of 2.0 (low) with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N - network reachable but gated behind a present attack requirement (AT:P), high privileges (PR:H), and passive user interaction (UI:P), with only limited integrity impact and no confidentiality or availability impact. No EPSS score, CISA KEV listing, POC reference, or SSVC decision was supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The real-world risk is low and multi-tenant/governance-oriented: the flaw lets an authenticated user who can UPDATE workloads escape the label and user-annotation checks that CREATE enforces, spoofing user info or rewriting the application ID to land work in a queue they should not reach or to evade user-based quota tracking. This is a priority chiefly for operators of shared, multi-tenant YuniKorn clusters relying on queue/quota isolation as a security boundary; for single-tenant or trusted-user clusters it is largely a correctness issue. The signals are internally consistent (all low, no exploitation intelligence), so there is no conflicting high-CVSS-but-low-risk tension to flag here.

A legitimate but low-privilege tenant in a shared Kubernetes cluster submits a compliant workload via CREATE (which passes checks), then issues an UPDATE to a deployment, job, or statefulset that injects a forged user-info annotation and changes the application ID. Because UPDATE skips the label/annotation validation, the workload is admitted into a higher-priority or better-resourced queue the user is not entitled to, and the user's quota accounting is bypassed. No public POC is referenced, but the technique is straightforward for anyone already authorized to patch their own workload objects.