CVE-2026-15044: TrustyAI Service Operator Auth Bypass

CVE-2026-15044 Overview

CVE-2026-15044 is a missing authentication flaw in the TrustyAI Service Operator. The operator deploys AI guardrail and orchestration services such as gorch and NemoGuardrails. When a specific security setting remains disabled, these services expose their communication channels without requiring caller authentication. Any workload within the cluster can then reach the guardrails and orchestrator endpoints without proper authorization. An attacker with in-cluster access can read sensitive information and make limited modifications to AI model behavior. Red Hat tracks the issue under Bugzilla report #2498039.

Critical Impact
Unauthenticated in-cluster access to AI guardrails and orchestrator services enables information disclosure and limited tampering with AI model interactions.

Affected Products

TrustyAI Service Operator
gorch orchestrator service deployments managed by the operator
NemoGuardrails service deployments managed by the operator

Discovery Timeline

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

Technical Details for CVE-2026-15044

Vulnerability Analysis

The TrustyAI Service Operator provisions AI trust and safety services inside a Kubernetes cluster. Two of those services, gorch and NemoGuardrails, listen for requests over cluster-internal communication channels. The operator supports a security setting that enforces caller identity verification on these channels. When that setting is not enabled during deployment, the services accept requests from any pod or workload with network reachability. The attack requires adjacent network access with low privileges and no user interaction. Exploitation yields high confidentiality impact and low integrity impact, with no direct impact on availability.

Root Cause

The root cause is a missing authentication requirement on service endpoints [Broken Access Control]. The operator deploys gorch and NemoGuardrails with authentication controls disabled by default unless the deploying user explicitly opts in. Callers are not required to prove identity before invoking guardrail or orchestrator APIs, so authorization decisions cannot be enforced.

Attack Vector

An attacker who controls a workload in the same cluster sends requests directly to the exposed gorch or NemoGuardrails service. Because no authentication is enforced, the requests are processed. The attacker can retrieve prompts, responses, guardrail policies, and orchestration configuration. The attacker can also submit inputs that alter model behavior within the limits of the exposed API surface.

No verified public exploit code is available. Refer to the Red Hat CVE-2026-15044 Advisory and Red Hat Bugzilla Report #2498039 for vendor technical details.

Detection Methods for CVE-2026-15044

Indicators of Compromise

Unexpected in-cluster HTTP or gRPC requests to gorch or NemoGuardrails service endpoints originating from workloads outside the intended caller set.
Service logs showing successful API calls without an associated authenticated principal or service account token.
Anomalous volumes of guardrail policy queries or orchestration requests from a single pod or namespace.

Detection Strategies

Audit TrustyAI Service Operator custom resources for deployments where the authentication security setting is disabled.
Inspect Kubernetes NetworkPolicies covering the namespaces running gorch and NemoGuardrails and flag any that permit cluster-wide ingress.
Correlate service access logs with pod identity to identify calls that lack a valid authentication token.

Monitoring Recommendations

Enable request logging on gorch and NemoGuardrails and forward logs to a centralized analytics platform.
Monitor for east-west traffic to guardrail service ports from unexpected source namespaces.
Alert on configuration drift when the operator reconciles a service with authentication disabled.

How to Mitigate CVE-2026-15044

Immediate Actions Required

Enable the authentication security setting on all TrustyAI Service Operator custom resources that deploy gorch or NemoGuardrails.
Restrict ingress to guardrail and orchestrator services using Kubernetes NetworkPolicies scoped to authorized client workloads.
Rotate any credentials, API keys, or model configuration that may have been exposed through unauthenticated access.

Patch Information

Consult the Red Hat CVE-2026-15044 Advisory for fixed operator versions and product-specific errata. Update the TrustyAI Service Operator to the version identified in the advisory and re-reconcile existing custom resources so the authentication setting is applied to running services.

Workarounds

Deploy a service mesh with mutual TLS (mTLS) in front of gorch and NemoGuardrails to enforce caller identity outside the application.
Apply strict NetworkPolicies that allow only named client service accounts or namespaces to reach the affected service ports.
Place the services behind an authenticating reverse proxy until the operator setting can be enabled cluster-wide.

bash

# Configuration example: restrict ingress to gorch and NemoGuardrails services
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: trustyai-guardrails-restrict
  namespace: trustyai
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/part-of: trustyai
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              trustyai-client: "true"
        - podSelector:
            matchLabels:
              role: guardrails-client
EOF