CVE-2026-97851 in dcm4chee-arc-light
Summary
by MITRE • 10/16/2026
The storage status-change REST service allows location records still associated with DICOM instances to be changed to deletion-related states. Changing a location to TO_DELETE causes PurgeStorageScheduler to delete the referenced object from storage even though the corresponding instance record remains in the database.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
This vulnerability represents a critical integrity failure within medical imaging information systems, specifically affecting the interaction between the DICOM Storage Service and its underlying data management components. The core issue lies in the asynchronous handling of state transitions for stored objects. When an administrator or automated process invokes the storage status-change REST service to mark a location record as TO_DELETE, the system triggers the PurgeStorageScheduler to physically remove the associated file from persistent storage media. However, this action is not coupled with a corresponding update to the database records that track the DICOM instances themselves. This decoupling creates a state of inconsistency where the physical asset is destroyed while its logical metadata persists in the relational database.
The technical flaw stems from a lack of atomic transactional integrity between the storage layer and the data persistence layer. In a robust implementation, deleting an object should involve either updating both records simultaneously within a single transaction or ensuring that the deletion of the file triggers a cascade update to mark the instance record as deleted or purged in the database. Instead, the system allows the scheduler to proceed with physical removal based solely on the location status flag, ignoring the existence of active references from DICOM instances. This design oversight violates fundamental principles of data consistency and referential integrity, leading to orphaned metadata entries that point to non-existent files.
The operational impact of this vulnerability is severe for healthcare organizations relying on these systems for clinical decision-making and archival compliance. Clinicians accessing the database may encounter errors when attempting to retrieve or display images referenced by DICOM instances, as the underlying data files are missing. This can lead to interrupted workflows, delayed diagnoses, and potential patient safety risks if critical imaging studies become inaccessible during urgent care scenarios. Furthermore, this inconsistency complicates system maintenance and auditing efforts. Database administrators cannot accurately assess storage usage or identify truly orphaned records because the database believes instances still exist while they do not physically reside on disk. This discrepancy can also interfere with backup and restore procedures, potentially leading to corrupted archives if restoration attempts fail due to missing files referenced in the metadata.
From a compliance perspective, this flaw poses significant challenges for regulations such as HIPAA and GDPR which mandate accurate record-keeping and data integrity. The presence of phantom records that cannot be accessed or verified undermines the reliability of medical records. It also complicates legal discovery processes where complete and unaltered evidence is required. If an audit reveals discrepancies between database counts and actual file storage, it may indicate broader systemic issues with how data lifecycle management is handled across the platform.
To mitigate this vulnerability, developers must implement strict transactional boundaries that ensure any change to a location's status results in synchronized updates to all related DICOM instance records. This can be achieved by modifying the REST service handler or the PurgeStorageScheduler logic to first update the database state of associated instances before initiating physical file deletion. Alternatively, implementing a soft-delete mechanism where both the storage and database are marked as deleted without immediate physical removal allows for safer recovery options and ensures data consistency until final cleanup is performed during low-traffic periods. Regular integrity checks should also be introduced to detect and reconcile any existing discrepancies between stored files and their corresponding metadata records.