A flaw was found in Apicurio Registry. The DocumentBuilderAccessor correctly blocks external DTD and schema access but does not disable DOCTYPE declarations or enable FEATURE_SECURE_PROCESSING. An attacker with artifact-write permission can upload XML documents with internal entity-expansion payloads (billion-laughs variant) that cause CPU and heap exhaustion, partially mitigated by the JAXP default 64,000 entity-expansion limit.
A flaw was found in Apicurio Registry's XML parsing infrastructure. The DocumentBuilderAccessor correctly sets ACCESS_EXTERNAL_DTD="" and ACCESS_EXTERNAL_SCHEMA="" (blocking external entity fetch, so no XXE or SSRF), but does not set disallow-doctype-decl=true or FEATURE_SECURE_PROCESSING:
```java
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
// missing: factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
// missing: factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
```
This allows an attacker with artifact-write permission to upload XML documents containing internal entity-expansion payloads (billion-laughs variant) that cause exponential memory and CPU consumption. The attack is partially mitigated by the JAXP default jdk.xml.entityExpansionLimit of 64,000 entities, but repeated parallel uploads can still exhaust the registry pod's CPU and heap, degrading service for all tenants.
The same gap exists in SchemaFactoryAccessor.java which silently swallows SAXNotRecognizedException when setting security properties — if the runtime SchemaFactory implementation rejects the property, the factory runs fully unhardened.
Affected files: schema-util/xml/src/main/java/io/apicurio/registry/xml/util/DocumentBuilderAccessor.java, SchemaFactoryAccessor.java
Upstream: https://github.com/Apicurio/apicurio-registry
Remediation: Add factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) and factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true). In SchemaFactoryAccessor, fail-closed (throw) instead of swallowing the exception on property rejection.
A flaw was found in Apicurio Registry's XML parsing infrastructure. The DocumentBuilderAccessor correctly sets ACCESS_EXTERNAL_DTD="" and ACCESS_EXTERNAL_SCHEMA="" (blocking external entity fetch, so no XXE or SSRF), but does not set disallow-doctype-decl=true or FEATURE_SECURE_PROCESSING: ```java DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // missing: factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); // missing: factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); ``` This allows an attacker with artifact-write permission to upload XML documents containing internal entity-expansion payloads (billion-laughs variant) that cause exponential memory and CPU consumption. The attack is partially mitigated by the JAXP default jdk.xml.entityExpansionLimit of 64,000 entities, but repeated parallel uploads can still exhaust the registry pod's CPU and heap, degrading service for all tenants. The same gap exists in SchemaFactoryAccessor.java which silently swallows SAXNotRecognizedException when setting security properties — if the runtime SchemaFactory implementation rejects the property, the factory runs fully unhardened. Affected files: schema-util/xml/src/main/java/io/apicurio/registry/xml/util/DocumentBuilderAccessor.java, SchemaFactoryAccessor.java Upstream: https://github.com/Apicurio/apicurio-registry Remediation: Add factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) and factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true). In SchemaFactoryAccessor, fail-closed (throw) instead of swallowing the exception on property rejection.