What is the CVSS score of CVE-2025-12103?

CVE-2025-12103 has a CVSS 3.1 base score of 5.0 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2025-12103?

Yes, a patch is available for CVE-2025-12103. Update the affected software to the latest version immediately.

Red Hat OpenShift AI CVE-2025-12103

MEDIUM

Incorrect Privilege Assignment (CWE-266)

2025-10-28 secalert@redhat.com

Information Disclosure Red Hat

5.0

CVSS 3.1 · Vendor: redhat

Severity by source

Vendor (redhat) PRIMARY

5.0 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

vuln.today AI

5.0 MEDIUM

Any authenticated cluster user exploits over the network with no complexity; scope changes across namespaces; read-only pod/PVC enumeration yields low confidentiality impact only.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N

Red Hat

5.0 MEDIUM

qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

Jul 25, 2026 - 12:06 vuln.today

DescriptionCVE.org

A flaw was found in Red Hat Openshift AI Service. The TrustyAI component is granting all service accounts and users on a cluster permissions to get, list, watch any pod in any namespace on the cluster.

TrustyAI is creating a role trustyai-service-operator-lmeval-user-role and a CRB trustyai-service-operator-default-lmeval-user-rolebinding which is being applied to system:authenticated making it so that every single user or service account can get a list of pods running in any namespace on the cluster

Additionally users can access all persistentvolumeclaims and lmevaljobs

AnalysisAI

Incorrect privilege assignment in the TrustyAI component of Red Hat OpenShift AI exposes pod, PersistentVolumeClaim, and LMEvalJob metadata cluster-wide to every authenticated user or service account. The TrustyAI operator automatically provisions a ClusterRoleBinding that binds the role trustyai-service-operator-lmeval-user-role to system:authenticated, the built-in Kubernetes group encompassing all authenticated identities - meaning any user or workload with valid cluster credentials inherits get/list/watch permissions on pods in every namespace. No special conditions are required beyond holding any valid credential on the cluster. No public exploit has been identified at time of analysis, and the EPSS score of 0.03% reflects low opportunistic exploitation probability, though the misconfiguration is trivially leveraged by any cluster tenant.

Technical ContextAI

TrustyAI is a model explainability and fairness evaluation operator within Red Hat OpenShift AI, designed to support LLM evaluation jobs (LMEvalJob CRD) on OpenShift Kubernetes clusters. The flaw stems from CWE-266 (Incorrect Privilege Assignment): the operator's installation logic creates a ClusterRole (trustyai-service-operator-lmeval-user-role) granting get/list/watch verbs on pods, persistentvolumeclaims, and lmevaljobs resources, then binds this role via a ClusterRoleBinding (trustyai-service-operator-default-lmeval-user-rolebinding) to the system:authenticated group. In Kubernetes RBAC, system:authenticated is an implicit group that includes every user and service account that has successfully authenticated to the API server - making this a cluster-scoped privilege escalation that violates namespace isolation. The CVSS Scope:Changed metric correctly reflects that the flaw crosses namespace trust boundaries, allowing a tenant in namespace A to enumerate pods in namespace B.

Affected ProductsAI

Red Hat OpenShift AI with the TrustyAI component installed is affected. The flaw is introduced automatically upon deployment of the TrustyAI service operator, which creates the overpermissive ClusterRoleBinding as part of its standard installation. Specific affected versions and platform build numbers are detailed in vendor advisories RHSA-2025:21117 (https://access.redhat.com/errata/RHSA-2025:21117) and RHSA-2026:10184 (https://access.redhat.com/errata/RHSA-2026:10184). The issue is tracked upstream at https://bugzilla.redhat.com/show_bug.cgi?id=2405966. CPE data for specific RHEL/OpenShift AI package versions was not included in the provided intelligence but should be confirmed via the Red Hat CVE page at https://access.redhat.com/security/cve/CVE-2025-12103.

RemediationAI

Apply the vendor-released patches detailed in RHSA-2025:21117 (https://access.redhat.com/errata/RHSA-2025:21117) and RHSA-2026:10184 (https://access.redhat.com/errata/RHSA-2026:10184); exact patched package versions should be sourced directly from these advisories as specific version strings were not included in available intelligence. As an immediate compensating control prior to patching, administrators should manually delete or patch the ClusterRoleBinding trustyai-service-operator-default-lmeval-user-rolebinding to bind to a specific, narrowly scoped group or ServiceAccount rather than system:authenticated - note this may temporarily disrupt TrustyAI LMEvalJob scheduling if the operator legitimately depends on this binding. A second control is to audit existing cluster audit logs for unexpected cross-namespace pod list/watch calls from non-operator service accounts, which would reveal if the misconfiguration has already been leveraged for reconnaissance. Re-applying the operator upgrade without first removing the overpermissive CRB may leave the binding in place if the operator does not clean up the old binding during upgrade; verify CRB removal post-patch.