| … | … | @@ -514,26 +514,35 @@ const resolveEditorLaunch = Effect.fn("resolveEditorLaunch")(function* ( | |
| 519 | + | return { | |
| 520 | + | ...powerShellFileManagerLaunch( | |
| 521 | + | input.cwd, | |
| 522 | + | `Invoke-Item -LiteralPath ${escapePowerShellStringLiteral(normalizeWindowsFileManagerPath(input.cwd))}`, | |
🟠 High process/externalLauncher.ts:522
Opening a Windows folder whose name contains ’ can execute commands embedded in that name, causing arbitrary PowerShell commands to run. escapePowerShellStringLiteral escapes only ASCII ', but PowerShell 5.1 also treats ’ as a string delimiter, and this path is interpolated into executable source; encode the path as data or escape all PowerShell string delimiters.
🤖 Copy this AI Prompt to have your agent fix this:
| 1 | In file @apps/server/src/process/externalLauncher.ts around line 522: |
| 2 | |
| 3 | Opening a Windows folder whose name contains `’` can execute commands embedded in that name, causing arbitrary PowerShell commands to run. `escapePowerShellStringLiteral` escapes only ASCII `'`, but PowerShell 5.1 also treats `’` as a string delimiter, and this path is interpolated into executable source; encode the path as data or escape all PowerShell string delimiters. |
Confirmed on Windows PowerShell 5.1: the added regression failed with typographic apostrophes in the folder name. Updated the shared literal helper to double all PowerShell single-quote delimiters (ASCII plus U+2018 through U+201B). The Windows test now executes the generated source with a stub shell handler and verifies the exact path, including each typographic delimiter and harmless command-like text, arrives unchanged. UTF-8 output is explicit so Windows console encoding cannot conceal a path change. The focused tests and check:changed validation pass with this correction.
Sorry, I'm unable to act on this request because you do not have permissions within this repository.