CVE-2026-97146

Executive Summary

CVE-2026-97146 is an authorization bypass in Apache YuniKorn 1.9.0 and earlier in which the validation that constrains the content of the user-info annotation is skipped whenever a pod carries the label app=yunikorn. Because that label is also used to identify the YuniKorn application itself within deployments, any user who can submit a pod with that label can attach an arbitrary user-info annotation. The result is unauthorized queue selection and quota-tracking manipulation — a user can place workloads into queues they are not entitled to, and can corrupt per-user quota accounting even when the pod ultimately runs in the correct queue. All YuniKorn deployments running 1.9.0 or earlier that permit untrusted users to create pods are in scope.

Technical Analysis

Apache YuniKorn is a resource scheduler for Kubernetes and Apache Hadoop YARN. In this product, scheduling queues are associated with user identities, and the scheduler derives the effective user identity from a user-info annotation attached to the workload (pod). Validation logic exists to limit what that annotation may contain so that a submitting user cannot simply assert an arbitrary identity.

CVE-2026-97146 describes a logic flaw in that validation path:

• The control: a check that "limits the user annotation content" — i.e., the code path that sanitizes or restricts the user-info annotation so a user cannot claim arbitrary user information.
• The bypass: if the pod carries the label app=yunikorn, that check is not run.
• The reason the label is privileged: app=yunikorn is the label "used to identify the YuniKorn application itself in the deployments" — it is an operational marker used by the platform, not a security boundary. Because it is user-settable on submitted pods, it is trivially attacker-controlled.

The net effect is an incorrect authorization / authentication-bypass-by-spoofing condition. The identity supplied in the annotation is trusted downstream by the scheduler without the guard that would normally constrain it. There is no memory corruption, no remote code execution, and no privilege escalation at the OS or cluster level implied by the description; the flaw is a trust-boundary error inside YuniKorn's scheduling authorization model.

Two distinct downstream trust relationships are documented as affected:

1. Queue access control. "The arbitrary user information could allow access to a queue that the user normally would not have access to."
2. Quota accounting. "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."

The second point is important: even when the pod is correctly placed, forging the user annotation allows a submitter to escape the accounting of resources consumed against their own identity — degrading the integrity of the multi-tenant quota model itself.

Note on the label semantics: the description states the check is skipped when the label app=yunikorn is present. This is a straightforward string-match guard. No additional parameter, endpoint, or function name is provided in the source data; the specific code path is not disclosed, so no function or class names are asserted here.

The CNA did not publish a title, CWE, or CVSS vector. The affected-version statement is version-based ("1.9.0 and earlier"), not a package-version range, and no OSV package mapping is available. This report's CVSS vector is an analyst estimate derived from the described impact (network-reachable, low complexity, low privileges required, no user interaction, limited confidentiality/integrity impact, no availability impact); it is NOT a vendor-published score.

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template exists for CVE-2026-97146. The attack chain below is inferred from the vulnerability class (authorization bypass via spoofable identifier) and from the explicit statements in the NVD description. No specific function names, endpoints, or API paths are asserted, because none are provided in the source data.

1) Reconnaissance / target identification. The attacker identifies a Kubernetes environment running Apache YuniKorn 1.9.0 or earlier. This is established by checking the YuniKorn version exposed through the scheduler's deployment artifacts or by the presence of YuniKorn components in the cluster. The attacker needs only the ability to submit a pod — a low-privilege capability in most multi-tenant clusters.

2) Triggering the flaw. The attacker authors a pod manifest that includes two attacker-controlled fields:

• the label app=yunikorn, which the description states causes the user-annotation checks to be skipped, and
• a user-info annotation whose value is chosen arbitrarily by the attacker rather than being constrained to the attacker's own identity.

Because the deployment uses app=yunikorn to identify the YuniKorn application itself, the guard intended to constrain annotation content does not execute for this pod.

3) Payload / execution at the vulnerability-class level. There is no code execution payload. The "payload" is the forged annotation value itself — an arbitrary user identity. When YuniKorn processes the pod, it accepts the unvalidated annotation and derives scheduling identity from it. The attacker has, in effect, impersonated a privileged or unrelated user to the scheduler.

4) Post-exploitation impact.

• Queue selection: the pod is admitted to a queue the submitting user would not normally be permitted to use. The attacker consumes that queue's capacity and can starve legitimate tenants of that queue.
• Quota accounting corruption: because user-based quota enforcement and tracking key off the same annotation, the resources consumed by the attacker's workload are attributed to the forged identity — or not attributed to the attacker at all. Per-user quotas can be sidestepped even when the pod lands in the intended queue.
• Operational confusion: workloads mislabeled app=yunikorn and placed into incorrect queues can disrupt the scheduler's own operational assumptions and any tooling that treats that label as authoritative.

The blast radius is bounded to YuniKorn's queue and quota model. The description does not claim container escape, node compromise, or access to other tenants' data beyond the queue-allocation and quota-tracking effects listed.

Impact Assessment

Affected systems: Apache YuniKorn 1.9.0 and earlier, deployed as a scheduler in front of Kubernetes or YARN workloads, in environments where users who should not have unrestricted queue access are nonetheless permitted to create pods.

Business impact: The vulnerability undermines the multi-tenant isolation guarantees of the scheduling layer. Two concrete harms follow directly from the description:

• Unauthorized resource access: a tenant can claim capacity in queues reserved for other teams or for higher-priority/privileged workloads, causing resource contention and potential starvation of legitimate workloads.
• Quota integrity loss: because "user based quota enforcement is also based on the user annotation," forged annotations corrupt the accounting that backs fair-share and per-user quota policy. This can allow a tenant to exceed its entitlement without triggering quota enforcement, and it can pollute chargeback/showback data used for internal cost allocation.

Blast radius: Scoped to the cluster(s) running the affected YuniKorn version. There is no evidence in the provided data of lateral movement, data exfiltration, or RCE. The primary risk is availability degradation for correctly-behaving tenants and integrity loss of scheduling/quota metadata.

CVSS subscores (analyst estimate, not vendor-published): AV:N (scheduler is network-reachable), AC:L (the bypass is a simple label/annotation manipulation with no race or special conditions), PR:L (requires the ability to submit a pod), UI:N (no victim interaction), S:U (impact stays within the scheduling component's security authority), C:L (leaks queue/user information indirectly), I:L (quota and queue state are altered), A:N. Score is limited by the absence of confidentiality, integrity, and availability impacts beyond the scheduling layer.

EPSS: Not yet scored by FIRST.org. No EPSS value is asserted here. CISA KEV: Not listed. Exploit availability: None public.

Detection Guidance

Sigma Rule

title: Apache YuniKorn User Annotation Bypass via app=yunikorn Label
id: 8f2c1e4a-9b7d-4c3e-a1f0-6d5e2b9c7a11
status: experimental
description: Detects pod creation or workload submission carrying the label app=yunikorn in combination with a user-info annotation, consistent with CVE-2026-97146 abuse.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-97146
author: valtersit.com
date: 2026-01-01
logsource:
  product: kubernetes
  service: audit
detection:
  selection_label:
    requestObject.metadata.labels.app: 'yunikorn'
  selection_annotation:
    requestObject.metadata.annotations|contains: 'user'
  selection_verb:
    verb:
      - create
      - patch
      - update
  filter_system:
    user.username|startswith:
      - 'system:'
      - 'system:serviceaccount:kube-system'
  condition: selection_label and selection_annotation and selection_verb and not filter_system
falsepositives:
  - Legitimate YuniKorn control-plane components creating pods with the app=yunikorn label
level: high
tags:
  - attack.t1190
  - attack.t1548

YARA Rule

rule CVE_2026_97146_YuniKorn_Annotation_Bypass
{
    meta:
        description = "Detects YuniKorn pod manifests that set app=yunikorn together with a user-info annotation (CVE-2026-97146 bypass pattern)"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-97146"
        severity = "high"

    strings:
        $label   = "app: yunikorn" ascii nocase
        $label2  = "app=yunikorn" ascii nocase
        $annot   = "annotations:" ascii nocase
        $user    = "user" ascii nocase
        $annkey  = "yunikorn.apache.org/user" ascii nocase

    condition:
        ( any of ($label, $label2) ) and
        ( $annot and $user ) or $annkey
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-97146 Apache YuniKorn app=yunikorn Label User-Annotation Bypass Attempt"; flow:established,to_server; content:"app"; http_cookie; nocase; content:"yunikorn"; nocase; content:"annotation"; nocase; content:"user"; nocase; pcre:"/app[\"']?\s*[:=]\s*[\"']?yunikorn/i"; reference:cve,2026-97146; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-97146; classtype:attempted-admin; sid:202697146; rev:1;)

Elastic Detection

// Detects pod submissions that combine the app=yunikorn label with a forged user annotation.
// CVE-2026-97146: the annotation validation check is skipped when the label app=yunikorn is present.
kubernetes.audit where
  event.action in ("create", "patch", "update") and
  kubernetes.audit.requestObject.metadata.labels.app == "yunikorn" and
  kubernetes.audit.requestObject.metadata.annotations : "user" and
  not user.name : "system:*"

Splunk SPL Query

index=kubernetes sourcetype="kube:apiserver:audit"
  (verb=create OR verb=patch OR verb=update)
  ("requestObject.metadata.labels.app"="yunikorn" OR requestObject.metadata.labels.app=yunikorn)
  ("requestObject.metadata.annotations"=*user*)
  NOT user.username=system:*
| stats count min(_time) as first_seen max(_time) as last_seen
        values(requestObject.metadata.annotations) as annotations
        values(requestObject.metadata.name) as pod_name
        by user.username requestObject.metadata.namespace
| where count > 0
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - count

Wazuh OSSEC Rule

<group name="kubernetes,yunikorn,">
  <rule id="202697" level="12">
    <decoded_as>json</decoded_as>
    <field name="verb">create|patch|update</field>
    <field name="requestObject.metadata.labels.app">yunikorn</field>
    <field name="requestObject.metadata.annotations" type="pcre2">user</field>
    <description>Possible CVE-2026-97146 exploitation: pod submitted with app=yunikorn label and user annotation, bypassing YuniKorn annotation validation.</description>
    <mitre>
      <id>T1190</id>
      <id>T1548</id>
    </mitre>
    <group>cve_2026_97146,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations

   • Restrict who may create or modify pods in namespaces where YuniKorn schedules workloads. Enforce admission policies that reject user-supplied pods carrying the label app=yunikorn, since that label is intended to identify the YuniKorn application itself and should not be user-settable on ordinary workloads.
   • Use a Kubernetes admission controller (ValidatingAdmissionPolicy / webhook) to strip or block user-info annotations on pods unless submitted by an authorized, trusted service account.
   • Audit existing deployments for any pods carrying app=yunikorn that were not created by the YuniKorn control plane; investigate their annotations for forged identities and reattribute or refund consumed quota.
   • Reconcile queue usage and per-user quota accounting, as the description states quota tracking can be sidestepped even when the workload runs in the intended queue.

2. Patch / upgrade steps

   • Upgrade Apache YuniKorn to 1.10.0, which the CNA states fixes this issue.
   • After upgrading, verify that the annotation validation path is no longer conditioned on the app=yunikorn label by testing with a pod that sets both the label and an arbitrary user annotation; confirm the annotation is rejected or constrained.
   • Validate the fix in a staging cluster before rolling to production, since scheduling policy changes can affect queue behavior.

3. Long-term hardening

   • Treat all user-supplied workload metadata (labels, annotations) as untrusted input. Never use a user-settable field as a trust signal that gates a security check.
   • Adopt least-privilege RBAC in the cluster so that only scheduling control-plane components may set identity-defining metadata.
   • Monitor for suspicious annotations and labels with the detections above, and include YuniKorn version inventory in regular dependency/vulnerability scanning.
   • Track the Apache YuniKorn project's security advisories for follow-up patches.

References

• NVD — CVE-2026-97146: https://nvd.nist.gov/vuln/detail/CVE-2026-97146
• Apache YuniKorn project (vendor/upstream): https://yunikorn.apache.org/
• Apache Software Foundation security advisories: https://apache.org/security/
• Apache YuniKorn releases (1.10.0 fix): https://yunikorn.apache.org/docs/
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-97146 is NOT currently listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public PoC, exploit code, Nuclei template, or documented exploit-in-the-wild activity exists for CVE-2026-97146 at the time of writing. No threat actor campaign has been associated with this CVE in the provided data.