[jdotc1]

Fixes #129.

The CLI uses server-provided SOP Instance UIDs to form instance and metadata filenames. A parent-relative or absolute UID can currently select a path outside the requested output directory.

Add a shared path guard that requires the resolved output file's parent to be the selected directory, and use it for instance, metadata, and frame export destinations. Normal filenames and existing UID-format permissiveness are preserved. This does not claim to eliminate filesystem races or provide comprehensive filesystem security.

Validation: six focused mocked cases against the actual source save helpers and new tests loaded in isolation. Instance and JSON metadata saves each cover normal, parent-relative, and absolute values. The four escaping cases failed before the fix; all six passed afterward. No server, clinical data, codecs, real writes, full suite, or frame-export integration test was used.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[CPBridge]

Hi @jdotc1

Am I correct in understanding that the issue that this PR is trying to solve is if the server provides a UID that "breaks" the filepath formed from that UID out of the intended directory, e.g. by provided a "UID" along the lines of "../1.2.3.4"?

If so, this is not an issue that you would ever encounter unless a server is acting quite maliciously with the intention of getting you to write files outside the intended location. This then is a security precaution against a malicious server? Just trying to make sure I understand the problem you are trying to solve here. Because this is not something you would ever encounter under normal usage. No real DICOM server would ever support a UID like "../1.2.3.4"

[jdotc1]

Yes—the intended scope is hardening against an untrusted or compromised endpoint, or malformed response data that reaches the CLI. A valid SOP Instance UID should not contain a parent-relative or absolute path.

The guard keeps a UID-derived destination within the selected output directory while preserving existing UID validation behavior. It is defense in depth at the local write boundary; it does not claim to eliminate filesystem races or make an untrusted server generally safe.

I also ran the project CLI tests and the focused output-path tests with the real dependencies: 55 and 6 passed, respectively.

[jdotc1]

Thank you for considering this change and for the helpful discussion. When convenient, could you please approve the pending unit-test workflow for this PR? I appreciate your time.