Description

An attribute coercion is a configuration-defined rule that rewrites DICOM attributes as objects pass through the archive. A rule may name its transformation as a URI with an xslt: scheme, in which case the scheme-specific part is treated as the location of a stylesheet. The coercion processor passes that location straight to the template cache:

XSLTCoercionProcessor.java:75-77

String xsltStylesheetURI = coercion.getSchemeSpecificPart();
Templates tpls = TemplatesCache.getDefault().get(StringUtils.replaceSystemProperties(xsltStylesheetURI));
Attributes newAttrs = SAXTransformer.transform(attrs, tpls, false,

View source →

The cache compiles whatever the URI points at. There is no scheme allowlist and no restriction to a local stylesheet directory, so a remote location is fetched and compiled like a local one:

TemplatesCache.java:75-80

public Templates get(String uri) throws TransformerConfigurationException {
    Templates tpl = map.get(uri);
    if (tpl == null)
        map.put(uri, tpl = SAXTransformer.newTemplates(new StreamSource(uri)));
    return tpl;
}

View source →

Compilation goes through a single shared factory in the dcm4che library, created at its defaults and never hardened:

SAXTransformer.java:63-64

private static SAXTransformerFactory factory =
        (SAXTransformerFactory) TransformerFactory.newInstance();

View source →

FEATURE_SECURE_PROCESSING is not set, and neither ACCESS_EXTERNAL_DTD nor ACCESS_EXTERNAL_STYLESHEET is constrained. On the shipped runtime the transformer is the JDK's own XSLTC implementation, where the jdk.xml.enableExtensionFunctions property governs whether a stylesheet may call into Java. That property defaults to true on the Java version the distribution ships with, and only flipped to false in a later Java release, so on a stock installation a stylesheet reaches Java methods and through them the operating system. The document() function gives a lower bound on the same path even where extension functions are unavailable: reads of local files and requests to hosts the archive can reach but the caller cannot.

The trigger surface is wider than the configuration interface that installs the rule. A coercion fires on ordinary traffic, which means it is reached not only by a DICOMweb store but also by a read-only query, and by C-FIND or C-STORE on the DICOM port. A peer that speaks only DICOM, with no access to the HTTP interface at all, is enough to make an installed rule run.

The fix enables JAXP secure processing by default on the shared transformer factory in the dcm4che library, which disables Java extension functions, and restricts the protocols an external stylesheet may be loaded over. Because the factory is shared, the change covers every consumer of the library rather than the coercion path alone.

dcm4chee-arc-light is the DICOM archive and image manager of the dcm4che project, used by hospitals, research groups, and imaging vendors as open infrastructure for storing and exchanging medical images. We appreciate the project's long-running work on that infrastructure and the care its maintainers took over this report. We reported this finding privately to J4Care in June 2026; they responded constructively and released a fix.

Impact

Code execution in the archive process carries the archive's own access to the imaging record it holds. The process is the custodian of the stored DICOM objects and of the database that indexes them, so studies and the patient identifiers attached to them can be read, altered, or deleted, and the credentials the archive holds for its own backing services are readable in that context.

Severity is rated against the deployment the project's own documentation presents first, in which the configuration interface answers without authentication. Where the secured build is deployed instead, the configuration interface requires only the base role that the shipped low-privilege account already holds, so the chain remains reachable by any authenticated user rather than being closed.

Mitigation

Upgrade to dcm4chee-arc-light 5.35.0 or later, which enables JAXP secure processing on the XSLT path. Until upgraded, operators can reduce exposure by starting the application server with the JVM property jdk.xml.enableExtensionFunctions set to false, which stops the command-execution step without disabling attribute coercion, and by restricting the configuration and control interfaces, the DICOM port, and the LDAP configuration backend to trusted networks.

Defender's Checklist

Upgrade, or disable Java extension functions now.

5.35.0 hardens the shared transformer factory. If you cannot upgrade immediately, start the application server with jdk.xml.enableExtensionFunctions set to false. That removes the step from stylesheet to operating-system command while leaving attribute coercion working, and it is a single JVM property rather than a configuration migration.

Audit the attribute coercions currently configured.

List the coercion rules on your archive device and check every one that names an xslt: URI. A stylesheet location that is remote, or that sits outside the directory your deployment intends to serve stylesheets from, should be treated as suspect. Coercions are configuration, so they persist across restarts and survive an upgrade.

Do not rely on blocking the HTTP interface alone.

Once a rule is installed it fires on read-only queries and on raw C-FIND or C-STORE against the DICOM port. Restricting the DICOMweb interface does not prevent an already-installed rule from running; the control that matters is preventing the configuration write in the first place.

Restrict the configuration and control interfaces.

The archive provides no way to restrict its device and control resources to administrators separately from ordinary users, so the boundary has to be enforced outside the application, at a reverse proxy or on the network. The LDAP configuration backend needs the same treatment, since writing configuration there reaches the same code path.

Treat an exposed archive as having disclosed its configuration secrets.

If the configuration interface was reachable from an untrusted network, assume the credentials held in archive configuration for the database, the storage backends, and the LDAP backend are known, and rotate them.

Severity Reasoning

AV:NThe configuration interface that installs the coercion rule is an HTTP resource of the archive, and the rule then fires on network DICOM traffic.AC:LNo timing or environmental preconditions. The permissive transformer factory and the extension-function default are both stock configuration on the shipped runtime.PR:NRated against the deployment the project documents first, in which the configuration interface answers without authentication. On the secured build this becomes PR:L, giving 8.8.UI:NThe rule fires on ordinary traffic the archive already receives; no operator action is needed.S:UImpact is bounded to the archive service account and what it can reach.C:HCode execution exposes stored imaging, the index database, and the credentials the archive holds for its backing services.I:HCode execution permits modification of stored studies and the identifiers attached to them.A:HCode execution as the service account can stop the archive or delete stored data.

Remote Code Execution via XSLT Attribute-Coercion Injection

Description

Impact

Mitigation

Defender's Checklist

Severity Reasoning

References

How We Can Help

Who We Are

Dr. rer. nat. Simon Weber

Dipl.-Inf. Volker Schönefeld

Looking for a Penetration Test?