CVE-2026-90885
Camel-Saxon: XML external entity processing - XQueryBuilder parsed a message body that was already a javax.xml.transform.Source with Saxon's default parser settings, so an external entity declared in that body was resolved
Description
XQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel's own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.
Mitigation
Credit
This issue was discovered by Leon Zlobecki
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24691 refers to the commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/26344 (commit 9c23b6868bb92cb19c2b5a7ee624421d760cda8f), and backported to camel-4.22.x in https://github.com/apache/camel/pull/26728 (commit 0d0ed8bbe38fdae6e778c4f719e80c2e2d0e51b2) and to camel-4.18.x in https://github.com/apache/camel/pull/26730 (commit ed513f3a7117c3343a9e31e22e5627498f2fcdb6).
XQueryBuilder now builds its default Saxon Configuration with parse options that enable the disallow-doctype-decl parser feature and disable the external-general-entities, external-parameter-entities and load-external-dtd features. This aligns a body that is already a Source with the hardened parser configuration that Camel’s XmlConverter applies to String, byte[] and InputStream bodies. The change is visible and is recorded in the 4.23 upgrade guide: a body that reaches XQuery as an already-built Source and carries a DOCTYPE declaration is now rejected with a parse error, while bodies without a DOCTYPE are unaffected. Only the default Configuration is hardened. A Configuration supplied through the configuration option of the xquery endpoint or language, or through XQueryBuilder.setConfiguration, is used as is and is not modified, so a deployment that genuinely needs DOCTYPE or external entity processing can keep it, while a deployment that supplies its own Configuration for any other reason needs to apply the same parse options itself.
The code path predates Apache Camel 4.0 and was already present in the 2.x and 3.x releases, so the affected range starts at 4.0.0 and every release line up to the fixed releases carries the issue. The 4.14.x line and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x lines, reached end of life before the fix and do not receive it. On the 4.22.x line the fix was backported after 4.22.1 had been cut, so 4.22.1 is affected and 4.22.2 is the first fixed release of that line.
This issue is distinct from CVE-2026-85250, which concerned the documentType=InputSource option of camel-xpath and was fixed in 4.18.5, 4.22.1 and 4.23.0. Both concerned an input path that bypassed the parser hardening applied by default, but they are in different components and the fix for one does not cover the other; in particular, 4.22.1 resolves CVE-2026-85250 but not this issue. It is classified as CWE-611 (Improper Restriction of XML External Entity Reference).