---
id: "CVE-2026-91858"
kind: "vulnerability"
aliases: ["CVE-2026-91858"]
title: "Apache Camel FOP: XSL-FO body can read local files via XXE"
severity: "medium"
cvss: 6.5
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["camel", "fop", "java", "package", "saxon", "self-hosted"]
not_affected_if: ["default-config", "no-saxon-on-classpath", "no-untrusted-xsl-fo-input"]
published_at: "2026-10-19T11:17:25+00:00"
first_seen_at: "2026-10-23T21:57:18+00:00"
updated_at: "2026-10-25T03:57:09+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91858", "first_seen_at": "2026-10-23T21:57:18+00:00"}]
---

# Apache Camel FOP: XSL-FO body can read local files via XXE

camel-fop transforms incoming XSL-FO bodies with a JAXP TransformerFactory that only sets FEATURE_SECURE_PROCESSING, which does not block external DTDs or entities on third-party factories such as Saxon-HE. An external sender can make the Camel process read files it can access and issue requests to hosts named in the document.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the application's classpath contains Saxon-HE or another alternative JAXP TransformerFactory, for example by running `mvn dependency:tree` and looking for `camel-saxon`, `camel-xslt-saxon` or `Saxon-HE`.
- Check whether any route feeds untrusted input into a `fop` producer endpoint.
- Check the camel version in use; releases on the 4.14.x line and earlier are end of life and receive no fix.

## Fix

- Upgrade camel-fop to a patched release on a supported line; releases on the 4.14.x line and earlier receive no fix, so move off that line.
- Remove Saxon-HE or other alternative JAXP TransformerFactory implementations from the classpath if FOP is not expected to use them.
- Unknown fixed version number: the sources do not say which release contains the fix.

## Timeline

- 2026-10-23T21:57:18+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-91858

## From the sources

FopProducer transforms the incoming XSL-FO message body by creating a javax.xml.transform.TransformerFactory through TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING before running an identity transform over the body. On the JDK's built-in transformer, that feature alone already empties the accessExternalDTD and accessExternalStylesheet limits, so an external DTD or entity is refused. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, for example because the application also uses camel-xslt-saxon or camel-saxon, TransformerFactory.newInstance() returns that implementation instead, and FEATURE_SECURE_PROCESSING on its own does not restrict external resource access on it. A DOCTYPE with an external subset, or an external general entity, declared in the XSL-FO document is then resolved and expanded while the body is transformed. An external sender whose XSL-FO reaches a fop producer could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. camel-fop does not bring such a factory itself, and excludes Xalan, so a default deployment using the JDK transformer is not affected; the issue is reachable only where another component has placed an alternative JAXP TransformerFactory on the classpath. Releases on the 4.14.x line and earlier reached end of life before this issue was resolved and do not receive a fix.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_