CVE-2025-12805: OpenShift AI Auth Bypass Vulnerability

CVE-2025-12805 Overview

A security flaw has been identified in Red Hat OpenShift AI (RHOAI) llama-stack-operator that allows unauthorized cross-namespace access to Llama Stack services. The vulnerability exists because no NetworkPolicy restricts access to the llama-stack service endpoint, enabling users in one namespace to access another user's Llama Stack instance via direct network requests. This broken access control weakness (CWE-653: Improper Isolation or Compartmentalization) can lead to viewing or manipulation of sensitive data belonging to other users.

Critical Impact

Attackers with low privileges can access other users' Llama Stack instances across namespaces, potentially exposing sensitive AI model data, configurations, and enabling unauthorized data manipulation.

Affected Products

• Red Hat OpenShift AI (RHOAI)
• llama-stack-operator deployments without NetworkPolicy enforcement
• Multi-tenant Kubernetes/OpenShift environments running Llama Stack services

Discovery Timeline

• 2026-03-26 - CVE-2025-12805 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2025-12805

Vulnerability Analysis

This vulnerability represents a fundamental isolation failure in the llama-stack-operator component of Red Hat OpenShift AI. In properly secured multi-tenant Kubernetes environments, NetworkPolicies are essential for enforcing namespace-level isolation, preventing pods in one namespace from communicating with services in another namespace without explicit authorization.

The llama-stack-operator fails to deploy the necessary NetworkPolicy resources when provisioning Llama Stack services. This oversight means that any authenticated user with access to the OpenShift cluster can craft network requests to access Llama Stack service endpoints in other namespaces. Given that Llama Stack services handle AI model inference requests and potentially sensitive training data, this cross-namespace access creates a significant data exposure risk.

The attack requires network-level access to the cluster (AV:N) and only low privileges (PR:L) to execute. No user interaction is required (UI:N), and the vulnerability impacts both confidentiality (C:H) and integrity (I:H) of data in affected Llama Stack instances, though availability remains unaffected (A:N).

Root Cause

The root cause of this vulnerability is improper isolation or compartmentalization (CWE-653). The llama-stack-operator does not create or enforce Kubernetes NetworkPolicy resources that would restrict ingress traffic to llama-stack service endpoints. Without these policies, the default Kubernetes networking behavior allows unrestricted pod-to-pod communication across namespace boundaries.

Attack Vector

The attack exploits the missing network segmentation between namespaces in OpenShift/Kubernetes environments running the vulnerable llama-stack-operator. An attacker with valid credentials to the cluster (even with minimal privileges) can perform the following attack sequence:

1. Enumerate services across namespaces using standard Kubernetes API calls or network scanning
2. Identify Llama Stack service endpoints in target namespaces
3. Send direct network requests to the discovered llama-stack service endpoints
4. Access, view, or manipulate data belonging to other users' Llama Stack instances

The exploitation does not require elevated privileges within the cluster—only basic network access and the ability to route traffic to the target service endpoint. The service endpoints typically expose inference APIs that can return model outputs and potentially reveal sensitive information processed by the AI services.

Detection Methods for CVE-2025-12805

Indicators of Compromise

• Unexpected network connections to llama-stack service endpoints from pods in other namespaces
• API requests to Llama Stack services originating from unauthorized source namespaces
• Unusual query patterns or data access requests across namespace boundaries
• Authentication logs showing access attempts from unexpected service accounts

Detection Strategies

• Implement network traffic monitoring to detect cross-namespace communications to llama-stack services
• Deploy Kubernetes audit logging to capture API calls and service access patterns
• Use network flow analysis tools to identify anomalous traffic between namespaces
• Monitor for enumeration activities targeting service endpoints across the cluster

Monitoring Recommendations

• Enable Kubernetes audit policy for all API server requests to detect reconnaissance activities
• Configure network observability tools (such as Cilium Hubble or Calico Enterprise) to track cross-namespace traffic flows
• Set up alerts for any network traffic targeting llama-stack service ports from non-authorized source namespaces
• Review service account permissions and pod security contexts regularly

How to Mitigate CVE-2025-12805

Immediate Actions Required

• Apply the security patches provided in Red Hat Security Advisories RHSA-2026:2106 and RHSA-2026:2695
• Manually deploy NetworkPolicy resources to restrict access to llama-stack service endpoints
• Audit existing Llama Stack deployments for signs of unauthorized access
• Review Kubernetes RBAC configurations to ensure namespace isolation principles are enforced

Patch Information

Red Hat has released security advisories addressing this vulnerability. Organizations running affected versions of Red Hat OpenShift AI should apply the patches immediately:

• Red Hat Security Advisory RHSA-2026:2106
• Red Hat Security Advisory RHSA-2026:2695

Additional technical details are available in Red Hat Bugzilla Report #2413101 and the Red Hat CVE page for CVE-2025-12805.

Workarounds

• Deploy a NetworkPolicy in each namespace running llama-stack services to restrict ingress traffic to authorized sources only
• Implement namespace-level network isolation using Kubernetes Network Policies or CNI-specific policies (Calico, Cilium)
• Use service mesh solutions (such as Istio or OpenShift Service Mesh) to enforce mTLS and authorization policies between services
• Consider deploying dedicated network policies that explicitly deny cross-namespace traffic by default

# Example NetworkPolicy to restrict llama-stack service access
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-llama-stack-access
  namespace: <your-llama-stack-namespace>
spec:
  podSelector:
    matchLabels:
      app: llama-stack
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: <authorized-namespace>
      ports:
        - protocol: TCP
          port: 8080