Skip to main content

TrustyAI Operator CVE-2026-15044

| EUVDEUVD-2026-42283 MEDIUM
Information Exposure (CWE-200)
2026-07-08 secalert@redhat.com GHSA-569j-6vhh-8mc3
6.3
CVSS 3.1 · Vendor: redhat
Share

Severity by source

Vendor (redhat) PRIMARY
6.3 MEDIUM
AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
vuln.today AI
6.3 MEDIUM

Adjacent vector confirmed by cluster-internal scope; PR:L reflects required cluster foothold; C:H for sensitive guardrail data exposure; I:L for described limited model changes.

3.1 AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
4.0 AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Red Hat
6.3 MEDIUM
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
Low
Availability
None

Lifecycle Timeline

1
Analysis Generated
Jul 08, 2026 - 16:03 vuln.today

DescriptionCVE.org

A flaw was found in the TrustyAI Service Operator. When deploying services like gorch or NemoGuardrails, if a specific security setting is not enabled, these services can expose their communication channels without requiring users to prove their identity. This allows any other program within the cluster to access the AI guardrails and orchestrator without proper authorization. An attacker could exploit this to gain unauthorized access to sensitive information and potentially make limited changes to the AI models.

AnalysisAI

Unauthenticated cluster-internal access to TrustyAI Service Operator's gorch and NemoGuardrails deployments is possible when a specific security setting is not explicitly enabled at deployment time. Any workload running within the same Kubernetes or OpenShift cluster can reach these AI guardrail and orchestration service endpoints without presenting credentials, exposing sensitive inference data and enabling limited unauthorized model interactions. No public exploit has been identified at time of analysis, but the low-complexity adjacent attack vector and low-privilege prerequisite make this a realistic lateral movement risk in shared or multi-tenant cluster environments.

Technical ContextAI

TrustyAI is a Red Hat-backed Kubernetes operator for deploying AI trustworthiness services on OpenShift, including guardrail enforcement via NemoGuardrails and AI orchestration via gorch. The flaw arises from a missing or non-default authentication enforcement configuration at the service communication layer - essentially, intra-cluster service endpoints are left unauthenticated unless the operator is explicitly configured to require it. Although CWE is listed as N/A in the source data, the behavior maps closely to CWE-306 (Missing Authentication for Critical Function) and CWE-284 (Improper Access Control). The CVSS adjacent-network vector (AV:A) confirms the attack surface is bounded to pod-to-pod or service-to-service communication within the cluster network fabric, rather than the public internet. The vulnerability is tracked under ENISA EUVD-2026-42283 and Red Hat Bugzilla 2498039.

Affected ProductsAI

The TrustyAI Service Operator is affected specifically when deploying gorch or NemoGuardrails services without enabling the requisite authentication/security setting. The vulnerability applies to the operator's service deployment lifecycle rather than a specific binary version disclosed in available data. Exact affected operator version ranges are not independently confirmed from the available intelligence; administrators must consult the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-15044 and the Bugzilla report at https://bugzilla.redhat.com/show_bug.cgi?id=2498039 for authoritative version scope.

RemediationAI

The primary remediation is to apply the vendor-released patch from Red Hat - consult https://access.redhat.com/security/cve/CVE-2026-15044 for the specific patched TrustyAI operator version, which is not independently confirmed in available data. Prior to patching, administrators should immediately audit all TrustyAI deployments to verify that the authentication-enforcement security setting is explicitly enabled in the operator configuration for any gorch or NemoGuardrails service; the exact parameter name should be confirmed from the Red Hat advisory at the link above. As a complementary compensating control, apply Kubernetes NetworkPolicies to restrict pod-to-pod communication to only explicitly authorized workloads that require access to TrustyAI service endpoints - note that NetworkPolicy enforcement depends on the CNI plugin in use (e.g., Calico, OVN-Kubernetes) and is not a substitute for application-level authentication. No exact patched version number was available in the provided intelligence; do not apply an untested version without confirming from the vendor advisory.

Vendor StatusVendor

Share

CVE-2026-15044 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy