AI SecurityKubernetesIAM

IAM in Danger: Why Red Hat's 'Important' Rating for CVE-2025-10725 is Dangerously Wrong

A simple RBAC misconfiguration in Red Hat OpenShift AI lets any authenticated user become a full cluster administrator. Red Hat calls it Important. With a CVSS of 9.9, the rest of the world calls it Critical.

This post was originally published on LinkedIn.

TL;DR

  • A simple misconfiguration in Red Hat OpenShift AI (CVE-2025-10725) lets any authenticated user — from a data scientist to an intern — become a full cluster administrator.
  • Red Hat calls it “Important”. With a CVSS score of 9.9, the rest of the world calls it “Critical”. The vendor rating is dangerously misleading.
  • The vulnerability isn’t a complex software bug; it’s a policy failure. Someone effectively gave admin-level keys to everyone with a building pass.
  • The fix is simple: patch immediately or remove the misconfigured rule. The bigger lesson is that in the AI era, boring identity and access management (IAM) policy is your most important security control.

As “Important” as full AI cluster takeover

Enterprises racing to adopt AI platforms can’t afford this kind of oversight.

CVE-2025-10725 in Red Hat OpenShift AI is a textbook case of how a simple mistake in configuration can completely dismantle the security of a critical, enterprise-grade platform. It’s a glaring oversight in Role-Based Access Control (RBAC) that allows any user who can log into the system to grant themselves the keys to the entire kingdom.

And to call its severity “Important” is a serious understatement.

Let’s break it down

This wasn’t some obscure bug. It was clearly a RBAC blunder: a ClusterRoleBinding connected the kueue-batch-user-role to the all-powerful system:authenticated group, giving everyone in the building the keys to the server room.

Practical exploit, step by step:

  1. Log in. Any corporate SSO, compromised password, or even a basic account that gets you in the platform is good enough.
  2. Use standard cluster tools (kubectl, oc) to create batch workloads anywhere, skipping every boundary you were supposed to have.
  3. Launch a pod that grabs a privileged service account or escalates further — think “privileged: true” or RBAC changes via initContainer.
  4. Chain impersonations or modify more RBAC objects until your account has full cluster-admin power.
  5. You’re now root. Add yourself as cluster-admin, and do as you please.

No malware, no fancy hacking, just misconfig and API calls. This is cloud attack at its most basic.

Why “just an authenticated user” misses the point

OpenShift AI is built for collaboration, which means “authenticated user” is everyone. Any phished credential, rogue insider, or third-party contractor could flip this misconfiguration into a platform-wide breach. This shows a dangerous misunderstanding of how open most enterprise AI clusters are in practice.

What gets stolen and broken?

Gaining cluster-admin rights is the end of the game. An attacker has total control. This exposes:

  • Your Data: Customer info, financials, and the models you worked months to build.
  • Your Models: Attackers don’t just take models — they can pollute training data, inject subtle backdoors, and flip your AI from asset to spy.
  • Your Operations: One attacker can wipe out workloads, destroy datasets, and drop applications, bringing everything to a standstill.

Immediate actions — seriously, not optional

  • Patch or Unbind: If you’re on RHOAI 2.19 or 2.21, patch now. If not, yank the misconfigured ClusterRoleBinding fast.
  • Automate Guardrails: Use policy-as-code tools so dangerous RBAC changes simply won’t deploy, ever — even after a late-night edit.
  • Continuous RBAC Audits: Set up tools like RHACS or your preferred KSPM that flag privilege drift or oversized group privileges in real time.
  • Least Privilege, Not “Just Works”: Never allow big RBAC groups to hold important roles. Service accounts should be tiny, reviewed, and ruthlessly scoped down.
  • Admission Controls: Stop creation of privileged pods and dangerous workload configs before they get a chance to do damage.

Pro blueprint for safer AI RBAC

  • Split Roles: Notebook users, admins, automation agents — clear walls, no exceptions.
  • Namespace Everything: Each project, team, or client gets their own sandbox with zero cross-access.
  • Policy-as-Code, Always: CI/CD for RBAC changes, no manual tweaks; automated checks block anything risky.
  • Scan Continuously, Not Quarterly: KSPM should alert instantly when dangerous privilege chains even flicker into existence.

The deeper lesson

Default configs aren’t just risky — they can be the difference between resilience and ruin. The “smarter model” hype only works if basic identity policy isn’t an afterthought. Security should always be the baseline, not the bonus track.

← All posts