T07 · Tool Hijacking and Spoofing
- Location
scripts/run.sh:10- Finding
Untrusted PATH Resolution Allows Executable Hijacking
- Content
View full analysis
Vulnerability Details
File Location:
scripts/run.sh, line 10
Vulnerability Type: Unqualified external executable invocation
Risk Level: HighVulnerable Code
bash OUT="$(seo-autopilot "$SITE" 2>&1 || true)"Technical Analysis
The script invokes
seo-autopilotby name without using a canonical absolute path, verifying its resolved location, or checking its integrity. The shell therefore searches the runtimePATHand executes the first matching file.The audited project does not contain the
seo-autopilotimplementation or define a pinned, trusted installation source. Consequently, the actual executable and its SEO, network, repository-modification, and pull-request behavior cannot be verified from this package.An attacker who can write to a directory that precedes the legitimate executable in
PATH, or who can influence the process environment, can provide a malicious executable namedseo-autopilot. Triggering the skill would then execute that program with the privileges of the agent or user running the script.The
|| trueconstruct additionally suppresses every nonzero exit status from the external executable. Although captured output remains available, the wrapper continues as if the command succeeded, which can conceal execution failures or malicious substitution from calling automation.Attack Path
- The attacker gains write access to a directory that appears before the trusted tool directory in the runtime
PATH, or influencesPATHbefore the skill is launched. - The attacker places an executable named
seo-autopilotin that directory. - A user or agent triggers the skill with an allowed site, such as
boll-koll.se. - The allowlist check succeeds.
- Line 10 resolves
seo-autopilotthrough the attacker-influencedPATHand runs the malicious executable. - The executable performs arbitrary actions under the privileges of the invoking process and can emit a plausible
PR:line to impersonate l ...[truncated 834 chars]
- The attacker gains write access to a directory that appears before the trusted tool directory in the runtime
- Remediation
View remediation
Remediation Suggestions
-
Bundle a reviewed implementation with the project and invoke it through a canonical path derived from the script directory, for example:
bash SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)" TOOL="$SCRIPT_DIR/seo-autopilot" [[ -x "$TOOL" ]] || { echo "ERROR: trusted seo-autopilot executable is unavailable" >&2 exit 1 } OUT="$("$TOOL" "$SITE" 2>&1)" -
If the executable must be installed externally, document and pin its trusted source and version. Resolve its absolute path and verify that it is located in an approved, non-user-writable directory.
-
Where practical, verify the executable against an approved cryptographic checksum or signed release before execution.
-
Set a minimal trusted
PATHinside the script and reject resolutions from writable or unexpected directories. An absolute path is preferable to relying onPATH. -
Remove
|| true. Capture and propagate failures explicitly so callers cannot mistake failed execution for success:bash if ! OUT="$("$TOOL" "$SITE" 2>&1)"; then printf '%s\n' "$OUT" >&2 exit 1 fi -
Run the external tool with least privilege and expose only the repository credentials, filesystem paths, and network access required for the SEO task.
-