Camel Quarkus XXE is CVE-2026-88789
Apache disclosed CVE-2026-88789 in Camel Quarkus: the Xalan-backed XSLT support factory drops JAXP external-access hardening, enabling XXE that can read local files or reach internal hosts. CVSS 3.1 8.6 from Apache. Fixed in 3.33.3 and 3.40.0. A public reproducer exists. Not in CISA KEV.
Published 5 Oct 2026
What happened
On 1 October 2026 Apache published CVE-2026-88789 for Apache Camel Quarkus. James Netherton posted the same text to oss-security that day. The Camel security page titles the issue as a forced Xalan TransformerFactory that drops upstream external-DTD and stylesheet hardening. Apache rates it High and publishes CVSS 3.1 score 8.6 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N. The weakness is CWE-611.
The vulnerable piece is the Camel Quarkus extension camel-quarkus-support-xalan. It hands the xslt component a Xalan-backed TransformerFactory and also registers that factory as the JAXP default. Because Xalan-J 2.7.x does not honour the ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_STYLESHEET attributes, Camel’s intended external-access restrictions never took effect.
Who is affected
Apache names Camel Quarkus from 3.2.0 before 3.33.3, and from 3.34.0 before 3.40.0. Applications become in scope when they use camel-quarkus-xslt, camel-quarkus-xslt-saxon, camel-quarkus-tika, or camel-quarkus-xmlsecurity, because each of those brings the XSLT support extension onto the classpath. For camel-quarkus-xslt, the xslt path is exposed when a message body already arrives as a javax.xml.transform.Source. Bodies Camel itself converts from String, byte[], or InputStream into a SAXSource with external entities disabled are outside that path. For the other three extensions, Apache says exposure is limited to the JAXP default factory, since they do not perform XSLT transformations themselves.
Plain Apache Camel and Camel Spring Boot are outside this CVE according to the public reproducer’s own description: they use the JDK TransformerFactory, which honours the attributes. The advisory is Camel Quarkus only.
What is confirmed
NVD published the record on 1 October 2026 with vulnStatus Deferred and carries Apache’s 8.6 score as a Secondary metric from security@apache.org. GitHub Security Advisory GHSA-w8wc-5pf9-6ph5 mirrors the same score, vector, and CWE-611. Fixed releases are 3.33.3 on the 3.33.x LTS line and 3.40.0. CISA’s KEV catalog does not list the CVE, and CISA’s SSVC options for it set exploitation to none.
A public repository owned by GitHub user oscerd (Andrea Cosentino) is titled as a reproducer for CVE-2026-88789 against Camel Quarkus. The account’s public bio identifies the owner as an Apache Camel contributor and Apache Member. The repository README states it demonstrates local-file read and internal-network reachability through the vulnerable factory. That sets availability to PoC. ThreatWire did not run the project and does not reprint payloads or commands.
What is not confirmed
Neither Apache nor CISA reports exploitation in the wild. The social claim of a generic “unauthenticated attacker” matches Apache’s CVSS privileges-required value of None, but the advisory’s concrete condition is an attacker who supplies the XML document being transformed, or other application code that obtains TransformerFactory.newInstance() while the Xalan factory is the JAXP default. That is not the same as every Camel Quarkus deployment being remotely reachable without further conditions. Headline shorthand that lists the four extensions as equally transforming XML is incomplete: only camel-quarkus-xslt performs XSLT itself; the others mainly pull the support extension onto the classpath.
What to do
Upgrade Apache Camel Quarkus to 3.40.0, or to 3.33.3 if remaining on the 3.33.x LTS stream. Until an upgrade lands, Apache’s workaround is not to pass a javax.xml.transform.Source built from untrusted input into an xslt endpoint; leave the body as String, byte[], or InputStream so Camel converts it to a hardened SAXSource. Converting an existing Source with convertBodyTo is not a workaround. Code that needs JAXP external-access restrictions should request the JDK TransformerFactory implementation explicitly rather than calling TransformerFactory.newInstance() while the Xalan factory is registered.
Sources: the Apache Camel advisory for CVE-2026-88789, the 1 October 2026 oss-security post, NVD, CVE.org, GHSA-w8wc-5pf9-6ph5, camel-quarkus issue 9115, and the oscerd reproducer repository.