CVE-2026-86332: MLflow broken authz leaks NIM/NGC

CISO Take

A backend-for-frontend endpoint in Red Hat OpenShift AI's dashboard (GET /api/nim-serving/:nimResource) uses its own elevated service account to fetch Kubernetes Secrets and returns the full secret payload to any authenticated caller, without checking whether that user is authorized to see it — so any logged-in dashboard user, not just admins, can pull the cluster's NVIDIA NGC API key and the NIM image pull secret. The blast radius is organizational rather than internet-wide: exploitation requires only a low-privilege account (PR:L) and no user interaction, and once exploited it hands an attacker credentials that can be reused against NVIDIA's commercial API and the private container registry backing your model-serving pipeline. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this reads as opportunistic-insider risk rather than an active internet campaign — but the CVSS 6.5 confidentiality-only score understates the practical cost if the NGC key gets reused for quota abuse or the pull secret is used to pull proprietary NIM images. Track the Red Hat bug (bugzilla 2529287) for a patched odh-dashboard/odh-core-bff build; until then, restrict who has any dashboard login and rotate both the NGC API key and the NIM pull secret if the environment has multiple non-admin tenants. Add detection for GET requests to /api/nim-serving/:nimResource from non-admin accounts in dashboard/BFF access logs.

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

What is the risk?

Medium severity (CVSS 6.5, confidentiality-high / integrity-none / availability-none). Attack complexity is low and no user interaction is required, but exploitation requires an authenticated account (PR:L) — this is not an unauthenticated internet-facing flaw, it's a broken authorization boundary inside a platform that any onboarded dashboard user (even non-admin) can walk through with a single API call. There is no known public exploit code, no Nuclei template, no CISA KEV listing, and EPSS data is unavailable, so there is no evidence of active or automated exploitation. The underlying package (rhoai/odh-dashboard family) shows meaningful pre-existing exposure — 81 other CVEs and an OpenSSF Scorecard of only 5.5/10 — which raises confidence this is a component with a track record of security gaps rather than a one-off. Practical risk is highest in multi-tenant OpenShift AI clusters where non-admin users (data scientists, MLOps engineers) share the platform with less-trusted parties.

How does the attack unfold?

Initial Access

Attacker obtains any valid, low-privilege authenticated account on the OpenShift AI dashboard through normal onboarding, without needing admin rights.

AML.T0012

Exploitation

Attacker sends a GET request to /api/nim-serving/:nimResource; the BFF uses its own privileged service account to read the Secret without verifying the caller's authorization.

AML.T0049

Credential Access

The full Kubernetes Secret object, including the NVIDIA NGC API key and NIM image pull secret, is returned in the HTTP response body.

AML.T0055

Impact

Attacker exfiltrates and reuses the leaked credentials to consume NVIDIA NGC services under the victim's account or pull private NIM container images, causing cost harvesting or IP exposure.

AML.T0025

Initial Access

Attacker obtains any valid, low-privilege authenticated account on the OpenShift AI dashboard through normal onboarding, without needing admin rights.

AML.T0012

Exploitation

Attacker sends a GET request to /api/nim-serving/:nimResource; the BFF uses its own privileged service account to read the Secret without verifying the caller's authorization.

AML.T0049

Credential Access

The full Kubernetes Secret object, including the NVIDIA NGC API key and NIM image pull secret, is returned in the HTTP response body.

AML.T0055

Impact

Attacker exfiltrates and reuses the leaked credentials to consume NVIDIA NGC services under the victim's account or pull private NIM container images, causing cost harvesting or IP exposure.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	—	No patch
27.9K OpenSSF 5.4 694 dependents Pushed 6d ago 36% patched ~73d to patch Full package profile →
rhoai/odh-core-bff-rhel9	—	—	No patch
rhoai/odh-dashboard-operator-rhel9	—	—	No patch
rhoai/odh-dashboard-rhel8	—	—	No patch
rhoai/odh-dashboard-rhel9	—	—	No patch
rhoai/odh-mod-arch-agent-ops-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

6.5 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 12% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I None

A None

What should I do?

1 step

1) Track Red Hat's fix for bugzilla 2529287 / CVE-2026-86332 and apply the patched odh-dashboard, odh-dashboard-operator, and odh-core-bff builds as soon as they're released (no fixed version is published yet at disclosure time). 2) Interim compensating control: restrict who can authenticate to the OpenShift AI dashboard to trusted users only, since read access to the vulnerable route requires nothing beyond a valid low-privilege dashboard login. 3) Rotate the NVIDIA NGC API key (apiKeySecret) and the NIM image pull secret (nimPullSecret) if any non-admin or lower-trust users had dashboard access before patching, since the Secret data itself must be treated as already exposed. 4) Add Kubernetes-level defense in depth: consider a NetworkPolicy or admission control restricting which service accounts can read the specific Secret objects, independent of the dashboard's own authorization logic. 5) Monitor dashboard/BFF access logs and Kubernetes audit logs for GET requests to /api/nim-serving/:nimResource from accounts without cluster-admin or NIM-admin role, and for anomalous NGC API usage patterns after the fact.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass Data Leakage Inference API AML.T0025 - Exfiltration via Cyber Means 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 - AI system life cycle and information security integration

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-86332?

A backend-for-frontend endpoint in Red Hat OpenShift AI's dashboard (GET /api/nim-serving/:nimResource) uses its own elevated service account to fetch Kubernetes Secrets and returns the full secret payload to any authenticated caller, without checking whether that user is authorized to see it — so any logged-in dashboard user, not just admins, can pull the cluster's NVIDIA NGC API key and the NIM image pull secret. The blast radius is organizational rather than internet-wide: exploitation requires only a low-privilege account (PR:L) and no user interaction, and once exploited it hands an attacker credentials that can be reused against NVIDIA's commercial API and the private container registry backing your model-serving pipeline. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this reads as opportunistic-insider risk rather than an active internet campaign — but the CVSS 6.5 confidentiality-only score understates the practical cost if the NGC key gets reused for quota abuse or the pull secret is used to pull proprietary NIM images. Track the Red Hat bug (bugzilla 2529287) for a patched odh-dashboard/odh-core-bff build; until then, restrict who has any dashboard login and rotate both the NGC API key and the NIM pull secret if the environment has multiple non-admin tenants. Add detection for GET requests to /api/nim-serving/:nimResource from non-admin accounts in dashboard/BFF access logs.

Is CVE-2026-86332 actively exploited?

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

How to fix CVE-2026-86332?

1) Track Red Hat's fix for bugzilla 2529287 / CVE-2026-86332 and apply the patched odh-dashboard, odh-dashboard-operator, and odh-core-bff builds as soon as they're released (no fixed version is published yet at disclosure time). 2) Interim compensating control: restrict who can authenticate to the OpenShift AI dashboard to trusted users only, since read access to the vulnerable route requires nothing beyond a valid low-privilege dashboard login. 3) Rotate the NVIDIA NGC API key (apiKeySecret) and the NIM image pull secret (nimPullSecret) if any non-admin or lower-trust users had dashboard access before patching, since the Secret data itself must be treated as already exposed. 4) Add Kubernetes-level defense in depth: consider a NetworkPolicy or admission control restricting which service accounts can read the specific Secret objects, independent of the dashboard's own authorization logic. 5) Monitor dashboard/BFF access logs and Kubernetes audit logs for GET requests to /api/nim-serving/:nimResource from accounts without cluster-admin or NIM-admin role, and for anomalous NGC API usage patterns after the fact.

What systems are affected by CVE-2026-86332?

This vulnerability affects the following AI/ML architecture patterns: model serving, ml_ops platforms, container image supply chain.

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

CVE-2026-86332 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.21%.

What is the AI security impact?

Affected AI Architectures

model servingml_ops platformscontainer image supply chain

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

A flaw was found in odh-dashboard in Red Hat OpenShift AI. The backend-for-frontend route GET /api/nim-serving/:nimResource reads Kubernetes Secrets using the dashboard service account and returns the full Secret object, including .data, without an authorization check. Any authenticated dashboard user can retrieve the cluster NVIDIA NGC API key Secret (apiKeySecret) and the NIM image pull secret (nimPullSecret). Create and delete of the same NIM credential are admin-gated; the read path is not. This is missing authorization (CWE-862) and insufficiently protected credentials (CWE-522). It is distinct from CVE-2026-5483 (service-account token leak in the Kubernetes client response wrapper on the same route) and CVE-2026-16456 (odh-model-controller cross-namespace confused deputy).

Exploitation Scenario

A data scientist or other low-privilege user with a legitimate, non-admin OpenShift AI dashboard account (obtained through normal onboarding, not through any exploit) sends a routine authenticated GET request to /api/nim-serving/:nimResource. The backend-for-frontend service, instead of checking whether the calling user is authorized to view NIM credentials, uses its own privileged Kubernetes service account to fetch the corresponding Secret object and returns the full .data payload — including the base64-encoded NVIDIA NGC API key and the NIM image pull secret — directly in the HTTP response. The user decodes the response, extracts both credentials, and either uses the NGC API key to consume NVIDIA's hosted model/API catalog at the organization's expense and quota, or uses the pull secret to pull the organization's private NIM model-serving container images outside the cluster, exposing proprietary model artifacts or configuration.

Weaknesses (CWE)

CWE-862 Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.