CVE-2026-85250
Camel-XPath: XML external entity processing - the documentType=InputSource option handed the payload to an XPath engine that built its own parser with JDK defaults, so a DOCTYPE refused on the default document type was accepted and its external entity resolved
Description
With documentType set to InputSource, XPathBuilder handed the payload straight to javax.xml.xpath, which builds a DocumentBuilder of its own using the JDK defaults. The hardening applied to Camel's default document type was therefore bypassed: a DOCTYPE declaration that is refused on the default type was accepted here, and the external entity it declared was resolved and expanded into the evaluated document. An external sender whose XML reaches such an expression could read files readable by the Camel process and cause the process to issue requests to hosts it names. The two document types disagreeing on parser configuration is what made this reachable, since a deployment choosing InputSource for streaming reasons had no indication it was also choosing a weaker parser.
Mitigation
Credit
This issue was discovered by Claude Security Scan Tool
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24475 refers to the various commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/25683 (commit 1ead256f1bfcef36c2572a88809bcd7547bdc111), backported to camel-4.22.x in https://github.com/apache/camel/pull/25940 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb) and to camel-4.18.x in https://github.com/apache/camel/pull/25942 (commit af1efbcccf5882b1ef0094db718972da3190e7e9).
The issue is classified as CWE-611 Improper Restriction of XML External Entity Reference. The camel-4.14.x line reached end of life before this fix and does not receive it; deployments on 4.14.x should move to 4.18.5 or later.