Apache Camel EUVD-2026-109959

Exploitation requires that an XQuery expression or the xquery component/language evaluate a message body that is already a javax.xml.transform.Source AND that the Source is stream-based (so Saxon must parse it itself). This arises when a route calls convertBodyTo(Source.class), or when an earlier component/processor sets the body to a stream-based Source, before XQuery evaluation. The attacker must get untrusted XML containing a DOCTYPE with an external subset or an external entity onto that path. What LIMITS exploitation: bodies of type String, byte[], or InputStream are NOT vulnerable because Camel's XML type converters build a hardened, external-entity-safe Source for them; a route that does not convert to or set a Source body is not exposed; and only Apache Camel 4.0.0-4.18.4 and 4.19.0-4.22.1 are affected. No non-default Saxon option is required - the vulnerable default Configuration is used whenever the route does not supply its own.

This is a CWE-611 XML External Entity flaw in Apache Camel's camel-saxon XQuery support, scored CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) with confidentiality-only impact. The network, no-privilege, no-interaction vector reflects that an external sender's XML can reach the vulnerable parser, but the signals must be read together: the vuln.today priority is 'this_week' (not act_now/emergency), no EPSS score and no CISA KEV entry were provided, and no public exploit is listed - so there is no evidence of active or widespread exploitation, and this is a prioritized-but-not-emergency patching item rather than a drop-everything event. Critically, the CVSS PR:N/UI:N vector overstates real-world reachability: exploitation does not fire against a default standalone deployment but only when a route evaluates XQuery over a message body that is ALREADY a stream-based javax.xml.transform.Source (e.g. after convertBodyTo(Source.class) or when an upstream processor set a Source body). String, byte[] and InputStream bodies are NOT affected because Camel's XmlConverter hardens those paths - this materially narrows the attack surface to specific route designs, a nuance the raw score does not capture. Where that route condition holds, impact is genuine (arbitrary local file read limited to files readable by the Camel process, plus SSRF to attacker-named hosts).

An external party submits XML to an Apache Camel route that converts the message body to a javax.xml.transform.Source and evaluates it with the XQuery language or xquery endpoint. The XML carries a DOCTYPE with an external entity (e.g. SYSTEM "file:///etc/passwd" or a http:// URL); Saxon's default, unhardened Configuration resolves and expands it, leaking the file's contents into the evaluated document or forcing the process to connect to an attacker-chosen host. No public exploit is identified at time of analysis, though the fix PR (apache/camel#26344) includes a regression test with a working XXE canary payload demonstrating the issue.