Critical SSRF Flaw in Red Hat OpenShift AI Exposes Cloud Secrets, K8s Tokens

Red Hat has disclosed a high-severity vulnerability in the guardrails-detectors component of Red Hat OpenShift AI (RHOAI), tracked as CVE-2026-15378, that allows remote attackers to perform blind Server-Side Request Forgery (SSRF) attacks through maliciously crafted XML Schema Definition (XSD) inputs.

With a CVSS v3.1 base score of 9.3, the flaw poses a serious risk to organizations running AI workloads with guardrails-based content moderation, potentially exposing cloud metadata credentials, Kubernetes API tokens, and internal service secrets.

Critical SSRF Flaw

The vulnerability, cataloged under CWE-918 (Server-Side Request Forgery), resides in how the guardrails-detectors component processes the xml-with-schema: detection feature. When a user submits input for validation, the system parses an accompanying XSD string to enforce schema compliance.

Attackers can exploit this parsing behavior by embedding external entity references or schema import directives that force the server to make outbound network requests to attacker-controlled or internal destinations.

Because the SSRF is “blind,” attackers don’t receive direct output from these requests. Instead, they infer success through timing differences, error responses, or out-of-band techniques, making detection considerably harder for defenders relying solely on response-based monitoring.

The attack surface here is unusually broad for an SSRF flaw, according to Red Hat’s advisory. Successful exploitation could grant attackers access to:

Cloud metadata service credentials (AWS IMDS, Azure Instance Metadata, GCP metadata endpoints)
Kubernetes API server tokens and internal cluster resources
Internal MinIO object storage instances used for model artifacts
Other internal network endpoints not normally reachable from outside
Local file reads, including service account tokens and pod secrets via file:// URI handling

This combination of SSRF plus local file read means an attacker doesn’t just probe internal infrastructure; they can potentially pivot to a full cluster compromise by harvesting Kubernetes service account tokens, which often carry elevated permissions within a namespace.

Per the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N), the vulnerability requires no authentication, no user interaction, and minimal attack complexity.

The “Scope: Changed” designation indicates that the vulnerability allows an attacker to affect resources beyond the vulnerable component’s security authority, specifically the internal network and metadata endpoints described above.

Confidentiality impact is rated High, while integrity impact is Low and availability is unaffected, consistent with a data-exfiltration-focused flaw rather than a denial-of-service vector.

Remediation

The vulnerability affects the rhoai/odh-fms-guardrails-orchestrator-rhel9 package within Red Hat OpenShift AI. As of this writing, Red Hat has marked the package status as “Affected,” with no errata issued yet, meaning a patched version is still pending release.

Organizations running RHOAI with guardrails-detectors enabled should:

Monitor Red Hat’s security advisory page for CVE-2026-15378 for errata updates
Restrict outbound network access from guardrails-detectors pods using NetworkPolicies
Disable or limit xml-with-schema: detector functionality until a fix ships
Rotate service account tokens and audit Kubernetes RBAC bindings tied to affected namespaces
Implement egress filtering to block requests to cloud metadata IP ranges (e.g., 169.254.169.254)

Given the severity and the sensitive nature of the exposed assets, security teams should prioritize this advisory alongside routine RHOAI patch management cycles rather than treating it as a lower-priority background item.