Sanitize ScriptArguments in AzurePowerShellV2-V5 and ServiceFabricPowerShellV1 (MSRC 115118)

[wawanawna]

Context

The PowerShell-runner task family appended the YAML-supplied ScriptArguments input directly into a generated PowerShell command (& '<scriptPath>' $scriptArguments / . '<scriptPath>' $scriptArguments) without sanitization. A YAML template-parameter splice containing shell metacharacters (;, |, &, ``, etc.) would be parsed by PowerShell as additional statements and executed under the service connection's identity. This is the same class of injection that motivated the original work item #75787 and that has been progressively retrofitted across the repo:

Task family	Retrofit PR
AzureFileCopyV1-V5, WindowsMachineFileCopyV1-V2	#18646 (2023-07-21)
PowerShellV2, BashV3, SshV0	#18744 (2023-08-04)
PowerShellV2 (moved onto common Sanitizer)	#19183 (2023-11-08)
SqlAzureDacpacDeploymentV1, SqlDacpacDeploymentOnMachineGroupV0	#21947 (2026-04-16)
PowerShellOnTargetMachinesV3	#21968 (2026-04-15)
AzureCLIV2, AzureCLIV3	#22066 (2026-04-28)

The PowerShell-flavored sister tasks that had not been retrofitted were AzurePowerShellV2-V5 and ServiceFabricPowerShellV1. This PR closes that gap.

Related: ICM 31000000596029, MSRC case 115118 (resolved as Duplicate; this PR is the proper code-level remediation in the line of #18646 / #18744 / #22066).

---

Task Names

AzurePowerShellV2, AzurePowerShellV3, AzurePowerShellV4, AzurePowerShellV5, ServiceFabricPowerShellV1, plus a new helper file in Tasks/Common/Sanitizer/.

• AzureCloudPowerShellDeploymentV1 - deprecated: true in task.json.
• AzureCloudPowerShellDeploymentV2 - deprecated: true and preview; no ScriptArguments concat sink.
• PowerShellOnTargetMachinesV2 - deprecated: true (PowerShellOnTargetMachinesV3 fixed in Fix security issue for PowerShellOnTargetMachines@3 #21968).
• ChefKnifeV1 - deprecated: true, removal date 2024-01-31 in task.json.
• AzureCLIV1 - deprecated: true, explicitly skipped in feat(AzureCLI): Implement security enhancements for scriptArguments validation #22066.
• ServiceFabricDeployV1 - uses its own SfSafeParser feature-flagged safe parser instead of Invoke-Expression.
• AzureVmssDeploymentV{0,1}/Resources/customScriptInvoker.ps1 - by design runs customer-supplied script on the target VM (the customer is the script author, not a third-party injecting into a YAML splice).

AzurePowerShellV1 and ServiceFabricPowerShellV2 do not exist in any branch of the repo.

---

Description

Two-flag rollout, mirroring PR #21947's Should-UseSanitizedArguments pattern (and #22066's EnableAzureCliArgsValidation pattern). Sanitization fires only when BOTH:

1. Org-level - the existing "Enable shell tasks arguments validation" toggle (Org/Project Settings -> Pipelines -> Settings), which sets the AZP_75787_* env triplet on the agent. Surfaced via Get-SanitizerCallStatus in the existing Tasks/Common/Sanitizer module.
2. Per-task pipeline - a new pipeline feature flag, queried via Get-VstsPipelineFeature:
   • EnableAzurePowerShellArgumentsSanitization - shared across AzurePowerShellV2-V5.
   • EnableServiceFabricPowerShellArgumentsSanitization - ServiceFabricPowerShellV1.

This means a customer who has the org toggle on today (e.g. because they enabled it for the PowerShellV2 fix) will not see any behavior change on these newly-onboarded tasks until Microsoft turns on the per-task pipeline flag, preventing accidental regression. The same rollout model was used by #21947 and #22066.

New shared helper - Tasks/Common/Sanitizer/Invoke-ScriptArgumentSanitization.ps1 (sourced from Sanitizer.psm1 and exported). Three functions:

• Test-ShouldUseSanitizer -TaskName <name> -PipelineFeatureFlagName <name> - combined check, emits FF-check failure telemetry like PR Prevent security exploit in SqlAzureDacpacDeploymentV1 and SqlDacpacDeploymentOnMachineGroupV0 where Invoke-Expression is used #21947.
• Invoke-ScriptArgumentSanitization -InputArgs <args> -TaskName <name> -PipelineFeatureFlagName <name> - single-call wrapper around Protect-ScriptArguments + try/catch.
• Publish-SanitizerErrorTelemetry - small ##vso[telemetry.publish] emitter shared by both.

Fail-closed dispatch (deliberate divergence from PowerShellV2's PS port): Invoke-ScriptArgumentSanitization treats any exception out of Protect-ScriptArguments as a sanitization failure and aborts the task with the task-localized ScriptArgsSanitized message. We deliberately do not compare .Exception.Message against Get-VstsLocString -Key 'ScriptArgsSanitized' to distinguish "rejection" from "unexpected error":

• The Sanitizer module throws Get-VstsLocString -Key 'PS_ScriptArgsSanitized' (its own resjson key) while the task resjson uses key ScriptArgsSanitized. The two strings are translated independently. fr-FR already diverges today: coche vs backtick. An -eq comparison on a French agent would let a real sanitizer rejection fall into the "swallow into telemetry" branch and bypass the gate.
• Even on an unrelated sanitizer crash, executing the un-vetted args is exactly the vulnerability we are guarding against. Failing closed is the safer default.

This is a divergence from the inline catch blocks in PowerShellV2 / SqlAzureDacpacDeploymentV1 / AzureCLIV2 (which compare to Get-VstsLocString); those task-specific implementations carry the same latent locale-drift bug but ship in TypeScript / inline PS where it has been masked by en-US-identical strings. The new shared helper fixes it once.

Per-task collapse - each task entry script went from a ~25-line inline try/catch + local Publish-Telemetry helper to:

powershell if ($scriptType -ne "InlineScript") { Invoke-ScriptArgumentSanitization
-InputArgs $scriptArguments -TaskName 'AzurePowerShellV5'
-PipelineFeatureFlagName 'EnableAzurePowerShellArgumentsSanitization'
}
`

Per task, the change set is still the proven PowerShellV2-style retrofit:

1. make.json adds ../Common/Sanitizer to the common array.

2. The entry script imports the module and calls the shared helper right after the existing [\r\n] newline check, only when -ne "InlineScript".

3. task.json / task.loc.json patch-bumped (post-rebase against current master):

   Task	master	PR
   AzurePowerShellV2	2.274.0	2.274.2
   AzurePowerShellV3	3.274.0	3.274.2
   AzurePowerShellV4	4.274.2	4.274.6 (Default), 4.274.7 (Node24_1)
   AzurePowerShellV5	5.274.4	5.274.6 (Default), 5.274.7 (Node24_1)
   ServiceFabricPowerShellV1	1.228.0	1.228.2

   Patch-number gaps (V4: +4, V5: +2 from current master Default) are intentional - they reserve headroom for currently open in-flight PRs (Update package dependencies and fix security vulnerabilities #22058 Update package dependencies and fix security vulnerabilities is still based on older V4/V5 patches and is expected to land first).

4. task.loc.json.messages adds "ScriptArgsSanitized": "ms-resource:loc.messages.ScriptArgsSanitized".

5. All ten locale Strings/resources.resjson/<locale>/resources.resjson files add the new loc.messages.ScriptArgsSanitized entry, copying the already-translated text from PowerShellV2.

6. _generated/AzurePowerShellV{4,5}{,_Node24} mirrors the source changes and _buildConfigMapping / *.versionmap.txt are kept consistent (Default = master patch, Node24_1 = Default+1).

InlineScript and ScriptPath are intentionally not sanitized: inline scripts are author-written; the path is not shell-spliced (it goes through '' quoting).

---

Risk Assessment - Low

• Dual-flag rollout removes the only realistic regression vector. Org-level FF off -> no-op. Org on + per-task off -> no-op (this is the protective bit for customers who already enabled the org toggle). Both on -> enforce.
• Test-ShouldUseSanitizer falls open (returns False) on cmdlet-missing or FF-check error and emits diagnostic telemetry - never a hard failure on the FF query path itself.
• Allowlist regex and FF semantics are reused verbatim from the shipped Tasks/Common/Sanitizer module (no new sanitization code).
• Verified manually by sourcing Sanitizer.psm1 and running five scenarios:
  1. Org off -> no-op even with malicious args.
  2. Org on, pipeline off -> no-op even with malicious args.
  3. Both on + malicious args -> throws with the localized ScriptArgsSanitized message.
  4. Both on + clean args -> returns.
  5. Get-VstsPipelineFeature missing -> no-op, emits cmdletMissing telemetry.
• Locale-drift regression test included.

---

Documentation changes required: Y

The Learn topic at https://learn.microsoft.com/azure/devops/pipelines/security/inputs#enable-shell-tasks-arguments-validation has not been updated since the 2023 retrofit and is missing the four subsequent retrofits (#21947, #21968, #22066, this PR). Companion docs PR: MicrosoftDocs/azure-devops-docs#14371.

Added unit tests: Y

Tasks/Common/Sanitizer/Tests/L0Invoke-ScriptArgumentSanitization.ps1 covers the new dispatcher across six gating branches, fail-closed behaviour, and locale-drift regression. Registered in Tasks/Common/Sanitizer/Tests/L0.ts. The existing Tasks/Common/Sanitizer/Tests/L0* suite continues to cover the underlying regex/throw/audit/telemetry FF behaviour and bash/cmd/PowerShell format-compatibility.

Attached related issue: ICM 31000000596029, MSRC 115118, AB#75787

Checklist

• Task versions bumped per instructions.
• Patch-number gaps verified against current open PR queue; no collisions.
• Changes apply only when both feature flags are enabled.
• L0 test infrastructure unaffected (Register-Mock Import-Module in Tests/lib/Initialize-Test.ps1 neutralizes the new import; the helper falls open through the FF gate when Get-VstsPipelineFeature is unavailable).
• _generated/ regenerated for the two tasks that have generated mirrors (V4, V5).
• Shared helper passes 5/5 manual end-to-end smoke scenarios + 14 automated L0 assertions.
• Rebased onto current master, _generated/ and versionmaps re-validated.
• Server-side prerequisite (NOT in this PR): register EnableAzurePowerShellArgumentsSanitization and EnableServiceFabricPowerShellArgumentsSanitization in Tools.PipelineFeatures (mseng/AzureDevOps) with default off. Without this, the PR is a permanent no-op.
• Independent review by MSRC-75787 / Tasks/Common/Sanitizer owners requested before merge.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[wawanawna]

@nemanjarogic could you trigger CI with /azp run when you have a moment? Since this PR is from a fork branch (wawanawna/azure-pipelines-tasks), the Azure Pipelines / CodeQL / SDL checks don't auto-run for security reasons — I'd like to verify the comma fix (fe60811) and the rest of the rebased PR pass before you take another look. Thanks!

[wawanawna]

Superseded by #22171, which is opened from the same branch pushed directly to microsoft/azure-pipelines-tasks (not the fork). This was the only way to get Azure Pipelines / CodeQL / SDL CI to run automatically before merge — fork PRs in this repo skip those checks for secret-isolation reasons. Tip commit is identical (fe608119f). Closing this one in favor of #22171.