powershell-format: $loaders enumeration leaves an edge — Invoke-Command/Start-Job -FilePath with a computed path

[kyle-sexton]

The residual

plugins/powershell-format/hooks/powershell-format.sh decides whether a PSScriptAnalyzer custom rule's code-loading targets can be pinned to a trust approval. Named loaders are matched against an enumerated list:

$loaders = @("Import-Module", "ipmo", "Add-Type", "New-Module",
    "Import-PowerShellDataFile")

Any cmdlet that loads code but is not on that list is not treated as a loader, so a non-constant argument to it is not refused. Two named examples:

• Invoke-Command -FilePath $x
• Start-Job -FilePath $x

Both execute a repository file whose path the scan cannot pin, and neither trips the loader test.

Why generalizing is not the answer

The obvious generalization — "refuse any command with a non-constant argument" — would refuse Write-Output $x, Where-Object { $_ -eq $y }, and essentially every real rule module. That disables the feature for every consuming repo, which is a worse outcome than the residual: a gate nobody can satisfy gets switched off, and then nothing is checked at all.

There is no obvious middle predicate either. "Loads code" is not a property the AST exposes; it is cmdlet semantics, which means any mechanical test is either an enumeration (this one, with an edge) or over-broad (unusable). Enumerating more names narrows the edge without removing it.

Why the reported repro is nonetheless covered

The finding that surfaced this class was . (Join-Path $PSScriptRoot "deps" "helper.ps1"), and that is structurally covered without reference to $loaders:

• InvocationOperator identifies every . and & invocation regardless of name
• a target that is not a StringConstantExpressionAst, an expandable string whose variables the scan can expand, or an inline script block refuses approval

So the dot-source and call-operator forms — the ones a rule module actually uses to pull in a sibling file — do not depend on the list at all. The list only governs named cmdlets.

Fail-closed confirmation

The residual fails closed in the common direction and open only in the narrow one:

• an unlisted cmdlet with a constant argument: the path is collected by the literal scan and pinned, so a change revokes the approval — correct
• an unlisted cmdlet with a non-constant argument: not refused, and the target is not pinned — the bypass

The exposure is therefore limited to a rule module that both uses one of these specific cmdlets and computes its path. That is narrow, but it is real, and it is recorded here rather than left implicit.

What would actually close it

Options, none free:

1. Extend the enumeration and accept a permanently-thin edge. Cheapest; does not close the class.
2. Enumerate on the parameter rather than the cmdlet — any command invoked with -FilePath, -LiteralPath, -Path, -ScriptBlock and a non-constant value. Broader coverage, still an enumeration, but of a much smaller and more stable vocabulary than the cmdlet namespace.
3. Invert: allow-list the cmdlets a custom rule may call at all, refuse everything else. Genuinely closes it, at the cost of refusing every rule module that calls anything unanticipated — likely unusable.

Option 2 looks like the best ratio if this is ever worth revisiting.

Provenance

Raised as a review finding on #1097, assessed there as a residual the design deliberately does not cover, and accepted as such on the record. Filed so the boundary is documented rather than rediscovered.

[kyle-sexton]

This was generated by AI during triage.

Triage

Verification: CONFIRMED, and still unaddressed by the sibling fix branch.

plugins/powershell-format/hooks/powershell-format.sh on current main (after #1097) defines
$loaders = @("Import-Module", "ipmo", "Add-Type", "New-Module", "Import-PowerShellDataFile")
(the Invoke-Expression/iex entries were split into a separate $evaluators list, not relevant
here). Neither Invoke-Command nor Start-Job is a member, and $loaders -contains $cmdName is the
only test that decides whether a named command's arguments get scanned as load candidates — so
Invoke-Command -FilePath $x / Start-Job -FilePath $x with a non-constant $x are never flagged,
exactly as reported. I also diffed the fix/trust-gate-residual-bypasses branch (the fix for
#1489) against its parent: it does not touch this cmdlet enumeration, confirming this is a distinct,
still-open gap, not something the sibling fix already closes.

The issue's own fail-closed analysis holds up under re-check: the dot-source and call-operator forms
(./&) are matched by InvocationOperator, independent of any name list, so the narrow bypass is
limited to a rule module that both calls one of these specific unlisted cmdlets AND computes its path
argument — a real but narrow exposure, and one the issue's own text already frames as a deliberately
accepted residual from #1097's review (not a new finding).

Classification

• Type: Bug (a real, narrow predicate gap, not merely a documentation ask)
• Priority: low — narrow precondition (an unlisted loader cmdlet called with a computed
  argument), already reviewed and accepted as a residual on #1097's record, no evidence of active
  exploitation, and generalizing the fix has real usability costs per the issue's own analysis.
• Work class: work-class: scoped (any future fix is a bounded enumeration/parameter-based
  predicate change, same shape as the sibling security(trust-gates): three residual approval-signature bypasses — escaped scalars, evaluated code, qualified loader names #1489 fixes)
• Routing: human-gated (needs-human). The issue itself lays out three remediation options with
  explicit tradeoffs and states "none free" — extending the enumeration narrows without closing the
  edge, parameter-based enumeration (-FilePath/-LiteralPath/-Path/-ScriptBlock) is offered as
  the best ratio but is still a design choice, and allow-listing callable cmdlets is flagged as likely
  unusable. This is a genuinely open design-space decision, not a single well-grounded default with a
  reversible alternative, so it does not qualify for decision-defaulted routing. No action is required
  before a maintainer chooses a direction (or explicitly declines to widen coverage further); the
  issue's own stated purpose — "documented rather than rediscovered" — is served by this triage pass
  regardless of when/whether it is picked up.

[kyle-sexton]

Drain: tracked by open PR #2466 fix(powershell-format): refuse computed -FilePath on Invoke-Command and Start-Job (no duplicate opened).