CVE-2026-15378: Critical OpenShift AI SSRF

Are You Affected?

CVE-2026-15378 affects the guardrails-detectors component used by Red Hat OpenShift AI (RHOAI). The attack requires no authentication or user interaction. An attacker who can reach the vulnerable service may submit malicious XSD content and cause the component to access network or local resources.

Available research identifies affected RHOAI container images, but does not provide a reliable normalized release range or universally applicable fixed version. Use the relevant Red Hat advisory and running image digest as the source of truth. Do not assume that a deployment is safe solely because it uses a particular RHOAI marketing version.

The affected image families identified in available Red Hat material include:

• odh-fms-guardrails-orchestrator-rhel9
• odh-guardrails-detector-huggingface-runtime-rhel9
• odh-kf-notebook-controller-rhel9

Examples of relevant repositories include:

• registry.redhat.io/rhoai/odh-fms-guardrails-orchestrator-rhel9
• registry.redhat.io/rhoai/odh-guardrails-detector-huggingface-runtime-rhel9
• registry.redhat.io/rhoai/odh-kf-notebook-controller-rhel9

Red Hat advisories associated with this CVE include RHSA-2026:60520, RHSA-2026:65126, and RHSA-2026:73987. The retrieved advisory material exposes updated image information but does not provide a dependable human-readable mapping between every affected release and a fixed RHOAI version.

Treat an installation as potentially affected until its running image digest is matched to the applicable Red Hat advisory.

For related identity and access context, see what is ABAC?. Organizations also reviewing broader security monitoring coverage may benefit from comparing open-source SIEM alternatives.

The Fix, If You’re in a Hurry

Identify the RHOAI release and running image digests. Then upgrade affected components to the Red Hat-provided fixed builds listed in the applicable advisory.

Because an authoritative standalone guardrails-detectors package version was not confirmed, do not try to remediate this issue by upgrading an unrelated Python package or relying on a locally cached image.

1. Inventory workloads and images

oc get pods -A -o wide

oc get pods -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGES:.spec.containers[*].image'

Identify the owning deployments or operators:

oc get deploy,statefulset,daemonset -A | grep -Ei 'guardrail|fms|notebook|odh'

Record immutable image IDs:

oc get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{"\n"}{end}{end}'

2. Apply the vendor fix

Follow the applicable Red Hat advisory and RHOAI operator procedure. Resource names vary by installation, so update the owning operator or deployment rather than assuming a universal resource name.

After updating the image or operator, monitor rollout status:

oc rollout status deployment/<deployment-name> -n <namespace>

A generic restart does not replace a vulnerable image. It can, however, ensure that updated content is running after the deployment or operator has been changed:

oc rollout restart deployment/<deployment-name> -n <namespace>

Verify immutable image digests after remediation:

oc get pods -n <namespace> \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{"\n"}{end}{end}'

Do not rely only on mutable tags.

3. Restrict egress if patching is delayed

At minimum, block detector access to:

• Cloud metadata services.
• Unnecessary Kubernetes API endpoints.
• Internal object-storage services.
• Management networks.
• Unapproved internal HTTP services.

A starting NetworkPolicy example is shown below:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-guardrails-egress
  namespace: <namespace>
spec:
  podSelector:
    matchLabels:
      app: guardrails-detector
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: <required-service-namespace>
      ports:
        - protocol: TCP
          port: 443

This policy is intentionally incomplete. Required service destinations differ by deployment. A deny-by-default policy that omits dependencies can disrupt availability, while an overly broad allowlist may leave the SSRF path exposed.

Test policy enforcement and inspect network-flow logs before treating the workaround as effective.

4. Rotate potentially exposed credentials

After containment, rotate credentials that may have been reachable from affected pods, including:

• Cloud credentials obtained through metadata services.
• Kubernetes service-account tokens.
• Secrets mounted into detector or related workloads.
• Credentials used by connected object-storage services.

Review cloud, Kubernetes, and application audit logs for suspicious use before and after rotation.

How This Vulnerability Works

The vulnerable processing path accepts attacker-controlled XSD content. XML schema processing may resolve external references or initiate network and file access on behalf of the supplied document.

In this case, the reported behavior allows a remote attacker to use the guardrails-detectors execution environment as a request origin.

The SSRF is described as blind, meaning the attacker may not receive the target response directly in the normal application response. Blind SSRF can still be dangerous because the vulnerable service may:

• Reach internal endpoints.
• Trigger side effects.
• Send requests containing credentials or attacker-selected headers.
• Probe services that are inaccessible from the public internet.

Response visibility is not required for an attacker to exploit a reachable internal service.

The second impact path is local file reading. If XML processing permits external local resources, an attacker may attempt to reference files available to the process, including Kubernetes service-account tokens and mounted pod secrets. Accessible files depend on container permissions, volume mounts, runtime configuration, and the pod’s service account.

Typical high-value targets include:

• Cloud instance metadata services and temporary credentials.
• Kubernetes API endpoints and cluster configuration.
• Internal MinIO or other object-storage services.
• /var/run/secrets/kubernetes.io/serviceaccount/token.
• Mounted application secrets and configuration files.
• Internal HTTP services reachable from the pod network.

The CVSS scope is Changed because compromise of the detector process can expose resources beyond the vulnerable component. The practical blast radius depends on pod network reachability, service-account permissions, mounted secrets, cloud identity configuration, and egress controls.

Technical Notes

The exact XSD payload used by an attacker was not provided in the available primary-source material. Defenders should not infer a specific exploit string.

The security-relevant behavior to investigate is external entity or schema resolution involving attacker-controlled input, followed by outbound requests or local file access from RHOAI detector pods.

A conceptual XML pattern that may appear in exploit attempts is:

<!DOCTYPE schema [
  <!ENTITY external SYSTEM "http://internal.example.invalid/resource">
]>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <!-- Attacker-controlled schema content -->
</xs:schema>

This is not a confirmed exploit payload for CVE-2026-15378. Use it only as a conceptual indicator when reviewing parser telemetry and application logs.

Severity, Explained

CVE-2026-15378 has a CVSS 3.1 score of 9.3, rated Critical:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Each component matters operationally:

• AV:N — Network: The attack is delivered over the network.
• AC:L — Low: No unusual conditions are required beyond reaching the vulnerable service.
• PR:N — None: The attacker does not need an account.
• UI:N — None: No victim needs to click or approve an action.
• S:C — Changed: The vulnerable component can affect resources beyond itself.
• C:H — High confidentiality impact: Cloud credentials, Kubernetes data, tokens, and secrets may be exposed.
• I:L — Low integrity impact: Retrieved credentials may enable subsequent unauthorized changes.
• A:N — None: The base score does not assign a direct availability impact.

The lack of direct availability impact does not mean low operational risk. Credential exposure can lead to unauthorized cloud access, object-storage activity, Kubernetes API actions, or lateral movement.

Actual impact varies by deployment. A tightly isolated pod with no mounted secrets and minimal cloud permissions has a smaller blast radius than a detector with broad service-account privileges and unrestricted egress.

CVSS also does not establish exploitation status. It measures technical severity under CVSS assumptions; it does not prove that exploitation has occurred in the wild.

Is CVE-2026-15378 Being Exploited?

CVE-2026-15378 was not listed in the CISA Known Exploited Vulnerabilities catalog at the time of assessment. There is therefore no CISA date-added entry, federal remediation deadline, required action, or ransomware-use flag for this CVE.

That is evidence that CISA had not cataloged confirmed exploitation. It is not proof that exploitation is impossible or absent.

No verified public proof-of-concept repository or confirmed in-the-wild exploitation campaign was identified in the reviewed sources.

The vulnerability remains attractive to attackers because its prerequisites are minimal: network reachability, no authentication, low complexity, and no user interaction.

Do not wait for KEV inclusion or a public exploit before applying Red Hat fixes. Monitor for suspicious outbound requests and credential use while remediation is in progress.