Red Hat OpenShift AI (CVE-2026-14450): Twenty CVEs and Three Ways a Namespace Tenant Becomes Cluster Admin

On August 10, 2026, Red Hat disclosed a wave of vulnerabilities across the Red Hat OpenShift AI (RHOAI) stack at once — the flagship 3.4.3 update alone bundles twenty CVEs spanning the Models-as-a-Service gateway, the training operator, the Data Science Pipelines operator, Feast, TrustyAI, and the dashboard. Read individually they look like a scattered batch of medium-to-critical bugs. Read together they describe one architecture problem: an AI platform bolts privileged operators onto Kubernetes, and each operator becomes a confused deputy — it accepts tenant-controlled identity, workload specifications, connection strings, or source code, and acts on them with far more authority than the tenant has. The recurring result is that a low-privileged namespace tenant, or any pod already running in the cluster, escalates to cluster-admin-equivalent access. What follows reproduces the mechanism behind the three clearest instances in a local lab, then sets out a vendor-agnostic audit procedure for a cluster under one's own administration.

The Pattern: The AI Control Plane Is a Confused Deputy

A multi-tenant AI platform on Kubernetes gives each team a namespace and a set of custom resources — a training job, a pipeline, a feature view, a model endpoint. Behind each custom resource is an operator: a controller running with a powerful ServiceAccount that reconciles the tenant's request into real cluster objects (pods, tokens, role bindings). The operator is the deputy. It is powerful so it can do its job. The vulnerability class is what happens when the deputy takes a tenant-controlled input and acts on it without preserving the tenant's authority boundary. The RHOAI disclosure is the same mistake made in three different places:

• • Unverified identity propagation — the deputy trusts an identity assertion it should have re-verified (CVE-2026-14450, CVE-2026-13717).
• • Ambient authorization — the deputy's permissions get aggregated onto a role every tenant already holds (CVE-2026-18951, CVE-2026-18982).
• • Interpreting tenant input — the deputy feeds a tenant-supplied string, spec, or repository into an interpreter or a privileged pod (CVE-2026-18948, CVE-2026-18617, CVE-2026-18942).

Everything below is reproduced locally. Where a flaw is specific to Red Hat's packaging, the lab demonstrates the mechanism and the detection technique — it is not a claim that the toy manifest is Red Hat's code. Cite the advisories, linked throughout, for the specific-product mapping.

Failure Mode 1 — Trusted Identity Headers (CVE-2026-14450)

Red Hat's Models-as-a-Service API sits behind a Kuadrant AuthPolicy gateway. The gateway authenticates a request and forwards the caller's identity to the backend in two HTTP headers, X-MaaS-Username and X-MaaS-Group. The backend trusts those headers as an authenticated assertion of who the caller is. That is safe only if the gateway is provably the only path to the backend. It is not: any pod in the cluster can reach the backend Service directly and set the headers to anything. Red Hat's description is that a forged request lets an attacker mint Kubernetes ServiceAccount tokens in other tenants' namespaces, revoke API keys, and read cross-tenant model configuration. CWE-290, authentication bypass by spoofing.

The mechanism reproduces in a few lines: a gateway that authenticates a token and overwrites the identity headers, and a backend that trusts them. Through the gateway, forged headers are stripped and replaced — the gateway is correct. Reaching the backend directly, they are not:

# Legit path — gateway authenticates, overwrites identity, forwards:
$ curl -s -H 'Authorization: Bearer tenant-a-token' \
       -H 'X-MaaS-Username: tenant-b' -H 'X-MaaS-Group: admins' gateway
  user   = tenant-a          # forged headers ignored
  groups = users
  ACTION = mint-serviceaccount-token denied (not admin)

# Attack — co-resident pod reaches the backend Service directly:
$ curl -s -H 'X-MaaS-Username: tenant-b' -H 'X-MaaS-Group: admins' backend
  user   = tenant-b          # trusted verbatim
  groups = admins
  ACTION = mint-serviceaccount-token GRANTED (admin)

Local reproduction of the CVE-2026-14450 class. The gateway does its job; the backend's trust in the headers is only as strong as the network guarantee that nobody else can reach it.

The paired flaw CVE-2026-13717 (8.8) is a gateway misconfiguration in the same MaaS component, affecting the same trust boundary. The principle is not specific to Red Hat: any service that reads identity from a header trusts whatever can write that header.

Failure Mode 2 — RBAC Aggregation (CVE-2026-18951, CVE-2026-18982)

Kubernetes lets you extend the built-in edit and admin ClusterRoles by labelling a new ClusterRole with rbac.authorization.k8s.io/aggregate-to-edit: "true". The aggregation controller then folds its rules into edit cluster-wide. It is an intentional extensibility mechanism — and a footgun. RHOAI's training-operator overlay aggregated trainjobs management onto edit, so every namespace editor silently gained the ability to create training jobs — and because the training job compiles into a pod with a tenant-chosen ServiceAccount and pod spec, that is a path to impersonation and host access. This is specific to Red Hat's overlay, not upstream Kubeflow.

On a throwaway cluster: a ServiceAccount bound only to the built-in edit role, before and after the operator installs its aggregated ClusterRole. Nothing about the tenant's own RoleBinding changes between the two checks:

$ kubectl auth can-i create trainjobs \
    --as=system:serviceaccount:tenant-a:tenant-editor -n tenant-a
no

# operator installs a ClusterRole labelled aggregate-to-edit: "true"
$ kubectl apply -f aggregate-to-edit.yaml

$ kubectl auth can-i create trainjobs \
    --as=system:serviceaccount:tenant-a:tenant-editor -n tenant-a
yes

The CVE-2026-18951 / -18982 mechanism. The privilege arrives through the built-in edit role, so no tenant's RoleBinding looks suspicious — the grant is invisible unless you expand the aggregated role.

The reason this is dangerous is subtle: the tenant's RoleBinding is unchanged and unremarkable. The new authority is grafted onto a role thousands of subjects already hold, so an auditor reviewing RoleBindings sees nothing. You have to expand what edit actually resolves to.

Failure Mode 3 — Operators That Run Tenant Input (CVE-2026-18948, CVE-2026-18617, CVE-2026-18942)

The third mode is the most direct: a privileged controller takes a tenant-supplied value and feeds it to an interpreter. The clearest example is Feast, the feature store bundled with RHOAI. An OnDemandFeatureView carries a user-defined function, serialized with Python's dill. The registry server deserializes it with dill.loads() — and deserializing an attacker-controlled pickle executes code. Red Hat (CVE-2026-18948, 9.9) states an unauthenticated attacker can achieve RCE on the feature-server pod in default configurations, with the registry-server path reachable through an authorization bypass. The same underlying flaw is tracked upstream as CVE-2026-56121 (Feast before 0.63.0).

Reproduced against the affected Feast release, the deserialization call runs a benign self-authored marker payload (it prints the process UID and writes a file — no weaponization). Critically, in the registry server's ApplyFeatureView handler the deserialize step runs before the permission check:

# registry_server.py, ApplyFeatureView:
#   OnDemandFeatureView.from_proto(...)   -> dill.loads(udf.body)   [line 348]
#   assert_permissions_to_update(...)                               [line 354]
# deserialization happens FIRST.

$ python repro.py
[*] feast version : 0.62.0   (affected: before 0.63.0)
[*] sink          : PythonTransformation.from_proto() -> dill.loads(body)
[!] ARBITRARY CODE EXECUTED before any auth check. Proof:
    uid=501 gid=20(staff) groups=20(staff),12(everyone),...

The Feast dill.loads() sink (CVE-2026-18948 / CVE-2026-56121) executing on the affected release. The 0.63.0 fix threads a skip_udf flag so the registry no longer deserializes incoming UDF bodies.

Two more flaws in the same disclosure are the same shape. CVE-2026-18617 (8.8): the Data Science Pipelines operator concatenates a tenant-controlled customExtraParams field into a MySQL connection string, letting a namespace editor enable LOCAL INFILE and exfiltrate the operator pod's ServiceAccount token. CVE-2026-18942 is the instructive one for scoring: the Feast operator runs a tenant-controlled feature repository with an elevated ServiceAccount, which Red Hat says can yield cluster-admin-equivalent access — yet it scores only 5.5, because CVSS measures the immediate technical impact, not the attack chain it unlocks. Do not triage this disclosure by base score alone.

Investigation Workflow

This disclosure splits cleanly into two jobs: find the OpenShift AI you are exposing on the network, then audit tenant-to-controller authority inside a cluster you control. The first is remote reconnaissance; the second is in-cluster and uses kubectl, not a network scanner. Both are worth running.

Part A — Find Exposed OpenShift & OpenShift AI (remote)

OpenShift exposes recognizable network surfaces. These are documented defaults, not fingerprints to guess at — combine them, and treat everything here as authorized-target-only:

• • 6443 — the OpenShift/Kubernetes API server. A reachable, internet-facing API server is itself a finding.
• • Port scan / HTTP: the web console and OAuth server ship as Routes under the cluster wildcard domain — console-openshift-console.apps.<cluster-name>.<base-domain> and oauth-openshift.apps.<cluster-name>.<base-domain>. The OpenShift AI dashboard is a Route in the applications domain (commonly an rhods-dashboard / odh-dashboard hostname); the exact string is deployment-specific, so confirm against your own Route list rather than assuming it.
• • TLS inspect: OpenShift Routes commonly present a wildcard certificate for *.apps.<cluster-domain>. Pull the cert and the SANs enumerate the cluster's exposed applications, including any dashboard published outside change control.
• • DNS: query for api.*, console.*, apps.*, and AI-tooling names like rhods.* / ai.*; certificate-transparency logs surface the same wildcard domains passively.
• • CVE lookup: track the RHOAI CVEs in RHSA-2026:53262 and your installed RHOAI version against the 2.25.10 / 3.4.3 / 3.3.6 fix line.

Discovery proves exposure and version, not exploitability: none of these flaws is reachable from an unauthenticated internet position — they need a foothold inside the cluster. Remote reconnaissance shows where the clusters are and whether their control-plane surfaces are needlessly public; it cannot show whether an edit role has been over-aggregated. That requires in-cluster inspection.

Part B — Audit Tenant-to-Controller Authority (kubectl)

Run this against a cluster you administer. Every finding takes the form starting principal → writable input → privileged controller → resulting authority:

• • Expand the aggregated roles. kubectl get clusterrole -l rbac.authorization.k8s.io/aggregate-to-edit=true -o yaml and the same for aggregate-to-admin. For every custom resource that got folded in, ask: can an ordinary editor create it, and does its controller then build pods, tokens, or role bindings?
• • Test as the tenant. kubectl auth can-i create <cr> --as=system:serviceaccount:<ns>:<sa> -n <ns>. The important question is not "can the editor create a TrainJob" but "is creating a TrainJob equivalent to creating a more privileged pod."
• • Check CRD-to-pod passthrough. kubectl get crd <name> -o yaml and grep for serviceAccountName, hostPath, securityContext, volumes, command, extraParams — fields where a "safe" custom resource smuggles a privileged pod spec.
• • Measure controller blast radius. For each operator's ServiceAccount, kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> against get secrets, create pods/exec, create serviceaccounts/token, and cluster RBAC writes. An operator that can mint tokens or write ClusterRoleBindings is a single compromise away from cluster-admin.
• • Test identity provenance. For each gateway-fronted backend, confirm client-supplied identity headers are stripped and overwritten, and that the backend is unreachable by ordinary tenant pods — not merely that the gateway is well-behaved.

Cross-Reference with External Data

Remediation

1. Upgrade RHOAI to 2.25.10, 3.4.3, or 3.3.6. One update line closes the whole batch (RHSA-2026:53261 / 53262 / 53263). This is the whole fix; everything below is defense-in-depth and detection.
2. For Feast specifically, confirm 0.63.0+ and lock down the registry. Red Hat's mitigation is to enforce auth.type: kubernetes in the operator-generated configuration and deny registry writes by default. Do not expose the Feast registry or feature server beyond the workloads that need it.
3. Expand your aggregated roles and diff them. kubectl get clusterrole edit admin -o yaml — any custom-resource verbs you did not deliberately grant to every editor are a finding. This is the check that would have surfaced CVE-2026-18951 before the advisory did.
4. Verify identity provenance on gateway-fronted services. Backends must re-verify identity (a signed token or mutually-authenticated channel), not trust bare headers, and network policy must stop tenant pods from reaching backends directly. A gateway is not a security boundary if the backend is reachable around it.
5. Constrain operator ServiceAccounts. Audit each controller's real permissions with kubectl auth can-i --as. An operator that can exec into arbitrary pods, mint tokens, or write cluster RBAC is over-privileged; scope it down.
6. Triage by attack chain, not base score. CVE-2026-18942 is a 5.5 that Red Hat says reaches cluster-admin-equivalent access. In a multi-tenant AI platform, "a namespace editor can run code as a privileged controller" is the finding that matters, whatever the number next to it.

Sources

• → Red Hat: CVE-2026-14450 (MaaS API trusted-header auth bypass)
• → Red Hat: CVE-2026-18948 (Feast dill deserialization RCE)
• → NVD: CVE-2026-56121 (upstream Feast, before 0.63.0)
• → Red Hat: CVE-2026-18951 (training-operator aggregate-to-edit)
• → Red Hat: CVE-2026-18982 (training-operator edit/admin aggregation + pod passthrough)
• → Red Hat: CVE-2026-18617 (DSPO MySQL DSN LOCAL INFILE)
• → Red Hat: CVE-2026-18942 (Feast operator runs tenant repository)
• → Red Hat: CVE-2026-13717 (MaaS Gateway misconfiguration)
• → Red Hat: RHSA-2026:53262 (RHOAI 3.4.3 fix)
• → Feast fix commit (skip_udf on the registry deserialization path)
• → Kubernetes: RBAC aggregated ClusterRoles (aggregate-to-edit)