trustyai-service-operator CVE-2026-15063

Three concrete conditions must be met: (1) Red Hat OpenShift AI must be deployed with the trustyai-service-operator and the gorch service template instantiated; (2) authentication must be enabled on the gorch service - paradoxically, this is the configuration under which the bypass exists, as the unproxied port issue only matters when authentication is otherwise expected to be enforced; (3) the attacker must control a pod with network reachability to the cluster-internal pod network (CVSS AV:A, PR:L). Exploitation is limited by the requirement for an existing cluster foothold - pure external network attackers without prior cluster access cannot reach these ports. There is no user interaction required (UI:N) and no complex timing or race condition (AC:L), meaning exploitation is straightforward once network adjacency is achieved.

The CVSS 3.1 vector AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N scores 6.3 (Medium), which is a reasonable reflection of real-world risk. AV:A (adjacent network) constrains exploitation to the Kubernetes cluster network, meaning only workloads already running inside the cluster can reach the exposed ports - external internet-based attackers cannot directly exploit this without a prior foothold. PR:L further limits exploitation to actors who can schedule or exec into a pod, which implies at least some level of cluster access. The high confidentiality impact (C:H) is the primary risk driver: orchestrator and detector metrics may expose model inference telemetry, request patterns, or operational details useful for reconnaissance. The low integrity impact (I:L) is less clear from the description and may reflect indirect manipulation possibilities. No EPSS data was provided, and there is no CISA KEV listing or known public exploit code, suggesting this has not yet been actively weaponized. The realistic threat actor is a malicious or compromised workload within the same OpenShift cluster, not an external adversary - teams should weight this against their multi-tenancy posture and which namespaces share the cluster network.

An attacker who has obtained execution in any pod on the OpenShift cluster network (via compromised workload, misconfigured RBAC allowing pod creation, or supply chain compromise of a deployed container) issues direct HTTP requests to the gorch service's orchestrator or detector metrics endpoints on their published pod-network ports. Because these ports are unproxied, kube-rbac-proxy is never consulted and no token validation occurs, returning full metrics data to the caller. No public exploit code has been identified at time of analysis.