Skip to content

Fix #7: resolve PowerShell by absolute path to prevent CWD hijacking - #8

Merged
interplains merged 1 commit into
mainfrom
fix/powershell-absolute-path
Oct 20, 2026
Merged

interplains merged 1 commit into
mainfrom
fix/powershell-absolute-path

Conversation

@interplains

Copy link
Copy Markdown
Owner

Summary

Fixes #7. The Windows host module invoked PowerShell by the bare name powershell, which Windows resolves through the executable search order — including the current working directory before System32. Because the README instructs users to run the scanner from their Downloads folder (a user-writable location), a planted powershell.exe there would execute during the host checks and could return forged results, as demonstrated in the report.

Change

  • host.py: the interpreter is pinned to its absolute path (%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe). An absolute path is never resolved through the search order, so only the real interpreter can run; if it is absent the call fails to a coverage gap rather than executing a same-named file from elsewhere.
  • The host-check subprocess now runs with an explicit, controlled working directory, so the child cannot inherit a hostile CWD either.
  • Regression tests assert the interpreter path is absolute and ends in powershell.exe.

Testing

  • Full suite: 288 passed, 8 skipped (optional engine).
  • Reproducible-build check passes; the rebuilt single-file no longer contains the bare-name invocation.

Reported by @okba14. Thank you for the detailed write-up and proof-of-concept.

The Windows host module invoked PowerShell by the bare name "powershell".
Windows resolves a bare executable name through the search order, which
includes the current working directory before System32. Because the README
tells users to run the scanner from their Downloads folder - a user-writable
location - a planted powershell.exe there would be executed during the host
checks, and could return forged check results.

Pin the interpreter to its absolute System32 path and run the child process in
a controlled working directory. An absolute path is never resolved through the
search order, so only the real interpreter can run; if it is absent the check
fails to a coverage gap rather than executing a same-named file from elsewhere.

Adds regression tests asserting the interpreter path is absolute.

Reported by @okba14 in #7.
@interplains
interplains merged commit ccd8685 into main Oct 20, 2026
19 checks passed
@interplains
interplains deleted the fix/powershell-absolute-path branch October 20, 2026 11:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unqualified PowerShell invocation enables local executable hijacking and scanner-result forgery

1 participant