Security research

The Red Hat OpenShift AI credential read that skipped the admin check

Dmitry Maranik·September 7, 2026

A route in the Open Data Hub dashboard — the same dashboard that ships in Red Hat OpenShift AI — returned the cluster's NVIDIA NIM credential to any authenticated user, admin or not. The endpoints that create and delete that credential were correctly restricted to admins. The endpoint that read it back was not. Red Hat Product Security assigned it CVE-2026-86332 (Moderate) and published it on 2026-09-07.

This one is not a cross-tenant leak, and we want to be precise about that up front: it is a privilege-boundary flaw — a low-privilege user reaching a credential that was meant for admins. But it turned up the same way our cross-tenant findings do, by comparing where a boundary is enforced against the neighbouring place it is not. So it is worth a short walk-through.

What broke

The dashboard has a backend-for-frontend layer: small server routes that read Kubernetes resources on the browser's behalf. One of them, GET /api/nim-serving/{nimResource}, resolves the NVIDIA NIM account's Secret — the NGC API key and the image pull secret — and hands it back.

Two details combine into the bug. First, the route has no authorization guard: it is a bare handler, and the caller only has to be logged in. Second, it reads the Secret using the dashboard's own service account, not the user's credentials, so Kubernetes RBAC never gets a say — the dashboard is privileged, and it reads on the user's behalf without checking whether the user should be allowed. It then returns the whole Secret object, including the base64-encoded .data.

the read had no guard; the write did

// the READ: no admin guard, reads with the dashboard service account fastify.get("/:nimResource", async (req) => {no secureAdminRoute const secret = await coreV1Api.readNamespacedSecret(name, ns) return { body: secret.body } // the whole Secret, incl. .data }) // the WRITE siblings for the SAME credential: admin only fastify.post("/", secureAdminRoute(fastify)(create)) fastify.delete("/:name", secureAdminRoute(fastify)(remove))

Any authenticated dashboard user could GET the NGC / NIM Secret in full, though only an admin could create or delete it. The read sibling never received the guard its write siblings have.

Why it matters, and why it is Moderate

What leaks is a real credential: the cluster's NVIDIA NGC API key and the image pull secret, in cleartext. These are shared infrastructure secrets, not per-user, so handing them to a lower-privileged account is a genuine privilege-boundary break. It keeps to Moderate because it is not a cross-tenant data leak, it is not remote code execution, and the attacker must already be an authenticated dashboard user. The blast radius is whatever that NGC key unlocks — pulling NIM containers, and the account access that key carries.

The pattern: the write was guarded, the read sibling wasn't

We keep writing about the un-retrofitted sibling: a boundary that is enforced on the write, the delete, and the list, and skipped on one read that sits right beside them. Usually the boundary is a tenant. Here it is a privilege level, but the shape is identical. The people who built this route knew the NIM credential was sensitive — that is exactly why create and delete are admin-only. The read is the sibling that got reused without the guard. When we review a codebase we diff the permission check across all of a resource's handlers for precisely this reason.

The fix, and the mitigation

The fix is one guard, matching the write siblings: require an admin on the read, or stop returning the raw Secret and return only the non-sensitive fields the UI needs. Until a patched dashboard image is available, Red Hat's guidance is to disable or remove the NVIDIA NIM integration so the Secret is not present to read.

Check your own service-account reads

If you build a dashboard or a backend-for-frontend that reads privileged resources on a user's behalf, the question this bug asks is: when a route reads with the server's identity instead of the caller's, what re-checks that the caller was allowed? Those routes bypass the platform's own access control by design, so each one needs its own guard — and the risky ones are the reads sitting next to a write you already remembered to lock down.

We built Sectum AI to check isolation at runtime: it stands up synthetic tenants, plants canary data, and verifies what a running stack actually returns across its surfaces — with a signed evidence pack you can verify yourself. It is open source; point it at your own stack.

Explore the open source More disclosures

Advisory: CVE-2026-86332 (published 2026-09-07, Moderate, CWE-862 / CWE-522), in the Open Data Hub dashboard shipped with Red Hat OpenShift AI. Credited reporter: Dmitry Maranik (Sectum AI). Source-confirmed at the time of reporting; not lab-reproduced.