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.