dcm4chee-arc-light
Remote Code Execution via Storage-Descriptor File Write
A storage location defines where the archive writes the objects it receives. Both its filesystem root and its path template are configuration-controlled, and neither was validated against a scheme allowlist nor against a containment boundary, so configuration alone determined the destination of a stored object. An attacker able to write archive configuration can point a storage location at a directory the application server watches for deployments and then store an ordinary DICOM object whose payload is a deployable web application, which the server picks up and runs as the archive service account.
This advisory contains limited information during coordinated disclosure. Please check back later for full details.
Description
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.
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. This is a coordinated disclosure; the full technical writeup follows once the remediation window closes.
Impact
- Code execution in the archive process carries the archive's own access to the imaging record it holds, so stored studies and the patient identifiers attached to them can be read, altered, or deleted. Independently of code execution, the same write primitive places well-formed studies at chosen locations, so an archive can be made to hold and later serve imaging that no imaging device produced. What that means clinically depends on how the receiving organisation uses the archive, and is for that organisation to assess.
- 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 contains each storage path within its root and refuses a storage root inside the application server home. Until upgraded, operators can reduce exposure by restricting the configuration and control interfaces and the LDAP configuration backend to trusted networks, and by reviewing the configured storage locations against the paths the deployment actually intends to use.
References
How We Can Help
Who We Are
The security researchers behind this advisory.
Dr. rer. nat. Simon Weber
Senior Pentester & MedSec Researcher
I evaluate your SaMD with the same industry-defining security insight I contributed to the BAK MV for the revision of the B3S standard.
- PhD on Hospital Cybersecurity
- Critical vulnerabilities found in hospital systems
- Alumni of THB MedSec Research Group
- gematik Security Hero
Dipl.-Inf. Volker Schönefeld
Senior Application Security Expert
As a former CTO and developer turned pentester, I work alongside your team to uncover vulnerabilities and find solutions that fit your architecture.
- 20+ years as CTO, 50M+ app downloads
- Architected and secured large-scale IoT fleets
- Certified Web Exploitation Specialist
- gematik Security Hero
Looking for a Penetration Test?
Machine Spirits specializes in security assessments for medical devices and healthcare IT. From MDR penetration testing to C5 cloud compliance, we help MedTech companies meet regulatory requirements.