Description

The DICOMweb store and workitem endpoints accept a DICOM dataset in XML form. Parsing goes through the dcm4che library's SAX reader, which builds a parser from the platform default factory and configures nothing on it:

SAXReader.java:66-74

public static Attributes parse(InputStream is, Attributes attrs)
        throws ParserConfigurationException, SAXException, IOException {
    if (attrs == null)
        attrs = new Attributes();
    SAXParserFactory f = SAXParserFactory.newInstance();
    SAXParser parser = f.newSAXParser();
    parser.parse(is, new ContentHandlerAdapter(attrs));
    return attrs;
}

View source →

disallow-doctype-decl is not set, the external general and parameter entity features are left alone, and secure processing is not enabled, so a document type declaration in the submitted body is honoured and the entities it declares are resolved by the parser as it reads.

What makes this more than a blind read is where the expansion ends up. The parser is building a DICOM dataset, so the resolved content is placed into whatever attribute the entity reference appeared in, and that dataset is then stored like any other. Because the archive serves its own stored objects back through its metadata retrieve interface, the caller reads the expanded content out of the attribute they put it in. The read and the retrieval are both ordinary DICOMweb operations.

The same position accepts a network reference instead of a file reference, in which case the archive issues the request while parsing. That reaches hosts routable from the archive but not from the caller, with the archive as the origin. Two limits are worth stating: the content has to survive XML parsing, so binary files are not recoverable this way and files containing characters that are illegal in XML may abort the parse; and the technique reads files as the archive's own service account, not as root.

The fix enables JAXP secure processing by default on the shared SAX parser factory in the dcm4che library, which stops the parser resolving external entities. As with the XSLT hardening in the same release, the change sits in the library rather than at the call sites, so it covers every consumer of the parser.

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

A text-format file readable by the archive service account can be retrieved by a caller who never authenticated, which on a stock deployment includes configuration files holding credentials for the archive's backing services in cleartext. The same mechanism reaches hosts on the internal network that the caller cannot address directly, using the archive as the origin of the request. Binary files are not recoverable this way, because the content has to survive XML parsing.

Severity is rated against the deployment the project's own documentation presents first, in which the DICOMweb endpoints answer without authentication. Where the secured build is deployed instead, those endpoints require the base role that the shipped low-privilege account already holds, so the finding remains reachable by any authenticated user at a correspondingly lower score.

Mitigation

Upgrade to dcm4chee-arc-light 5.35.0 or later, which stops external entity resolution in the shared parser. Until upgraded, operators can reduce exposure by restricting the DICOMweb endpoints to trusted networks, and should treat any credential held in configuration on an exposed archive as disclosed and rotate it.

Defender's Checklist

Upgrade, and check the library version rather than the archive version.

The fix is in the dcm4che library's shared parser factory, not at the archive's call sites. If you build the archive yourself or pin the library independently, confirm that the dcm4che core artifact actually moved, not only the archive release.

Rotate credentials held in archive configuration.

On a stock deployment the readable set includes the configuration holding database, storage backend, and LDAP credentials in cleartext. If the DICOMweb endpoints were reachable from an untrusted network on an affected version, treat those as disclosed and rotate them.

Do not rely on egress filtering as the control.

The network variant of this finding is a useful signal but not the main risk. The file read returns in band through the archive's own retrieve interface, so it needs no outbound connection at all and blocking egress does not affect it.

Check what else consumes the shared parser.

The permissive factory sat in the dcm4che library, so the exposure was not limited to the DICOMweb path. If you run other software built on the same library, confirm it picked up the hardened version too.

Severity Reasoning

AV:NThe DICOMweb store and workitem endpoints that accept the XML body are HTTP resources of the archive.AC:LNo timing or environmental preconditions. The parser defaults that permit entity resolution are stock.PR:NRated against the deployment the project documents first, in which the DICOMweb endpoints answer without authentication. On the secured build this becomes PR:L, giving 6.5.UI:NBoth the store and the retrieval that reads the content back are issued by the attacker.S:UImpact is bounded to what the archive service account can read and to the hosts the archive can reach.C:HText-format files readable by the service account are returned in band, which on a stock deployment includes configuration holding credentials for the backing services.I:NThe technique reads; it does not modify the archive's own data. The stored carrier object is attacker-supplied to begin with.A:NNo availability impact.

XML External Entity Injection via DICOMweb Metadata

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?