Applied-Upstream:
eca9a03dda7d4fc1faa7e5a6dac9617938cf5803
Last-Update: 2026-05-12
Reviewed-By: Étienne Mollier <emollier@debian.org>
Bug-Debian: https://bugs.debian.org/
1141411
In DCMSCU_STORAGE_BIT_PRESERVING mode, the C-STORE sub-operation
handler in handleCGETSession() built the on-disk filename from the
peer-supplied AffectedSOPInstanceUID without sanitization, allowing
a malicious C-STORE SCP to write files outside the configured
storage directory via path-separator or "../" sequences in the UID.
The DISK mode path was already sanitized (via createStorageFilename(),
fixed in commit
f06a86751 for CVE-2022-2120); this branch was missed.
The fix mirrors the same pattern (sanitize a local OFString copy) so
the request struct stays intact and the C-STORE response still echoes
the peer's original UID per protocol.
Affects all consumers of DcmSCU using DCMSCU_STORAGE_BIT_PRESERVING,
including getscu --bit-preserving.
This fixes DCMTK issue #1207.
Thanks to Abhinav Agarwal for the report and analysis.
Gbp-Pq: Name CVE-2026-50003.patch
// handle bit preserving storage mode, i.e. receive directly to disk
else if (m_storageMode == DCMSCU_STORAGE_BIT_PRESERVING)
{
+ // Sanitize SOP Instance UID before using it as part of a filename
+ // to prevent path traversal via malicious peers (see also CVE-2022-2120).
+ OFString uidForFilename = rsp.msg.CStoreRQ.AffectedSOPInstanceUID;
+ OFStandard::sanitizeFilename(uidForFilename);
OFString storageFilename;
OFStandard::combineDirAndFilename(
- storageFilename, m_storageDir, rsp.msg.CStoreRQ.AffectedSOPInstanceUID, OFTrue);
+ storageFilename, m_storageDir, uidForFilename, OFTrue);
result = handleSTORERequestFile(&pcid, storageFilename, &(rsp.msg.CStoreRQ));
if (result.good())
{