Remote Code Execution via Storage-Descriptor File Write

A storage descriptor tells the archive where to put the objects it receives. Two of its fields decide the destination: the storage URI, which is the filesystem root, and the storage path format, a template evaluated against the attributes of the object being stored. Both are ordinary configuration. The setter for the root accepts whatever it is given, with no scheme allowlist and no containment boundary:

public void setStorageURIStr(String str) {
    this.storageURI = URI.create(StringUtils.replaceSystemProperties(str));
    this.storageURIStr = str;
}

At write time the root and the evaluated path template are joined and opened directly:

protected OutputStream openOutputStreamA(WriteContext ctx) throws IOException {
    Path path = Paths.get(rootURI.resolve(ctx.getStoragePath()));
    Path dir = path.getParent();
    createDirectories(dir);
    while (true)
        try {
            ctx.setStoragePath(rootURI.relativize(path.toUri()).toString());
            return Files.newOutputStream(path, descriptor.getFileOpenOptions());

There is nothing to traverse out of, which is why no traversal sequence appears anywhere in this finding. An attacker who can write configuration sets the root to the directory they want and the path template to the filename they want, and the archive writes there because that is what it was told to do. The path template draws on attributes of the stored object, which the same caller supplies, so the filename and its extension are controllable too.

The step from a controlled write to code execution uses the same property of the application server as the vendor-data finding covered in the related advisory: an archive appearing in the deployments directory is picked up and deployed. Getting a deployable file there takes two properties of the store path. An Encapsulated PDF object carries its document in a bulk-data attribute, and the store re-encodes the object but copies that attribute through verbatim rather than running it past an image codec, so an embedded archive survives intact; placed as the highest-numbered element, nothing follows it in the written dataset. What lands on disk is therefore the whole DICOM object, not the archive alone. That still deploys, because an archive reader locates a ZIP's central directory from the end of the file, so the DICOM preamble and the element headers ahead of the payload are tolerated as a leading prefix.

The prefix does have a cost for the attacker, and it is worth being precise about it: the application server's deployment scanner runs a completeness check that reads a prefixed file as still being copied, so the first write does not deploy on its own. Deployment follows only once a corresponding marker file tells the scanner to proceed, which the same configuration-and-store primitive can produce. The chain is two writes rather than one, which is why the attack complexity stays low without the finding being a single request.

Code execution is the ceiling rather than the whole finding. The same primitive, used without the deployment step, writes well-formed and fully readable DICOM studies to chosen locations, which is enough to place imaging in an archive that no imaging device produced. The file open options are themselves a configuration field, so switching them from the default create-if-absent to a truncating mode through the same interface turns the primitive from placing new files into overwriting existing ones.

The fix resolves each storage path against its root and rejects any result that leaves it, and it additionally refuses a storage root that lies inside the application server's own home directory outside the subtree now designated for storage. The default storage location was moved into that subtree in the same release.

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.