GetDocumentInsider uses unsanitized documentName when generating output file path

[JRLK0]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Description

The GetDocumentInsider CLI tool constructs the output file path using a user-provided
documentName value.

Although a sanitized version of this value is computed internally, the final output
file name is built using the original, unsanitized input. As a result, directory
separators or traversal sequences (e.g. ../ or ..\) can influence the generated
file path.

This allows a crafted documentName value to escape the intended output directory
and cause files to be written to unintended locations.

This issue was previously reported to MSRC (VULN-168240) and was classified as a
non-serviciable security case.

---

Steps to reproduce

1. Run the GetDocumentInsider CLI tool with a specified --output directory.
2. Provide a documentName containing directory traversal sequences, such as:
   • a/../b
   • a\..\b
3. Observe that the generated output file path may be influenced by these sequences
   instead of being treated as a plain file name.

---

Expected behavior

The output file path should always be derived from a sanitized version of
documentName, with no possibility for directory traversal or subdirectory creation.

---

Actual behavior

The sanitized value is computed but not used when constructing the output file path.

---

Affected code

src/Tools/GetDocumentInsider/src/Commands/GetDocumentCommandWorker.cs
Method: GetDocumentPath(...)

---

Proposed fix

Use the sanitized document name when generating the output file path and treat
directory separators consistently across platforms.

---

Additional context

A fix and regression test have already been prepared and will be submitted in a
follow-up pull request.

Expected Behavior

The generated output file should always be created inside the specified output
directory, using a sanitized version of documentName that cannot influence the
resulting file path.

Steps To Reproduce

No separate repro project is required. The issue can be reproduced directly by
invoking the GetDocumentInsider CLI tool with a crafted documentName value, as
described above.

Exceptions (if any)

No response

.NET Version

.NET SDK version: 8.0.x

Anything else?

This issue was previously reported to MSRC (VULN-168240) and closed as non-serviciable
from a security perspective.