I recently reimplemented JSON logic extending it to handle XML and other formats and I learned from Cursor when I asked it, if it saw any vulnerabilities how many holes I left open regarding XML handling.
So as for one, I agree and happy to participate. Peter Verhas [email protected] t: +41791542095 On Thu, 18 Dec 2025 at 14:59, Gary Gregory <[email protected]> wrote: > What's the target Java platform? > > Gary > > On Thu, Dec 18, 2025, 08:55 Gary Gregory <[email protected]> wrote: > > > I'm all for it. > > > > Gary > > > > On Thu, Dec 18, 2025, 08:35 Piotr P. Karwasz <[email protected]> > > wrote: > > > >> 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] > >> > >> >
