Red Hat OpenShift AI: in-cluster pods can impersonate any user (CVE-2026-16745)

A flaw in the admin console of Red Hat's machine-learning platform "Red Hat OpenShift AI" lets an attacker who has already gained a foothold inside the cluster impersonate other people, including administrators. It is tracked as CVE-2026-16745 and rated "CVSS 8.8 (High)."

This is not something anyone can trigger from the open internet in a single shot. Exploiting it assumes the attacker already has a foothold inside your systems. The flip side is useful: check that assumption against your own setup and you can tell clearly whether you are affected. This article walks through what happens, who is affected, and what to do if you are.

What is Red Hat OpenShift AI, and why does this matter

Red Hat OpenShift AI (often shortened to RHOAI) is software that gives organizations a foundation for building artificial intelligence (AI) and machine-learning models and running them in production. It bundles data preparation, model training, and deployment into a single console, and it is being adopted across finance, manufacturing, and research institutions that hold large amounts of data in-house.

The platform runs on top of "Kubernetes," a system that manages many small runtime environments called containers as one herd (a cluster). OpenShift is Red Hat's enterprise-grade take on Kubernetes. The component at issue here is OpenShift AI's operations screen, an admin console called "odh-dashboard."

The raw number of organizations running it is smaller than that of consumer services. But on the ground, it is common for several teams or business partners to share the same platform. That shared, multi-tenant setup is exactly where this flaw quietly bites.

What happens — slipping past the identity check to impersonate others

When this flaw is exploited, the attacker can tell the admin console "I am a different user" and impersonate that person. According to NVD's description, an attacker can impersonate "any user within the cluster," including administrators, simply by supplying an arbitrary access token.

Once impersonation succeeds, the attacker reaches the "Kubernetes API," the control gateway for the whole cluster. With that in hand, they can run arbitrary programs, escalate privileges further, and read stored data. The severity assessment marks confidentiality, integrity, and availability all as "High," which shows just how broad the damage can be once the cluster is taken over.

The key point is that this is not a single strike over the internet. The attacker first needs some foothold inside the cluster. In an environment where several teams share the platform, though, that foothold is far from a high bar. A single container that is only supposed to hold low privileges can use this flaw as a stepping stone and suddenly become the master of the entire cluster.

Who the attacker targets, and what they do

The people who can put this flaw to use are attackers who already hold at least one foothold inside the target cluster. Think of a low-privilege container taken over through some other weakness, a machine-learning job of dubious origin imported from outside, or a malicious user from another team in a shared environment — anyone in a position to run something inside the cluster. This is not a "anyone from outside, instantly" flaw; it is a tool for lateral movement and escalation after a first step inside.

What that attacker does is connect directly to the console's back door and write any token they like into the identity header to impersonate an administrator. Once inside the cluster's control gateway as an admin, the rest is up to them: siphon off stored training data and credentials, plant rogue programs, or use the cluster as a springboard into other internal systems.

The damage runs in two directions. For a company that provides services on this platform, the confidential data and customer information used to train its AI are put at risk wholesale. For the end users of services running on that platform, their information may be siphoned off without their knowledge. That is why the next section — pinning down whether your environment is even affected — matters so much.

Are you affected — judge it by three conditions

The severity is a high CVSS 8.8, but the breakdown shows the attack requires "some low-level privilege (PR:L)." In other words, it only becomes dangerous once a few preconditions line up. Based on Red Hat's advisory, you need to pay attention when all three of the following apply.

• You run Red Hat OpenShift AI — environments where the odh-dashboard console is running are in scope. If you have not deployed OpenShift AI, this flaw does not concern you.
• Your version is 2.25, 3.3, or 3.4 — the streams before the fixed 3.5 are affected. If you have already moved to 3.5 or later, you have nothing to do here.
• Programs you cannot fully trust may share the cluster — this covers setups where multiple teams or partners share the platform, or where machine-learning jobs are accepted from outside. Conversely, a cluster owned by a single team, where you can account for and trust everything running, is far from meeting the condition.

If even one of the three does not apply, the risk of instant takeover through this flaw shrinks. That said, the third — "can you trust it" — depends heavily on how you operate, and one internal compromise breaks the assumption. Start by asking your operations team which version your OpenShift AI is running.

Affected versions at a glance

The table below shows where your OpenShift AI sits. The version is listed in the OpenShift AI deployment details you can view in the OpenShift console or via the oc get command.

The fix was merged upstream on May 27, 2026 and ships in the product as OpenShift AI 3.5. If you are staying on an older stream such as 2.25 or 3.3, check the per-stream update guidance on Red Hat's CVE page and remediate in the way that fits your environment.

Why it happened — trusting the "identity header" at face value

Here is the mechanism in plain terms. The program running behind odh-dashboard (the backend) was supposed to be reachable only through a "gatekeeper" placed in front of it. That gatekeeper is a component widely used in OpenShift called kube-rbac-proxy; its job is to verify that a user is genuine and pass their identity to the backend only when that check succeeds.

Two problems stacked up. First, the backend was listening on an entry point open to the whole cluster (0.0.0.0:8080). Second, that backend swallowed the identity header meant to come from the gatekeeper, "x-forwarded-access-token," without checking where it actually came from. With both in place, any container in the cluster could leap over the gatekeeper, connect straight to the back door, and impersonate anyone just by writing its own token into the header.

This is a "missing origin validation (CWE-346)" flaw — trusting received information without confirming its sender. The fix is straightforward: bind the backend's listener to itself only (127.0.0.1), so direct connections that bypass the gatekeeper are simply refused. The same odh-dashboard has been patched before, for a separate flaw that leaked an internal token externally (CVE-2026-5483, fixed in April 2026), so authentication plumbing has been a recurring theme. The pattern where loose Kubernetes configuration leads to takeover mirrors a low-privilege traffic-hijacking flaw found in OpenShift itself.

What to do right now

If you match the three conditions above, work through the responses in this order, highest priority first.

• Update OpenShift AI to 3.5 or later — this is the root fix. In 3.5 the backend's listener is confined to localhost, closing the path that leaps over the gatekeeper.
• If you cannot update immediately, restrict traffic to mitigate — use Kubernetes traffic control (a NetworkPolicy) to stop other containers from connecting directly to the odh-dashboard backend port, temporarily sealing the attack path.
• Review the "trust boundary" inside your cluster — in a shared setup, separating runtime environments per team or partner and minimizing the privileges of imported jobs keeps a foothold from forming in the first place.
• Check that the gatekeeper (kube-rbac-proxy) is actually in effect — confirm the authentication component sits in front as intended and that there is no bypass around it.

As a stopgap, restricting traffic is the quickest lever, so start there. Then work through a planned update to 3.5 or later. If you want to keep surfacing what weaknesses lurk in the components running in your cluster, making configuration and privilege reviews a routine habit is the shortest path to blocking this kind of internal escalation.

This flaw was found by an AI-driven audit

There is one more feature worth noting. The finder was not an outside researcher but an AI-driven security audit Red Hat runs against its own products, "Project Glasswing." Red Hat's product security team surfaced this issue while having AI inspect source code and configuration, and drove it to a fix under the internal tracking ID RHOAIENG-69351.

AI digging out vulnerabilities without human hands has suddenly become real in recent months. On this site we covered a denial-of-service flaw in Apache that AI discovered. This time it goes a step further: AI audited the very platform on which AI is built and found the hole. Once defenders start using AI, loose configurations that human review has long overlooked may keep coming to the surface.

Put differently, this flaw was caught by the defenders' own inspection before it was used in a real attack. The fact that no exploitation has been reported yet is partly a result of that early discovery.

Is it already being exploited

As of publication, there are no confirmed reports of this flaw being used in a real attack. It is also not currently on the U.S. CISA's "list of flaws confirmed to be exploited (KEV)." You can check the latest listing status in our Japanese-language summary of CISA's confirmed-exploitation list.

Still, do not get complacent. This flaw is the kind that takes effect "after getting inside the cluster," and the damage spreads fast when it is combined with an outside break-in. A multi-stage attack — a foothold made through another weakness, then this flaw to morph into an administrator — is a realistic scenario. While no exploitation is confirmed, affected environments are safer getting updates and traffic restrictions done ahead of time.

What to watch from here

To recap: the flaw is highly rated, but it is not something anyone can hit from the internet — it hinges first on whether there is a foothold inside the cluster. If your OpenShift AI is 2.25, 3.3, or 3.4 and multiple teams or external jobs share the environment, you are affected. If so, buy time with traffic restrictions while working through a planned update to 3.5 or later.

From here, watch how update guidance for the older streams (such as 2.25 and 3.3) is announced, and whether real exploitation or a KEV listing appears. We will add to this article as things move. It is also worth keeping an eye on the official CVE-2026-16745 entry and Red Hat's advisory.

References

• ▸ NVD - CVE-2026-16745 Detail
• ▸ Red Hat - CVE-2026-16745
• ▸ Red Hat Bugzilla - Bug 2506350 (CVE-2026-16745)
• ▸ Red Hat OpenShift AI product page
• ▸ NVD - CVE-2026-5483 (related odh-dashboard flaw)