long-running-harness

• Outcome: Review
• Latest audit: Sep 12, 2026 · 5:28 AM UTC
• Version: 1.0.0

Overview

This skill is a coherent long-running project workflow helper, but it normalizes automatic script execution, background services, subagent work, and recurring scheduled agent turns without enough user control.

Install only if you want a Chinese-language long-running project harness and are comfortable reviewing each project before use. Before letting it run init.sh, inspect dependency manifests, init_db.sh, npm scripts, and any generated cron job; require explicit approval for installs, database changes, background services, and recurring scheduled agent turns.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (3)

T06 · System Persistence

Error

• Location: SKILL.md:169
• Finding: Recurring Agent Cron Job Creates Cross-Session Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 169-174 **Vulnerability Type**: Persistent scheduled Agent execution **Risk Level**: High ### Vulnerable Code ```text ## Scheduled Inspection (Cron Job) For important projects, a periodic cron job can be configured to inspect progress: schedule: kind=cron, expr="0 */4 * * *" payload: kind=agentTurn, message="Read projects/<name>/progress.md and features.json, and check whether any feature has remained blocked for more than three sessions. If so, output a brief report." ``` The displayed text is an English rendering of the source instructions; the cron expression and configuration fields are unchanged. ### Technical Analysis The Skill instructs the Agent to configure a recurring `agentTurn` cron job that runs every four hours. This scheduled activity can continue after the initiating Skill invocation and conversation have ended. No expiration date, maximum execution count, automatic cleanup procedure, ownership tracking, or mandatory user-confirmation step is specified. Consequently, the scheduled task may continue indefinitely and repeatedly access project files. Although the stated purpose is project monitoring rather than malicious access, the behavior matches system persistence because it installs cross-session scheduled execution. ### Attack Path 1. A user invokes the Skill for an important or long-running project. 2. The Agent follows the optional monitoring guidance and creates the specified cron job. 3. The scheduled job remains registered after the original Agent session ends. 4. Every four hours, the platform starts another Agent turn. 5. Each new turn reads `progress.md` and `features.json` and performs additional processing. 6. Without explicit expiration or removal, execution and project-file access continue indefinitely. ### Impact Assessment The scheduled task obtains the ability to initiate repeated Agent activity across sessions and read the named project-state ...[truncated 421 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require explicit, informed user confirmation immediately before creating a scheduled task. - Default to a one-time status check instead of recurring execution. - Assign every scheduled task a clear owner, unique identifier, expiration time, and maximum run count. - Restrict the scheduled Agent to read-only access to the specific status files it requires. - Prevent the scheduled turn from treating file contents as trusted instructions. - Provide the exact command or procedure for listing and removing the task. - Automatically delete the task when the project completes or after a short predefined period. - Log every execution and notify the user when recurring activity occurs. ]]>

T08 · Insecure Dependencies

Error

• Location: references/init-template.md:17
• Finding: Project-Controlled Dependencies Are Installed Without Supply-Chain Verification<![CDATA[ ## Vulnerability Details **File Location**: `references/init-template.md`, lines 17-26 and 74-75 **Vulnerability Type**: Unsafe third-party dependency installation **Risk Level**: High ### Vulnerable Code ```bash if [ -f "package.json" ]; then npm install fi if [ -f "requirements.txt" ]; then pip install -r requirements.txt fi ``` The Python-specific template repeats the unsafe installation behavior: ```bash pip install -q -r requirements.txt ``` ### Technical Analysis The reusable initialization templates automatically install dependencies from project-controlled manifests without requiring dependency review, lockfiles, cryptographic hashes, trusted registries, or verified package provenance. Both package managers can retrieve remote packages. Node.js dependency installation can also execute lifecycle scripts, while Python packages may execute build-related code during installation. If an attacker controls or modifies `package.json`, its lockfile, `requirements.txt`, or a referenced package, running the generated initialization script can introduce and execute attacker-controlled code. This is especially risky because the Skill directs an Agent to run `init.sh` as a standard startup action, turning dependency installation into an expected and potentially unattended operation. ### Attack Path 1. An attacker adds a malicious, compromised, typosquatted, or dependency-confusion package to `package.json` or `requirements.txt`. 2. The project is opened or resumed through the long-running workflow. 3. The Agent runs the generated or existing `init.sh` during its startup routine. 4. `npm install` or `pip install -r requirements.txt` resolves the attacker-selected dependency from a package source. 5. Installation or lifecycle/build logic executes with the privileges and network access of the Agent user. 6. The malicious package can modify project files, access data available to that user, establish additional persistence, or tamper with later ...[truncated 522 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not install dependencies automatically before reviewing the relevant manifests and lockfiles. - Require committed lockfiles and immutable installation modes, such as `npm ci`. - Disable package lifecycle scripts where compatible, for example with `npm ci --ignore-scripts`. - Pin Python dependencies to exact versions and hashes, and install with `pip --require-hashes`. - Use explicitly configured, trusted registries and protect against dependency-confusion resolution. - Reject direct URL, VCS, local-path, or untrusted-index dependencies unless separately approved. - Perform installation inside an isolated container or disposable virtual environment with least privilege. - Restrict network and credential access during package installation. - Scan dependencies for known vulnerabilities and suspicious installation behavior. - Record and present the dependency changes for user approval before execution. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/init-template.md:28
• Finding: Startup Routine Blindly Executes Project-Controlled Scripts and Background Services<![CDATA[ ## Vulnerability Details **File Location**: `references/init-template.md`, lines 28-40 **Vulnerability Type**: Unvalidated local command execution and unmanaged background process **Risk Level**: High ### Vulnerable Code ```bash if [ -f "init_db.sh" ]; then echo "Initializing database..." bash init_db.sh fi if [ -f "package.json" ] && grep -q '"start"' package.json; then echo "Starting development server..." npm start & sleep 5 echo "Development server started" fi ``` The displayed messages are translated into English; the executable commands and control flow are unchanged. ### Technical Analysis The initialization template executes `init_db.sh` solely because the file exists and invokes the project-defined `npm start` command solely because the text `"start"` appears in `package.json`. Neither file is inspected, authenticated, allowlisted, or approved before execution. Both files are project-controlled execution surfaces: - `init_db.sh` can contain arbitrary shell commands. - The `start` entry in `package.json` can invoke arbitrary commands through the package manager. - Package-manager command behavior may also be influenced by local configuration and executable resolution. The server is launched in the background with `&`, but the template does not capture its process identifier, enforce a timeout, constrain its network binding, or terminate it at the end of the session. This can leave an unintended process running after the Agent task completes. ### Attack Path 1. An attacker modifies `init_db.sh` or the `start` script in `package.json`. 2. A later Agent session follows the standard initialization routine. 3. The existence check succeeds, and the Agent executes `bash init_db.sh` or `npm start`. 4. The attacker-controlled commands run with the Agent user's permissions. 5. If launched through `npm start &`, the process continues in the background. 6. The process may modify files, read user-accessible data, connect to network ...[truncated 654 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Inspect and present project-controlled scripts to the user before executing them. - Require explicit confirmation for scripts that modify databases, install software, start services, or access the network. - Execute untrusted project commands in an isolated container or sandbox with a read-only host filesystem where possible. - Run with a dedicated low-privilege account and a minimal environment. - Use absolute paths and a controlled `PATH` to reduce executable-resolution attacks. - Validate the exact package script instead of relying on a simple textual `grep`. - Restrict development services to a loopback interface unless external exposure is explicitly required. - Capture the background process identifier, impose a timeout, and terminate the process during the session cleanup routine. - Avoid background execution when a foreground process with managed lifecycle controls is sufficient. - Log commands, exit codes, process identifiers, opened ports, and cleanup results. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (6)

Natural-Language Policy Violations

Medium

• Confidence: 84% confidence
• Finding: The manifest and operational instructions are predominantly written in Chinese and present trigger phrases and outputs in Chinese as the default behavior. There is no statement offering bilingual operation or user opt-in for language/locale, which can violate organizational language-choice policy.

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The trigger phrases are broad enough to match common user requests like '继续开发' or '分配任务' without requiring explicit project-management context. That can cause the skill to activate unexpectedly and steer the agent into filesystem, git, or task-orchestration actions the user did not intend, increasing the risk of overbroad automation.

Natural-Language Policy Violations

Medium

• Confidence: 93% confidence
• Finding: This markdown template forces a specific language/locale for all field descriptions, examples, and instructions. Under the stated policy, a skill should not impose a language without user opt-in unless the locale constraint is explicitly documented and justified.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The template explicitly says the agent should run init.sh at every session, while the provided examples perform side-effecting actions such as package installation, database initialization, starting background services, and network smoke tests. In an agent skill context, normalizing automatic execution of such scripts increases the risk of unintended code execution, environment tampering, persistence, or costly/destructive actions in untrusted repositories.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: All user-facing instructional content in the file is presented only in Chinese, and there is no indication that the skill supports other languages or that Chinese is a required locale for a specific reason. This can violate language-choice policy when no opt-in or justification is provided.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: The file’s headings, field labels, and writing guidance are entirely in Chinese, and there is no indication that the user may choose another language or that the template is intentionally limited to a Chinese-only context. Under the stated policy, forcing a specific language without opt-in is a natural-language policy concern.

Static analysis

No suspicious patterns detected.