What is the CVSS score of EUVD-2026-55810?

EUVD-2026-55810 has a CVSS 3.1 base score of 8.0 (High). CVSS vector: CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of TrustyAI Service are affected by EUVD-2026-55810?

An authentication bypass in Red Hat OpenShift AI's TrustyAI Service (CVSS 8.0) allows any pod on the cluster to read, modify, or delete AI model monitoring data and configurations without presenting…. A patch is available.

How to fix or mitigate EUVD-2026-55810?

Within 24 hours: Audit all TrustyAI Service deployments and identify cluster pods with network access to TAS backends. Within 7 days: Implement Kubernetes NetworkPolicies to restrict cluster network access to TAS APIs, enforce Pod Security Standards (restricted profile), and review RBAC policies to minimize excessive cluster access. Within 30 days: Monitor Red Hat advisories for vendor-released patch; establish testing procedures to apply the patch once available; if patching cannot be completed within 60 days, evaluate disabling TrustyAI Service or deploying isolated cluster architectures.

TrustyAI Service EUVD-2026-55810

| CVE-2026-15581 HIGH

Missing Authentication for Critical Function (CWE-306)

2026-08-10 redhat

GHSA-7rjm-5cpg-vwpq

Authentication Bypass Red Hat Openshift Ai Rhoai Red Hat

8.0

CVSS 3.1 · Vendor: redhat

Severity by source

Vendor (redhat) PRIMARY

8.0 HIGH

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

vuln.today AI

8.0 HIGH

AV:A because exploitation requires a pod on the cluster network; PR:L because deploying a pod is a low-privilege tenant capability; full CIA because the unprotected API permits read, write, and delete operations.

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

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

Red Hat

8.0 HIGH

qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector

Adjacent

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 10, 2026 - 21:32 vuln.today

CVE Published

Aug 10, 2026 - 20:44 nvd

HIGH 8.0

DescriptionCVE.org

A flaw was found in the TrustyAI Service (TAS) deployment. This vulnerability allows any pod on the cluster network to bypass authentication and directly access the TAS backend API. An attacker can exploit this to read, tamper with, or delete monitoring data and configurations, and inject arbitrary data into the service, potentially disrupting tenant operations.

AnalysisAI

Authentication bypass in TrustyAI Service (TAS) within Red Hat OpenShift AI (RHOAI) exposes the backend API to any pod on the cluster network without requiring valid credentials. The CVSS vector (AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) confirms that an attacker with a pod on the cluster-such as through a compromised workload or a malicious tenant pod in a multi-tenant deployment-can read, modify, delete, or poison AI model monitoring data and configurations with no additional barriers. No public exploit code or CISA KEV listing has been identified at time of analysis, but the root cause (CWE-306: Missing Authentication for Critical Function) means exploitation is trivially simple once cluster network adjacency is established.

Technical ContextAI

TrustyAI Service is the AI model monitoring and explainability backend within Red Hat OpenShift AI (RHOAI), responsible for collecting and serving bias detection metrics, drift monitoring data, and explainability outputs for tenant AI/ML workloads. The CPE cpe:2.3:a:red_hat:red_hat_openshift_ai_(rhoai):*:*:*:*:*:*:*:* indicates the vulnerability affects all published versions of RHOAI with no version boundary currently defined. CWE-306 (Missing Authentication for Critical Function) identifies the root cause: the TAS backend API does not enforce authentication, relying instead on network-layer assumptions rather than application-layer controls. In Kubernetes/OpenShift environments, all pods sharing the cluster network can reach service endpoints on internal ClusterIP addresses, making 'cluster adjacency' a low barrier-any pod in the cluster, regardless of namespace or tenant, can send direct HTTP requests to the TAS API.

RemediationAI

No exact patched version was identified in the available intelligence data; operators should consult the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-15581 and monitor https://bugzilla.redhat.com/show_bug.cgi?id=2499637 for patch availability and confirmed fix versions. As a compensating control until a patch is applied, implement Kubernetes NetworkPolicy rules to restrict ingress to the TAS backend API to only authorized pods or service accounts-this reduces the cluster-adjacent attack surface by enforcing namespace-level or label-based access controls at the network layer, though it does not fix the underlying missing authentication. Additionally, audit existing cluster workloads for unexpected connections to TAS API endpoints using OpenShift audit logs or network flow data to identify potential prior exploitation. Note that NetworkPolicy-based restriction has the trade-off of requiring careful label management and may block legitimate internal consumers if misconfigured.