T09 · Insecure Skill Coding Practices
- Location
scripts/harness.sh:19- Finding
Python Code Injection Through an Untrusted PROJECT_DIR Path
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is coherent for long-running coding automation, but it gives agents broad local execution and git mutation workflows without enough safeguards.
Install only in a disposable or trusted project workspace. Review init.sh before every run, avoid running it from untrusted repositories, inspect git status and staged diffs before committing, and do not use git add -A where secrets or unrelated files may exist.
scripts/harness.sh:19Python Code Injection Through an Untrusted PROJECT_DIR Path
prompts/coder.md:24Mandatory Execution of a Mutable Project-Controlled Initialization Script
prompts/coder.md:48Unrestricted Git Staging Can Commit Credentials and Sensitive Local Files
The documented purpose focuses on workflow orchestration and progress tracking, but the described outputs include an init.sh development-server script and project environment setup behavior that materially expand execution capability. This mismatch can mislead users or downstream policy checks, causing them to approve a skill that can influence local process lifecycle and shell behavior beyond what its high-level description suggests.
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
# Coding Agent Prompt
You are the **Coding Agent** in a long-running project. You make incremental progress on ONE feature per session, test it thoroughly, and leave clear state for the next agent.
## Startup Sequence (EVERY session)
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
exit 0
fi
rm -f "$WORK_DIR/feature_list.json"
rm -f "$WORK_DIR/claude-progress.txt"
rm -f "$WORK_DIR/.harness.json"
rm -f "$WORK_DIR/init.sh"
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
fi
rm -f "$WORK_DIR/feature_list.json"
rm -f "$WORK_DIR/claude-progress.txt"
rm -f "$WORK_DIR/.harness.json"
rm -f "$WORK_DIR/init.sh"
ok "Harness reset. Run 'harness.sh init' to start fresh."
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
rm -f "$WORK_DIR/feature_list.json"
rm -f "$WORK_DIR/claude-progress.txt"
rm -f "$WORK_DIR/.harness.json"
rm -f "$WORK_DIR/init.sh"
ok "Harness reset. Run 'harness.sh init' to start fresh."
}
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
rm -f "$WORK_DIR/feature_list.json"
rm -f "$WORK_DIR/claude-progress.txt"
rm -f "$WORK_DIR/.harness.json"
rm -f "$WORK_DIR/init.sh"
ok "Harness reset. Run 'harness.sh init' to start fresh."
}
The README instructs users to run initialization commands that create and modify files in the target project, including project scaffolding and git state, but it does not clearly warn that these actions are state-changing. In an agent-automation skill, omission of modification warnings increases the risk that users or downstream agents run it in the wrong directory or on an important repository and unintentionally alter source files.
The documented harness reset capability implies potentially destructive state removal or reinitialization, yet the README provides no warning about data loss, overwritten progress, or repository changes. Because this skill manages persistent state across sessions, an unsafe reset can erase feature tracking, progress logs, scripts, or other project metadata with little user awareness.
The skill advertises commands that initialize projects, update files, and use shell-driven workflows, but it does not declare any explicit tool scope such as permissions or allowed-tools. In an agent environment, missing scope boundaries can cause the model to invoke file-write and shell capabilities more broadly than intended, increasing the chance of unauthorized filesystem changes or command execution.
The document explicitly depicts the skill creating files in the target project, modifying source code, interacting with git history, and starting a development server, but it provides no warning, consent boundary, or operational safeguards for those system-impacting actions. In an agent-automation skill, this omission increases the chance that an agent will perform persistent workspace changes or launch processes without the user understanding the scope of side effects.
The diagram explicitly instructs the initializer agent to write multiple files and perform git init plus an initial commit, but it provides no warning, confirmation step, or scoping guidance about modifying the user's working directory or repository state. In an agent-harness context, these are real side effects that can overwrite files, initialize a repository unexpectedly, or create commits the user did not intend.
The sequence directs the coding agent to run init.sh to start a dev server without any warning about local code execution, network exposure, background processes, or environment changes. Because this skill is specifically designed to orchestrate long-running agent workflows, undocumented script execution is more dangerous: users may treat it as routine while it can execute arbitrary shell commands with the user's privileges.
The prompt explicitly instructs the agent to read and execute init.sh, which is arbitrary code from the repository, and to start servers automatically. In an agent skill context, this can cause unreviewed code execution, network activity, or environment changes without an explicit safety check or user confirmation.
The prompt directs the agent to run git add -A and git commit, which stages all repository changes and mutates git history automatically. This is dangerous because it can capture unrelated, sensitive, or accidental modifications and persist them without a user warning or approval checkpoint.
The prompt explicitly instructs the agent to create files, install dependencies, write an executable shell script, and initialize and commit a git repository, but it provides no requirement to obtain explicit user confirmation before making those system-modifying changes. In an agentic environment, this can lead to unintended filesystem changes, package installation, process execution, and repository mutations based solely on a high-level project description.
The README presents all instructional content in Chinese and does not indicate that other languages are supported or that Chinese is a justified requirement for a region-specific skill. This can be a natural-language policy concern when a skill effectively forces a specific language without user opt-in.
This markdown file lists several commands and brief descriptions, but it does not clarify how or when the skill should be invoked versus when similar user requests should be ignored. Without negative examples or tighter trigger constraints, the activation scope is somewhat ambiguous for an orchestrating skill with broad workflow actions like init, run, feature, and commit.
No suspicious patterns detected.