CVE-2026-15378: Guardrails-Detectors SSRF Vulnerability

CVE-2026-15378 Overview

CVE-2026-15378 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in the guardrails-detectors component. A remote, unauthenticated attacker can submit a crafted XML Schema Definition (XSD) string that forces the server to issue outbound requests. The flaw enables blind SSRF against cloud metadata services, the Kubernetes API, internal MinIO instances, and other internal network endpoints. It also allows local file reads of sensitive artifacts such as service account tokens and pod secrets.

Critical Impact
Unauthenticated attackers can exfiltrate cloud credentials, Kubernetes service account tokens, and pod secrets by coercing the guardrails-detectors service into fetching attacker-controlled or internal resources.

Affected Products

Red Hat guardrails-detectors component
Deployments integrating guardrails-detectors within Kubernetes/OpenShift clusters
Environments where guardrails-detectors accepts untrusted XSD input

Discovery Timeline

2026-07-10 - CVE-2026-15378 published to the National Vulnerability Database
2026-07-14 - Last updated in NVD database

Technical Details for CVE-2026-15378

Vulnerability Analysis

The guardrails-detectors component parses user-supplied XML Schema Definition strings without restricting external references. When the parser resolves schema locations or external entities embedded in the XSD, it initiates HTTP or file-scheme requests from the server context. Attackers weaponize this behavior to reach resources that are otherwise isolated from the public network.

Because the SSRF is blind, responses are not returned directly to the caller. Attackers infer results through timing, error differentials, or by routing internal data into attacker-controlled endpoints via URL parameters. Targets of interest include the AWS Instance Metadata Service (IMDSv1), the Kubernetes API server at https://kubernetes.default.svc, and internal object stores such as MinIO.

The vulnerability is network-reachable, requires no privileges, and needs no user interaction. The scope changes because compromised metadata credentials extend the attacker's reach beyond the vulnerable service into the surrounding cloud tenant.

Root Cause

The root cause is unsafe XSD processing that permits resolution of external schema locations and entity references from user-controlled input. The parser trusts URIs supplied inside the schema, and the application does not enforce an allowlist for outbound destinations.

Attack Vector

An attacker submits a crafted XSD document to an API endpoint of the guardrails-detectors service. The XSD embeds schemaLocation, import, or entity URIs that point at internal targets such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ or file:///var/run/secrets/kubernetes.io/serviceaccount/token. The server dereferences these URIs, and the attacker recovers data through side channels or by directing responses to a controlled host.

See the Red Hat CVE-2026-15378 Advisory and Red Hat Bug Report #2498941 for further technical details.

Detection Methods for CVE-2026-15378

Indicators of Compromise

Outbound requests from the guardrails-detectors pod to 169.254.169.254, metadata.google.internal, or metadata.azure.com
Requests from the service to kubernetes.default.svc or internal MinIO endpoints outside normal application flow
Reads of /var/run/secrets/kubernetes.io/serviceaccount/token or /var/run/secrets/ paths by the detector process
XSD payloads containing schemaLocation, xs:import, or entity references pointing to non-application hosts

Detection Strategies

Inspect application logs for XSD submissions that include external URI references and reject or quarantine them
Deploy egress monitoring on pods running guardrails-detectors and alert on connections to link-local metadata IPs
Correlate process-level file access telemetry with unusual reads of Kubernetes secret paths
Use Singularity Cloud Workload Security runtime telemetry to identify anomalous outbound calls and file reads from container workloads

Monitoring Recommendations

Forward pod network and file-access events into Singularity Data Lake for OCSF-normalized correlation across cloud and identity sources
Alert on any HTTP 200 response from cloud metadata endpoints observed from application workloads
Track Kubernetes audit logs for API calls originating from service account tokens tied to the guardrails-detectors pod

How to Mitigate CVE-2026-15378

Immediate Actions Required

Apply the Red Hat patch for guardrails-detectors as soon as it is available for your channel
Rotate any service account tokens, cloud credentials, and MinIO keys accessible from the affected pods
Restrict pod egress with a NetworkPolicy that denies traffic to 169.254.169.254/32 and other metadata endpoints
Enforce IMDSv2 on AWS to require session tokens that SSRF payloads cannot obtain

Patch Information

Refer to the Red Hat CVE-2026-15378 Advisory for fixed package versions and errata. Track the associated Red Hat Bug Report #2498941 for backport status.

Workarounds

Disable or block XSD-based detector endpoints until patched
Configure the XML parser to reject external entity resolution and remote schema locations
Deploy an egress proxy in front of the workload that allowlists only required destinations
Run the pod with a restricted service account holding no cluster-scoped permissions

bash

# Kubernetes NetworkPolicy blocking metadata and internal targets
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: guardrails-detectors-egress
spec:
  podSelector:
    matchLabels:
      app: guardrails-detectors
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32
              - 169.254.170.2/32
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16