CVE-2025-12103
📋 TL;DR
This vulnerability in Red Hat OpenShift AI Service's TrustyAI component grants excessive permissions to all authenticated users and service accounts. It allows any authenticated entity to list pods, persistent volume claims, and LMEvalJobs across all namespaces in the cluster. This affects all OpenShift AI deployments using the vulnerable TrustyAI component.
💻 Affected Systems
- Red Hat OpenShift AI Service
⚠️ Manual Verification Required
This CVE does not have specific version information in our database, so automatic vulnerability detection cannot determine if your system is affected.
Why? The CVE database entry doesn't specify which versions are vulnerable (no version ranges provided by the vendor/NVD).
🔒 Custom verification scripts are available for registered users. Sign up free to download automated test scripts.
- Review the CVE details at NVD
- Check vendor security advisories for your specific version
- Test if the vulnerability is exploitable in your environment
- Consider updating to the latest version as a precaution
⚠️ Risk & Real-World Impact
Worst Case
Attackers could map the entire cluster infrastructure, identify sensitive workloads, and potentially use pod information to plan further attacks like privilege escalation or data exfiltration.
Likely Case
Unauthorized users can enumerate all running pods and resources, exposing sensitive application information and cluster architecture details that should remain confidential.
If Mitigated
With proper network segmentation and authentication controls, the impact is limited to information disclosure within already-trusted network segments.
🎯 Exploit Status
Exploitation requires authenticated access to the cluster but uses standard Kubernetes API calls.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: OpenShift AI 2.9.3 or later
Vendor Advisory: https://access.redhat.com/errata/RHSA-2025:21117
Restart Required: No
Instructions:
1. Update OpenShift AI to version 2.9.3 or later. 2. Apply the updated TrustyAI operator. 3. Verify the excessive role bindings have been removed.
🔧 Temporary Workarounds
Remove excessive role bindings
allManually delete the overly permissive role bindings created by TrustyAI
kubectl delete clusterrolebinding trustyai-service-operator-default-lmeval-user-rolebinding
🧯 If You Can't Patch
- Implement strict network policies to limit access to Kubernetes API server
- Use admission controllers to prevent creation of overly permissive role bindings
🔍 How to Verify
Check if Vulnerable:
Check if the vulnerable role binding exists: kubectl get clusterrolebinding trustyai-service-operator-default-lmeval-user-rolebindingCheck Version:
oc get csv -n redhat-ods-operator | grep opendatahub-operatorVerify Fix Applied:
Verify the role binding no longer exists and check OpenShift AI version is 2.9.3+📡 Detection & Monitoring
Log Indicators:
- Unusual pod listing requests from non-admin users
- Multiple GET /api/v1/pods requests from single users
Network Indicators:
- Excessive Kubernetes API calls to list resources from unexpected sources
SIEM Query:
source="kubernetes" AND (verb="list" OR verb="watch") AND resource="pods" AND user!="system:serviceaccount:kube-system:*"