CVE-2026-127031: SSRF
In Eclipse AAS4J before 3.0.1, XmlSchemaValidator.validateSchema() (and AASXValidator.validateSchema(), which calls it) validates untrusted XML with a default JAXP Validator that resolves external DTDs and external entities. An attacker who supplies a crafted AAS XML document or AASX package can read local files from the host, send their contents out-of-band to an attacker-controlled server, and make the validating process send arbitrary outbound requests (SSRF). Validation still returns no errors.
Details:
- Vulnerable code: dataformat-xml/src/main/java/org/eclipse/digitaltwin/aas4j/v3/dataformat/xml/XmlSchemaValidator.java. schema.newValidator().validate(new StreamSource(...)) runs without ACCESSEXTERNALDTD / ACCESSEXTERNALSCHEMA restrictions and without disallow-doctype-decl.
- Second entry point: dataformat-aasx/src/main/java/org/eclipse/digitaltwin/aas4j/v3/dataformat/aasx/AASXValidator.java. The AAS XML part of an .aasx package is passed unchanged to the vulnerable validator.
- XmlDeserializer (Jackson/Woodstox) is not affected, because DTD support is disabled by default there.
- Present since the initial import of the code base (commit cc9da52).
- Fix: harden the validator by setting ACCESSEXTERNALDTD and ACCESSEXTERNALSCHEMA to "" and rejecting DOCTYPE declarations. The bundled AAS.xsd does not need DTDs, so no functionality is lost.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Set both JAXP external-access properties to the empty string when creating the validator.
AAS4J XmlSchemaValidator (including AASXValidator) ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA = "" - Configuration
Reject DOCTYPE declarations during XML validation.
AAS4J XmlSchemaValidator (including AASXValidator) disallow-doctype-decl = true
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using Eclipse AAS4J versions before 3.0.1 are exposed when they validate attacker-controlled AAS XML through XmlSchemaValidator.validateSchema() or validate attacker-controlled AASX packages through AASXValidator.validateSchema(). The AASX validator passes the package's AAS XML content to the affected XML validator unchanged.
What does an attacker need to exploit this issue?
An attacker needs to be able to supply a crafted AAS XML document or AASX package that reaches one of the affected validation methods. The supplied data can cause external entity or DTD resolution without requiring attacker authentication or user interaction.
Is ordinary AAS XML deserialization affected?
No. XmlDeserializer, which uses Jackson/Woodstox, is not affected because DTD support is disabled by default there. The exposure is specific to schema validation through the affected validator methods.
Are default validator settings affected?
Yes. The affected code creates a default JAXP Validator without restrictions on external DTDs or external schemas and without disabling DOCTYPE declarations. Validation can still report no errors after the external resolution occurs.
How can I identify affected use in an application?
Check whether the application uses an AAS4J version before 3.0.1 and calls XmlSchemaValidator.validateSchema() or AASXValidator.validateSchema() on untrusted input. The relevant XML validator implementation is in dataformat-xml/src/main/java/org/eclipse/digitaltwin/aas4j/v3/dataformat/xml/XmlSchemaValidator.java.