Make XML parsing and validation resilient to outdated XML parsers on the classpath

[patbaumgartner]

Related to CycloneDX/cyclonedx-gradle-plugin#349

Problem

When an outdated XML parser such as Xerces 2.x leaks onto the classpath (pulled in transitively by another library or Gradle plugin), the JAXP lookup mechanism (SchemaFactory.newInstance / DocumentBuilderFactory.newInstance) picks it up, and BOM parsing/validation fails hard:

SAXNotRecognizedException: Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.

These parsers pre-date the JAXP 1.5 secure-processing properties. This is what breaks cyclonedxBom in CycloneDX/cyclonedx-gradle-plugin#349 whenever any other plugin ships Xerces on the buildscript classpath - reproducible with a plain Gradle 8.4 project, the current gradle plugin 3.3.0, and xerces:xercesImpl:2.12.2 added to the buildscript classpath.

Fix

• new XmlFactoryUtils prefers the JDK's built-in SchemaFactory / DocumentBuilderFactory via newDefaultInstance(), bypassing the classpath-based JAXP lookup. An implementation explicitly requested via the JAXP system properties is still honored - only the accidental classpath/ServiceLoader leak is bypassed. newDefaultInstance() only exists since Java 9 while this library targets Java 8, so it is invoked reflectively with a fallback to the standard lookup
• used in the three affected sites: CycloneDxSchema.getXmlSchema, XmlParser.createSecureDocument, BomXmlGenerator.buildSecureDocumentBuilder

XXE compensations when an outdated parser is chosen (review feedback)

Secure processing alone does not prevent XXE in Xerces 2.x, so when the JAXP 1.5 ACCESS_EXTERNAL_DTD/ACCESS_EXTERNAL_SCHEMA properties are unsupported the code now compensates instead of continuing insecurely:

• CycloneDxSchema.getXmlSchema and XmlParser.createSecureDocument set http://apache.org/xml/features/disallow-doctype-decl as a fallback; if that is unsupported too, the exception propagates (fail-secure)
• Xerces accepts disallow-doctype-decl on XMLSchemaFactory but does not propagate it to Validator instances (XMLSchemaValidatorComponentManager hardcodes it to false), leaving validation of untrusted input XXE-vulnerable. XmlParser.validate therefore probes the Validator for the JAXP 1.5 properties and, when unsupported, wraps the input in a SAXSource backed by a hardened XMLReader - validation stays fully streaming, and SAXSource inputs are re-wrapped the same way (DOMSource/StAXSource carry pre-parsed content and pass through)

Regression coverage

CI runs on Java 17/21/25 where newDefaultInstance() always succeeds, so a leaked Xerces would never be instantiated by the tests. The new XercesFallbackTest forces real Xerces 2.12.2 factories via the explicit JAXP system properties (guarded by an assertion that the factories actually are Xerces) and verifies on every CI JVM:

• parse, validate, and generate of a valid BOM keep working
• the XXE payload (security/xxe-protection.xml) is rejected with DOCTYPE is disallowed on both the parse and the validate path

Verification

• mvn clean verify green (1620 tests, 0 failures)
• reproducer for the gradle plugin scenario: Gradle 8.4 + plugin 3.3.0 + xercesImpl on the buildscript classpath fails with Error whilst validating XML BOM / SAXNotRecognizedException today; with this fix in core-java, validation uses the JDK parser and is unaffected

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 23 complexity

Metric	Results
Complexity	23

View in Codacy

🟢 Coverage 82.69% diff coverage · +0.02% coverage variation

Metric	Results
Coverage variation	✅ +0.02% coverage variation
Diff coverage	✅ 82.69% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (65c2eee)	Report Missing	Report Missing	Report Missing
Head commit (af3ad2e)	7751 (+43)	5799 (+34)	74.82% (+0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#894)	52	43	82.69%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}