A flaw was found in the `guardrails-detectors` component

The file_type content detector in Red Hat's guardrails-detectors — the component that inspects prompts and responses in OpenShift AI's TrustyAI/Guardrails orchestrator — accepts a user-supplied XML Schema Definition string via an xml-with-schema: prefix. The XSD parser resolves external references without a URL allow-list, so an attacker can point the fetch at http://169.254.169.254/ (AWS/GCP/Azure IMDS), http://localhost:6443 (in-cluster kube-apiserver), or file:///etc/passwd and force the detector pod to return the content. Affected: guardrails-detectors shipped in Red Hat OpenShift AI (RHOAI) self-managed 2.x and 3.0–3.3, plus the corresponding managed RHOAI offering, prior to the 2026-07-10 backport.

Red Hat scored this 9.3 CRITICAL primarily on the Scope-Changed (S:C) + C:H combination — the SSRF crosses the pod boundary and can egress cluster secrets. That math is defensible but overstated for the realistic deployment: the guardrails inference endpoint is not internet-exposed by default; it sits behind the OpenShift AI model-serving route, which requires a bearer token or OAuth proxy in nearly every documented install. The primitive is powerful (IMDSv1 credential theft, kube-apiserver probing, arbitrary file read as the detector service account) but the population able to reach it un-auth'd is small. HIGH is the honest read.

Why this verdict

• Auth gate reduces exposure ~99%: Red Hat's stock RHOAI deployment fronts the orchestrator Route with an OAuth proxy — the PR:N in the vector reflects the code path, not the deployment. Un-auth external attack is only viable on lab/PoC installs.
• IMDSv2 kills the classic credential-theft chain: AWS EKS clusters running IMDSv2 with hop-limit=1 (default since 2023) block the pod-to-metadata SSRF variant entirely. GCP and Azure require an identity header. This narrows the highest-impact outcome to environments still on IMDSv1.
• Role multiplier — AI inference tier is typical, not high-value: The guardrails-detectors pod is a stateless content-classification worker. Its SA in a well-scoped RHOAI install has read-only model-registry access, not cluster-admin. Blast radius stops at the tenant namespace in most deployments.
• Role multiplier — but shared-tenant RHOAI at ≥1% of installs is a floor case: In multi-tenant RHOAI (research clusters, internal AI-platform-as-a-service), the detector SA often has cross-namespace read for model artifacts. SSRF → SA token → cross-tenant model/data read is a fleet-scale outcome for that role. That keeps the floor at HIGH.
• No KEV, no PoC, EPSS 0.4%: the urgency curve is 'patch on your HIGH SLA', not 'drop everything today'. Reassess in 14 days if a Nuclei template lands.

Why not higher?

CRITICAL requires either unauth-internet-reachable exploitation at scale or a canonical high-value-role component (hypervisor, IdP, DC, backup, EDR kernel driver). Guardrails-detectors is an AI content filter — meaningful but not identity-plane or hypervisor-plane. The auth requirement plus IMDSv2 default plus <200 internet-exposed instances collectively rule out CRITICAL.

Why not lower?

MEDIUM would require the blast radius to end at the pod, but SSRF-to-cloud-metadata and SSRF-to-kube-apiserver are documented reachable outcomes and RHOAI shared-tenant installs do exist. Any deployment on IMDSv1 or with a broadly-scoped detector SA gets full cluster credential theft — that outcome forbids anything softer than HIGH.

1. Force IMDSv2 with hop-limit=1 on every RHOAI worker node — This single change neutralizes the highest-impact exploitation branch (cloud credential theft). On AWS: aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1. Deploy within the noisgate HIGH mitigation SLA of 30 days — ideally this week; it is a defense-in-depth win regardless of this CVE.
2. Apply an egress NetworkPolicy to the guardrails-detectors namespace — Deny egress to 169.254.169.254/32, fd00:ec2::254/128, cluster CIDR internal service IPs, and any non-model-registry external host. This blocks both IMDS SSRF and internal service probing. Deploy within 30 days per the noisgate HIGH mitigation SLA.
3. Front the guardrails-orchestrator Route with the OAuth proxy and verify token requirement — Run oc get route -n redhat-ods-applications and confirm every guardrails Route has spec.tls and an authenticating sidecar. Un-auth exposure converts this from HIGH to effective CRITICAL for that install. Verify within 30 days.
4. Scope the guardrails-detectors ServiceAccount to least privilege — Audit its RoleBindings — the SA should NOT hold cross-namespace or cluster-wide read on Secrets, ConfigMaps, or the model registry. Use kubectl auth can-i --list --as=system:serviceaccount:.... Cap within 30 days.
5. Add a WAF/orchestrator-layer filter for xml-with-schema: prefix — As a stopgap until the RHOAI backport is applied, drop or reject any detector request body starting with xml-with-schema:. Deploy within 3 days as an immediate tactical block.

Run this on a workstation with oc logged in as a cluster-admin (or any account with read on the redhat-ods-applications namespace and node access). Invoke as ./check-cve-2026-15378.sh. It inventories the guardrails-detectors image tag and the NetworkPolicy/IMDS posture, then classifies the cluster as VULNERABLE / PATCHED / UNKNOWN.

#!/usr/bin/env bash
# check-cve-2026-15378.sh — noisgate verifier for RHOAI guardrails-detectors SSRF
# Requires: oc (logged in), jq, and optional aws CLI for IMDS check.
set -u

NS="redhat-ods-applications"
FIXED_TAGS_REGEX='(2\.19\.[1-9]|3\.0\.[2-9]|3\.[1-3]\.[1-9])'  # adjust to RHSA-announced tags

echo "[*] Inventorying guardrails-detectors pods in ${NS}..."
PODS=$(oc get pods -n "${NS}" -l app.kubernetes.io/name=guardrails-detectors -o json 2>/dev/null)
if [ -z "${PODS}" ] || [ "$(echo "${PODS}" | jq '.items | length')" -eq 0 ]; then
  echo "[+] No guardrails-detectors pods found — component not deployed."
  echo "RESULT: PATCHED (not applicable)"
  exit 0
fi

IMAGES=$(echo "${PODS}" | jq -r '.items[].spec.containers[].image' | sort -u)
echo "[*] Detected images:"
echo "${IMAGES}" | sed 's/^/    /'

VULN=0
for IMG in ${IMAGES}; do
  TAG="${IMG##*:}"
  if echo "${TAG}" | grep -Eq "${FIXED_TAGS_REGEX}"; then
    echo "[+] ${IMG} — tag ${TAG} appears fixed."
  else
    echo "[-] ${IMG} — tag ${TAG} does NOT match known fixed range."
    VULN=1
  fi
done

echo "[*] Checking egress NetworkPolicy for IMDS block..."
NP=$(oc get networkpolicy -n "${NS}" -o json | jq -r '.items[].spec.egress[]?.to[]?.ipBlock.except[]?' 2>/dev/null | grep -c '169.254.169.254' || true)
if [ "${NP:-0}" -lt 1 ]; then
  echo "[-] No NetworkPolicy blocking egress to 169.254.169.254 — SSRF-to-IMDS reachable."
  VULN=1
else
  echo "[+] NetworkPolicy blocks 169.254.169.254."
fi

echo "[*] Checking IMDSv2 enforcement on worker nodes (AWS only)..."
if command -v aws >/dev/null 2>&1; then
  NODES=$(oc get nodes -o json | jq -r '.items[].spec.providerID' | grep -oE 'i-[a-f0-9]+' | sort -u)
  for I in ${NODES}; do
    MODE=$(aws ec2 describe-instances --instance-ids "${I}" --query 'Reservations[].Instances[].MetadataOptions.HttpTokens' --output text 2>/dev/null)
    if [ "${MODE}" != "required" ]; then
      echo "[-] Node ${I} allows IMDSv1 (HttpTokens=${MODE})."
      VULN=1
    fi
  done
else
  echo "[?] aws CLI not present — IMDS posture UNKNOWN."
fi

if [ "${VULN}" -eq 1 ]; then
  echo "RESULT: VULNERABLE"
  exit 2
fi
echo "RESULT: PATCHED"
exit 0

Sources

1. Red Hat CVE Database — CVE lookup portal
2. Red Hat OpenShift AI 3.3 — Enabling AI safety with Guardrails
3. Red Hat OpenShift AI 3.0 — Chapter 1: Enabling AI safety with Guardrails
4. CSO Online — Red Hat OpenShift AI weakness allows full cluster compromise
5. CWE-918: Server-Side Request Forgery (SSRF)
6. Red Hat Developer — Configure input guardrails for an OpenShift AI voice agent
7. AWS IMDSv2 enforcement documentation
8. trustyai-explainability/guardrails-detectors upstream