T07 · Tool Hijacking and Spoofing
- Location
SKILL.md:7- Finding
Execution of an Unverified External Validation Tool
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 7
Vulnerability Type:T07: Tool Hijacking and Spoofing
Risk Level: MediumVulnerable Code Snippet:
markdown Read `references/provider-selection.md` before choosing a source. Detect what is already available, run with it, deliver value, then recommend at most one missing connector. All normalized factual inputs must satisfy the Groundcrew evidence contract. Locate the active skills root and run `<skills-root>/.groundcrew/groundcrew-doctor.py --evidence <record.json>` before using them in a conclusion. Output follows `references/reporting.md`: shared skeleton, SHIP/FIX/BLOCK/UNDECIDED verdict, Measured/User-provided/Estimated labels.Technical Analysis
The skill requires the agent to discover an “active skills root” and execute
groundcrew-doctor.pyfrom that location. The executable is not included in the audited project, and the instruction does not require validation of its version, cryptographic hash, signature, ownership, or filesystem permissions.This creates an external trust boundary that cannot be verified from the skill package. If an attacker can influence skills-root resolution or replace
.groundcrew/groundcrew-doctor.py, a legitimate authority-report request will cause the agent to execute attacker-controlled Python code.The evidence-record argument may create an additional injection risk if an implementation constructs a shell command through string interpolation. The supplied text does not itself prove shell interpolation, so that aspect is a hardening concern rather than a separately confirmed vulnerability.
Attack Path
- An attacker gains write access to a candidate skills root or its
.groundcrewdirectory. - The attacker creates or replaces
.groundcrew/groundcrew-doctor.pywith a malicious program. - The active skills root resolves to the attacker-influenced location.
- A user invokes the authority-report skill with evidence to validate ...[truncated 1006 chars]
- An attacker gains write access to a candidate skills root or its
- Remediation
View remediation
Remediation Suggestions
- Bundle the evidence validator with the reviewed skill package so its implementation is inside the audit boundary.
- If an external installation is required, resolve it from a fixed, administrator-controlled absolute path rather than dynamically locating an active skills root.
- Pin the validator to an approved version and verify a cryptographic hash or trusted digital signature before every execution.
- Reject validators with unexpected ownership, permissions, symbolic-link resolution, or writable parent directories.
- Execute the validator using a process API with a fixed argument array, for example passing
--evidenceand the record path as separate arguments rather than constructing a shell command. - Canonicalize the evidence path, restrict it to an approved workspace, and reject symbolic links or paths that escape that workspace.
- Run the validator in a restricted environment with minimal filesystem access, no unnecessary network access, and only the credentials required for validation.
- Fail closed if the trusted validator cannot be located or authenticated; do not fall back to another executable with the same name.
