CVE-2026-18950: MLflow unvalidated roleRef enables

CISO Take

A flaw in Red Hat OpenShift AI's odh-dashboard fails to validate the roleRef field when creating RoleBindings, letting any authenticated low-privileged user bind their own account to cluster-admin or another high-privilege ClusterRole. This matters for AI platform teams because RHOAI/odh-dashboard sits in front of 683 downstream dependents and the mod-arch components (model registry, MLflow, gen-ai, AutoML, MaaS, eval-hub, autorag) — a single data-scientist-level tenant account can break namespace isolation and take over the entire OpenShift cluster, not just their own project. Severity is CVSS 8.8, but EPSS sits at only 0.36% (top 71st percentile), there is no CISA KEV listing, no public exploit code, and no Nuclei template — CISA's own SSVC call is TRACK, so this is not under known active exploitation today. Red Hat has shipped fixes via RHSA-2026:53263, RHSA-2026:53261, and RHSA-2026:53262; patch promptly given how trivial the exploit mechanics are (a single crafted RoleBinding), and in the interim audit existing RoleBindings cluster-wide for any roleRef pointing to cluster-admin or other privileged ClusterRoles outside expected service accounts.

Sources: NVD EPSS access.redhat.com OpenSSF ATLAS

What is the risk?

High severity (CVSS 8.8) privilege escalation requiring only low privileges and no user interaction, over the network, with high impact to confidentiality, integrity and availability once exploited. Current real-world exploitation likelihood is low: EPSS 0.36% (top 71st percentile), not in CISA KEV, no public exploit or scanner template found, and CISA SSVC rates it TRACK (not TRACK*/ATTEND). The gap between severity and observed exploitation activity is the key risk signal — this is a 'quietly critical' bug in infrastructure that is easy to weaponize (no special AI/ML knowledge needed, just Kubernetes RBAC) but hasn't yet attracted attacker attention. That can change quickly once a PoC circulates, especially given RHOAI's growing footprint (683 dependents, active upstream development — last push 2026-08-16) and its history of prior CVEs (75 in the same package family, OpenSSF Scorecard only 5.6/10).

How does the attack unfold?

Initial Access

Attacker authenticates to odh-dashboard as a legitimate but low-privileged tenant user, or uses stolen credentials for such an account.

AML.T0012

Exploitation

Attacker submits a RoleBinding creation request with roleRef set to cluster-admin (or another privileged ClusterRole); the dashboard backend fails to validate the field and creates the binding.

Persistence

The attacker's account (or an additional service account they create) now holds a durable cluster-admin binding that survives normal namespace-scoped access reviews.

Impact

With cluster-wide privileges, the attacker reads secrets and AI/ML artifacts across all tenant namespaces, tampers with model registries and MLflow pipelines, and can disrupt or exfiltrate data platform-wide.

AML.T0007

Initial Access

Attacker authenticates to odh-dashboard as a legitimate but low-privileged tenant user, or uses stolen credentials for such an account.

AML.T0012

Exploitation

Attacker submits a RoleBinding creation request with roleRef set to cluster-admin (or another privileged ClusterRole); the dashboard backend fails to validate the field and creates the binding.

Persistence

The attacker's account (or an additional service account they create) now holds a durable cluster-admin binding that survives normal namespace-scoped access reviews.

Impact

With cluster-wide privileges, the attacker reads secrets and AI/ML artifacts across all tenant namespaces, tampers with model registries and MLflow pipelines, and can disrupt or exfiltrate data platform-wide.

AML.T0007

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.5%

chance of exploitation in 30 days

Higher than 42% 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

1) Patch immediately by applying RHSA-2026:53263, RHSA-2026:53261, and RHSA-2026:53262 to all affected odh-dashboard and odh-mod-arch-* images. 2) Audit existing state now: run kubectl get rolebindings,clusterrolebindings --all-namespaces -o json and flag any binding whose roleRef references cluster-admin or another highly privileged ClusterRole that wasn't provisioned through your standard IaC/GitOps process. 3) Revoke and rotate credentials for any subject found bound to an unexpected privileged role. 4) Add admission control (OPA/Gatekeeper or Kyverno policy) to deny RoleBinding/ClusterRoleBinding creation referencing privileged ClusterRoles from non-admin service accounts, as defense-in-depth beyond the vendor fix. 5) Enable/monitor Kubernetes audit logs for rolebindings.create and rolebindings.update events tied to the dashboard's service account, and alert on any roleRef change post-patch.

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 Code Execution Framework AML.T0007 - Discover AI Artifacts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.9 - Data and infrastructure resource controls

NIST AI RMF

GOVERN 4.1 / MANAGE 4.1 - Access control and risk response for AI system infrastructure

Frequently Asked Questions

What is CVE-2026-18950?

A flaw in Red Hat OpenShift AI's odh-dashboard fails to validate the roleRef field when creating RoleBindings, letting any authenticated low-privileged user bind their own account to cluster-admin or another high-privilege ClusterRole. This matters for AI platform teams because RHOAI/odh-dashboard sits in front of 683 downstream dependents and the mod-arch components (model registry, MLflow, gen-ai, AutoML, MaaS, eval-hub, autorag) — a single data-scientist-level tenant account can break namespace isolation and take over the entire OpenShift cluster, not just their own project. Severity is CVSS 8.8, but EPSS sits at only 0.36% (top 71st percentile), there is no CISA KEV listing, no public exploit code, and no Nuclei template — CISA's own SSVC call is TRACK, so this is not under known active exploitation today. Red Hat has shipped fixes via RHSA-2026:53263, RHSA-2026:53261, and RHSA-2026:53262; patch promptly given how trivial the exploit mechanics are (a single crafted RoleBinding), and in the interim audit existing RoleBindings cluster-wide for any roleRef pointing to cluster-admin or other privileged ClusterRoles outside expected service accounts.

Is CVE-2026-18950 actively exploited?

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

How to fix CVE-2026-18950?

1) Patch immediately by applying RHSA-2026:53263, RHSA-2026:53261, and RHSA-2026:53262 to all affected odh-dashboard and odh-mod-arch-* images. 2) Audit existing state now: run `kubectl get rolebindings,clusterrolebindings --all-namespaces -o json` and flag any binding whose roleRef references cluster-admin or another highly privileged ClusterRole that wasn't provisioned through your standard IaC/GitOps process. 3) Revoke and rotate credentials for any subject found bound to an unexpected privileged role. 4) Add admission control (OPA/Gatekeeper or Kyverno policy) to deny RoleBinding/ClusterRoleBinding creation referencing privileged ClusterRoles from non-admin service accounts, as defense-in-depth beyond the vendor fix. 5) Enable/monitor Kubernetes audit logs for `rolebindings.create` and `rolebindings.update` events tied to the dashboard's service account, and alert on any roleRef change post-patch.

What systems are affected by CVE-2026-18950?

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

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

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

What is the AI security impact?

Affected AI Architectures

ml_ops platformsmodel registrymulti-tenant ML platformsmodel serving

MITRE ATLAS Techniques

AML.T0007 Discover AI Artifacts

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.9

NIST AI RMF: GOVERN 4.1 / MANAGE 4.1

What are the technical details?

Original Advisory

A flaw was found in odh-dashboard. An authenticated user of the dashboard can exploit a vulnerability related to how RoleBindings are created. The system does not properly validate the `roleRef` field, allowing a user to specify an arbitrary role, including highly privileged ones like `cluster-admin`. This can lead to privilege escalation, where an attacker gains unauthorized elevated access within their namespace and potentially persistent control over the system.

Exploitation Scenario

A data scientist with a normal, low-privilege RHOAI account (e.g. granted access to a single project namespace) authenticates to the odh-dashboard as intended. Instead of using the UI's guided workflows, they call the underlying RoleBinding-creation API directly (or intercept/modify the request the dashboard sends) and set roleRef to the cluster-admin ClusterRole while binding it to their own user or a service account they control. Because the backend does not validate that the requested roleRef is within the set of roles the dashboard is supposed to offer, the RoleBinding is created as requested. The user (or an external attacker who has compromised that account's credentials via phishing or credential stuffing) now has cluster-admin rights, letting them read every namespace's secrets and model artifacts, deploy arbitrary workloads, and plant additional RoleBindings or service accounts as a persistence mechanism that survives password rotation on the original account.

Weaknesses (CWE)

CWE-266 Incorrect Privilege Assignment

CWE-266 — Incorrect Privilege Assignment: A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[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.

Source: MITRE CWE corpus.