Skip to content

fix(windows): resolve absolute path for taskkill to prevent hijacking#617

Merged
kevincodex1 merged 1 commit into
Gitlawb:mainfrom
euxaristia:fix/windows-taskkill-hijacking
Jul 10, 2026
Merged

fix(windows): resolve absolute path for taskkill to prevent hijacking#617
kevincodex1 merged 1 commit into
Gitlawb:mainfrom
euxaristia:fix/windows-taskkill-hijacking

Conversation

@euxaristia

Copy link
Copy Markdown
Contributor

Summary

Fixes a medium-severity issue where invoking taskkill or taskkill.exe without an absolute path on Windows can allow binary hijacking under certain conditions.

This PR ensures all process-termination paths on Windows resolve the absolute path to taskkill.exe under System32 (referencing SystemRoot / windir, with a fallback to C:\Windows).

Changes

internal/background/process_windows.go

  • Add taskkillPath() helper and use it to resolve absolute path of taskkill in terminateProcess.

internal/config/process_windows.go

  • Add taskkillPath() helper and use it to resolve absolute path of taskkill in terminateCommandProcess.

internal/tools/bash_proc_windows.go

  • Add taskkillPath() helper and use it to resolve absolute path of taskkill in hardenProcessLifetime Cancel callback.

Test plan

  • go test ./internal/background/... ./internal/config/... ./internal/tools/... — ok

Using unqualified taskkill / taskkill.exe commands on Windows can allow binary hijacking under certain conditions. Update all process termination callers on Windows to resolve the absolute path to taskkill.exe under System32 (referencing SystemRoot/windir environment variables, falling back to C:\Windows).
@coderabbitai

coderabbitai Bot commented Jul 9, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@euxaristia, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 37 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fad260eb-397b-417e-b41f-27159722e9c6

📥 Commits

Reviewing files that changed from the base of the PR and between a880ce8 and 58fa338.

📒 Files selected for processing (3)
  • internal/background/process_windows.go
  • internal/config/process_windows.go
  • internal/tools/bash_proc_windows.go
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@anandh8x anandh8x left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Bare taskkill on PATH is a real hijack surface for force-kill paths. Pinning System32\taskkill.exe via SystemRoot/windir/C:\Windows is the right hardening. All three Windows terminate sites covered. All CI green. Ship it.

Nit (non-blocking): taskkillPath is duplicated in three packages; a shared helper can come later.

@gnanam1990 gnanam1990 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review

Verdict: Approve with notes (independent pass; not previously reviewed by me; agree with @anandh8x).

Bare taskkill / taskkill.exe on PATH is a real Windows hijack surface on force-kill paths. Pinning System32\taskkill.exe via SystemRootwindirC:\Windows is the right hardening. All three call sites (background, config, tools) are covered; no other taskkill usages remain in tree. CI green including windows-latest; packages compile under GOOS=windows.

Notes (non-blocking)

  1. Residual: poisoned SystemRoot/windir can still redirect the join; tighter option is GetSystemDirectory and ignore env.
  2. taskkillPath is triplicated — share later.
  3. Optional pure-function tests for env fallbacks.
  4. No linked issue / issue-approved.

Ship it.

@kevincodex1
kevincodex1 merged commit 2db00ee into Gitlawb:main Jul 10, 2026
7 checks passed
@euxaristia
euxaristia deleted the fix/windows-taskkill-hijacking branch July 17, 2026 21:05
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.

4 participants