CVE-2026-15063: TrustyAI Service Auth Bypass Vulnerability

CVE-2026-15063 Overview

CVE-2026-15063 is an authentication bypass vulnerability in the gorch service template shipped with the trustyai-service-operator. The service exposes orchestrator and detector metrics ports without routing them through kube-rbac-proxy. Any pod on the cluster network can reach these ports directly, bypassing the authentication layer that operators expect to enforce access control. The flaw is tracked under CWE-306: Missing Authentication for Critical Function and enables unauthorized read access to model orchestration and detector telemetry.

Critical Impact
Adjacent-network attackers with any pod foothold in the cluster can read orchestrator and detector metrics without credentials, exposing sensitive operational data from TrustyAI workloads.

Affected Products

trustyai-service-operator (Red Hat)
gorch service template deployments
OpenShift clusters running TrustyAI orchestrator and detector components

Discovery Timeline

2026-07-08 - CVE-2026-15063 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-15063

Vulnerability Analysis

The trustyai-service-operator deploys the gorch (guardrails orchestrator) component together with a sidecar-based kube-rbac-proxy. The proxy is intended to authenticate and authorize all inbound requests to metrics endpoints exposed by the orchestrator and its detector subsystems. In the affected service template, the raw orchestrator and detector metrics ports remain bound to the pod network without being fronted by the proxy. Requests sent directly to those ports never traverse the authentication path.

The result is a split trust boundary. External access via the proxy port enforces RBAC, while direct in-cluster access to the unproxied ports does not. Any workload that can resolve the service or pod IP can retrieve metrics containing model orchestration state, detector activity, and inference-related telemetry.

Root Cause

The root cause is a service template misconfiguration. The Kubernetes Service and container port definitions expose the orchestrator and detector metrics listeners in addition to the proxied endpoint. Because kube-rbac-proxy is not the sole ingress path, its authentication and authorization checks can be trivially avoided. This maps directly to [CWE-306], where a critical function (metrics retrieval containing sensitive workload data) lacks required authentication.

Attack Vector

Exploitation requires an adjacent network position, specifically an attacker-controlled or compromised pod on the same cluster network. The attacker issues an HTTP GET against the exposed orchestrator or detector metrics port on the gorch service or pod IP. No credentials, tokens, or service account bindings are needed. The response returns Prometheus-formatted metrics that may include operational counters, detector names, model identifiers, and request patterns useful for reconnaissance or downstream attacks against the AI serving pipeline. See the Red Hat CVE-2026-15063 Advisory for vendor-confirmed technical details.

Detection Methods for CVE-2026-15063

Indicators of Compromise

Unexpected HTTP requests to orchestrator or detector metrics ports originating from pods that are not part of the monitoring stack (Prometheus, OpenShift monitoring).
Network flows to gorch pod IPs on metrics ports that bypass the kube-rbac-proxy sidecar port.
Repeated /metrics scrapes from workloads outside the observability namespace.

Detection Strategies

Audit Service and Pod manifests for the trustyai-service-operator and confirm which ports are exposed without proxy fronting.
Enable Kubernetes NetworkPolicy logging or CNI flow logs to identify pods communicating with gorch metrics ports.
Cross-reference Prometheus scrape configurations with actual observed clients on the metrics ports.

Monitoring Recommendations

Continuously monitor east-west traffic to TrustyAI namespaces and alert on non-monitoring source pods reaching metrics endpoints.
Track anomalous DNS resolutions for gorch service names from workloads outside expected namespaces.
Review OpenShift audit logs for changes to trustyai-service-operator CRDs and service templates.

How to Mitigate CVE-2026-15063

Immediate Actions Required

Apply the fixed trustyai-service-operator release once published by Red Hat as referenced in Red Hat Bugzilla Report #2498058.
Restrict network access to gorch pods using Kubernetes NetworkPolicy that allows only the monitoring namespace to reach metrics ports.
Inventory clusters running TrustyAI to identify exposed orchestrator and detector ports.

Patch Information

Red Hat tracks remediation under the Red Hat CVE-2026-15063 Advisory. Consult the advisory for fixed component versions and update guidance for OpenShift AI and TrustyAI deployments.

Workarounds

Deploy a default-deny NetworkPolicy in the TrustyAI namespace and explicitly allow only Prometheus scrapers via the kube-rbac-proxy port.
Rebind orchestrator and detector metrics listeners to 127.0.0.1 so they are only reachable by the in-pod proxy sidecar.
Remove the unproxied port entries from the Service object until the operator ships a corrected template.

bash

# Example NetworkPolicy restricting gorch metrics access to the monitoring namespace
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: gorch-metrics-restrict
  namespace: trustyai
spec:
  podSelector:
    matchLabels:
      app: gorch
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: openshift-monitoring
      ports:
        - protocol: TCP
          port: 8443
EOF