CVE-2026-18949: MLflow SA token abuse escalates to

CISO Take

This flaw in Red Hat OpenShift AI's odh-dashboard lets an attacker who has already compromised the dashboard's Service Account token pivot from a scoped ML-platform identity to full cluster-administrator control, because the SA was granted permissions far broader than its dashboard function requires. That matters for AI/ML shops specifically because odh-dashboard sits at the center of multi-tenant model development platforms — once escalated, the attacker can read secrets and credentials belonging to every tenant, team, and pipeline on the cluster, not just their own namespace, defeating the isolation that lets multiple data science teams safely share infrastructure. It is not in CISA KEV, has no public exploit or Nuclei template, and CISA's SSVC decision is TRACK, with an EPSS score of just 0.4% — so this reads as a design/configuration flaw to remediate on a normal patch cycle rather than an active-exploitation emergency, though the 8.8 CVSS and low attack complexity mean it becomes serious the moment a dashboard SA token leaks via any other vector (log exposure, misconfigured secret, container escape). Patch to the fixed builds referenced in RHSA-2026:53261/53262/53263, and in the meantime audit the odh-dashboard SA's RBAC bindings to enforce least privilege scoped to its namespace instead of a cluster-wide ClusterRoleBinding, rotating the token if any prior exposure is suspected. Detection-wise, alert on the dashboard SA making API calls or resource reads outside its expected namespace/verb set, and on any ClusterRoleBinding creation or secrets access events attributable to that identity.

Sources: NVD EPSS CISA KEV ATLAS access.redhat.com OpenSSF

What is the risk?

High severity (CVSS 8.8) but low near-term exploitation likelihood: EPSS is 0.4% (top 65th percentile, not the tail), there is no CISA KEV listing, no public PoC, and no Nuclei template, and CISA's own SSVC decision is TRACK rather than Act/Attend. The real risk driver is impact, not likelihood — privileges required is low but the attacker must already hold a compromised SA token, meaning this is a privilege-escalation/blast-radius amplifier for an initial foothold rather than a standalone remote-exploitation vector. Given odh-dashboard's 683 downstream dependents, 75 other CVEs in the same package family, and a mediocre 5.6/10 OpenSSF Scorecard, the platform carries above-average baseline risk, so this CVE should be treated as high-priority patch-cycle work rather than an emergency.

How does the attack unfold?

Initial Access

Attacker obtains the odh-dashboard Service Account token through a separate compromise (leaked secret, exposed log, or another vulnerability).

AML.T0012

Privilege Escalation

Attacker uses the SA token to call the Kubernetes API directly and abuses its overly broad RBAC grants to create a cluster-admin binding for themselves.

Credential Harvesting

With cluster-admin access, attacker enumerates secrets and credentials across all namespaces, including other tenants' ML pipelines and model registries.

AML.T0055

Impact

Multi-tenant isolation is fully broken, giving the attacker persistent, cluster-wide control over every AI workload and its data on the platform.

Initial Access

Attacker obtains the odh-dashboard Service Account token through a separate compromise (leaked secret, exposed log, or another vulnerability).

AML.T0012

Privilege Escalation

Attacker uses the SA token to call the Kubernetes API directly and abuses its overly broad RBAC grants to create a cluster-admin binding for themselves.

Credential Harvesting

With cluster-admin access, attacker enumerates secrets and credentials across all namespaces, including other tenants' ML pipelines and model registries.

AML.T0055

Impact

Multi-tenant isolation is fully broken, giving the attacker persistent, cluster-wide control over every AI workload and its data on the platform.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	—	No patch
28.1K OpenSSF 5.3 691 dependents Pushed 5d ago 36% patched ~75d to patch Full package profile →
rhoai/odh-dashboard-rhel9	—	—	No patch
rhoai/odh-mod-arch-automl-rhel9	—	—	No patch
rhoai/odh-mod-arch-autorag-rhel9	—	—	No patch
rhoai/odh-mod-arch-eval-hub-rhel9	—	—	No patch
rhoai/odh-mod-arch-gen-ai-rhel9	—	—	No patch
rhoai/odh-mod-arch-maas-rhel9	—	—	No patch
rhoai/odh-mod-arch-model-registry-rhel9	—	—	No patch

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 47% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

Patch to the fixed odh-dashboard builds referenced in RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263 as soon as they are validated in staging. Until patched, manually tighten the odh-dashboard Service Account's RBAC: replace any ClusterRole/ClusterRoleBinding with namespace-scoped Role/RoleBindings limited to the verbs and resources the dashboard actually needs, and remove wildcard or cluster-admin-equivalent grants. Rotate the SA token proactively if there is any chance it was exposed (CI logs, misconfigured secrets, prior incidents). For detection, enable Kubernetes audit logging on the odh-dashboard SA identity and alert on: API calls outside its expected namespace, reads of secrets/configmaps in namespaces it doesn't own, and creation/modification of ClusterRoleBindings or RoleBindings attributed to that SA.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Framework AML.T0012 - Valid Accounts AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.4 - Security of AI system

NIST AI RMF

MANAGE-2.3 - Procedures are followed to respond to, and recover from, a previously unknown risk when it is identified

Frequently Asked Questions

What is CVE-2026-18949?

This flaw in Red Hat OpenShift AI's odh-dashboard lets an attacker who has already compromised the dashboard's Service Account token pivot from a scoped ML-platform identity to full cluster-administrator control, because the SA was granted permissions far broader than its dashboard function requires. That matters for AI/ML shops specifically because odh-dashboard sits at the center of multi-tenant model development platforms — once escalated, the attacker can read secrets and credentials belonging to every tenant, team, and pipeline on the cluster, not just their own namespace, defeating the isolation that lets multiple data science teams safely share infrastructure. It is not in CISA KEV, has no public exploit or Nuclei template, and CISA's SSVC decision is TRACK, with an EPSS score of just 0.4% — so this reads as a design/configuration flaw to remediate on a normal patch cycle rather than an active-exploitation emergency, though the 8.8 CVSS and low attack complexity mean it becomes serious the moment a dashboard SA token leaks via any other vector (log exposure, misconfigured secret, container escape). Patch to the fixed builds referenced in RHSA-2026:53261/53262/53263, and in the meantime audit the odh-dashboard SA's RBAC bindings to enforce least privilege scoped to its namespace instead of a cluster-wide ClusterRoleBinding, rotating the token if any prior exposure is suspected. Detection-wise, alert on the dashboard SA making API calls or resource reads outside its expected namespace/verb set, and on any ClusterRoleBinding creation or secrets access events attributable to that identity.

Is CVE-2026-18949 actively exploited?

No confirmed active exploitation of CVE-2026-18949 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-18949?

Patch to the fixed odh-dashboard builds referenced in RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263 as soon as they are validated in staging. Until patched, manually tighten the odh-dashboard Service Account's RBAC: replace any ClusterRole/ClusterRoleBinding with namespace-scoped Role/RoleBindings limited to the verbs and resources the dashboard actually needs, and remove wildcard or cluster-admin-equivalent grants. Rotate the SA token proactively if there is any chance it was exposed (CI logs, misconfigured secrets, prior incidents). For detection, enable Kubernetes audit logging on the odh-dashboard SA identity and alert on: API calls outside its expected namespace, reads of `secrets`/`configmaps` in namespaces it doesn't own, and creation/modification of ClusterRoleBindings or RoleBindings attributed to that SA.

What systems are affected by CVE-2026-18949?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, model registry, ml_ops platforms, multi-tenant cluster infrastructure.

What is the CVSS score for CVE-2026-18949?

CVE-2026-18949 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.60%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesmodel registryml_ops platformsmulti-tenant cluster infrastructure

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.4

NIST AI RMF: MANAGE-2.3

What are the technical details?

Original Advisory

A flaw was found in odh-dashboard. This vulnerability allows an attacker, who has compromised the dashboard's Service Account (SA) token, to exploit overly broad permissions granted to the SA. This enables the attacker to escalate their privileges to cluster-administrator level, gain access to sensitive data like credentials and keys across the entire cluster, and disrupt multi-tenant isolation.

Exploitation Scenario

An attacker first gains a foothold via an unrelated vector — a leaked CI/CD secret, an exposed dashboard log, a compromised developer laptop, or an SSRF/RCE in another cluster component — and extracts the odh-dashboard Service Account token. Using that token, they query the Kubernetes API directly (bypassing the dashboard UI) and discover the SA holds permissions well beyond what the dashboard needs, such as broad `get`/`list`/`create` rights on cluster-scoped resources. They use those permissions to create a new ClusterRoleBinding granting themselves cluster-admin, then enumerate `secrets` across every namespace on the cluster — harvesting database credentials, cloud IAM keys, and other tenants' model registry and MLflow tokens — and use that access to move laterally into other teams' training pipelines and model-serving workloads, fully collapsing the platform's multi-tenant boundary.

Weaknesses (CWE)

CWE-250 Execution with Unnecessary Privileges

CWE-250 — Execution with Unnecessary Privileges: The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.

[Architecture and Design, Operation] Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
[Architecture and Design] Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Source: MITRE CWE corpus.