CVE-2026-3415

This XXE vulnerability in the SchemaValidator Mediator exploits a dangerous assumption that enterprise integration middleware has encoded for years: that components named 'Validator' or 'SchemaValidator' are inherently safe because they process trusted schema definitions. They aren't. The vulnerability activates when external entity resolution gets enabled to handle schemas that legitimately reference external resources — then untrusted XML payloads route through the same parsing code path without that protection being reapplied. This is the XXE anti-pattern in its classic form, and it persists because 'validation' sounds like a security boundary when it's actually just data processing. What makes this exploitable in practice: the 'highly privileged actor' requirement. In integration middleware, the accounts that authenticate to these flows are typically service accounts or API keys with broad internal access — broad by design, not by accident. These accounts rarely receive the same privilege review as human administrators, and nobody monitors them for anomalous file reads or outbound requests. An XXE here isn't just reading one file on one server; it's reading it with an account that probably touches configuration endpoints, credential stores, and connected systems across the integration bus. The blast radius extends beyond the mediator to everything that account can reach. There's also an SSRF vector worth considering. This middleware sits between systems that legitimately communicate internally. An XXE that triggers outbound requests from this position can reach internal services that aren't internet-accessible — performing reconnaissance, harvesting credentials from internal APIs, or pivoting deeper into a network the attacker couldn't otherwise reach. For defenders: audit your SchemaValidator Mediator configurations and check whether external entity resolution is enabled. Then assume it is and work backward: identify every flow that routes untrusted XML through validation components, audit what service accounts have access to those flows, and review what those accounts can reach beyond the mediator itself. The parser likely lacks entity expansion limits — if your product exposes those controls, enable them. If it doesn't, treat this as a product-level secure default gap and escalate to the vendor. The 'certain conditions' language in the advisory is unhelpful. Treat this as: if your SchemaValidator processes any untrusted XML, you're in the conditions. The question isn't whether you were meant to — it's whether an attacker can get a service account to send you payloads you didn't intend to accept.

Reviewed through automated stages and approved by a human before publication.