Hi all,

Given the recent surge in low-quality XXE security reports on the one
hand, and the emergence of CVEs such as CVE-2025-54988 in Apache Tika
on the other [1], I would like to propose a new Apache Commons project:

Commons JAXP

The initial scope would be deliberately narrow: to provide builders
that securely configure, in an implementation-independent manner, the
following Java API for XML Processing (JAXP) factories:

- DocumentBuilderFactory (DOM)
- SAXParserFactory (SAX)
- XMLInputFactory (StAX)
- TransformerFactory (TraX)
- XPathFactory (XPath)

It seems unreasonable that in 2025 developers are still expected to
manually apply the same sets of configuration flags copied from
cheat sheets (such as OWASP [2]), which have effectively been outdated
for more than a decade.

In 2013, JEP 185 [3] introduced a set of system properties that define
the allowlist of protocols JAXP implementations may use to retrieve
external resources. For the default JDK implementations, these lists
are effectively empty for DOM and SAX (and, somewhat unexpectedly,
set to "all" for StAX).

However, introducing an older or alternative JAXP implementation on
the classpath (for example, Xerces) bypasses these safeguards and
reintroduces the very issues developers believe they are protected
against.

A small, focused library could address this by:

- Eliminating widespread duplication of JAXP hardening code across
  countless libraries and applications.
- Providing a single, well-understood location for handling XXE
  concerns, so that any future reports are directed at Commons JAXP
  rather than hundreds of downstream projects.

What do you think?

Piotr

[1] https://www.cve.org/CVERecord?id=CVE-2025-54988
[2]
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java
[3] https://openjdk.org/jeps/185

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to