@W-23807282 - prevent command injection via server-provided redirectUrl (RCE)

[ad-shreya]

@W-23807282@

Summary

Fixes a command injection → remote code execution vulnerability in sf devops stage environment add (Hackforce report a0LKa00000IqKR2MAN).

The command opened the OAuth redirectUrl returned by the target org using exec() with the URL interpolated into a shell string:

exec(`${cmd} "${url}"`);

Because --target-org accepts an arbitrary instance URL, an attacker controlling that endpoint could return a redirectUrl such as safe" & calc.exe & rem ", breaking out of the quoted URL to execute arbitrary commands on the victim's machine. It triggered regardless of --json; only --no-browser avoided it.

Fix (defense-in-depth)

1. No shell. Switched from exec() to execFile(), passing the URL as a discrete argument so no shell can interpret it. Windows uses cmd /c start "" <url> (empty window-title arg before the URL).
2. Validate the scheme. New sanitizeRedirectUrl() parses the value with the WHATWG URL API, rejects any non-http(s) scheme (blocking javascript:, file:, and non-URL payloads like the reported one, which don't parse at all), and returns the normalized href so residual quotes/spaces are percent-encoded. Invalid input throws a friendly error.InvalidRedirectUrl instead of launching anything.

Testing

• Added regression tests: URL passed as a discrete arg; the reported safe" & calc.exe & rem " payload is rejected with no process spawned; a crafted http URL is normalized so no quote/space survives.
• Updated the existing test mock from exec to execFile.
• All 10 tests pass; yarn compile clean; yarn lint 0 errors.

🤖 Generated with Claude Code