T09 · Insecure Skill Coding Practices
- Location
scripts/wiki_entry_step_checkpoint.sh:94- Finding
Arbitrary Shell Command Execution Through Checkpoint Audit Commands
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill has a clear wiki-maintenance purpose, but its bundled scripts allow overbroad local command execution and writes outside the intended vault boundary.
Install only in a high-trust local vault and run under least filesystem privileges. Before broader use, patch or restrict the raw --audit-cmd shell execution, reject absolute and ../ paths, canonicalize every target under the configured vault, and treat note content and wikilinks as untrusted input. Keep the vault in version control or backups because the skill intentionally rewrites and moves files.
scripts/wiki_entry_step_checkpoint.sh:94Arbitrary Shell Command Execution Through Checkpoint Audit Commands
scripts/wiki_entry_meta_writeback.sh:60Missing Vault Confinement Allows Modification or Relocation of Files Outside the Vault
scripts/wiki_entry_xref_sync.sh:54Content-Controlled Wikilinks Enable Cross-Reference Writes Outside the Domain Directory
scripts/_shared/query_history.sh:187Predictable Temporary Files Permit Symlink-Based File Clobbering
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Unlike the other mismatch reports, this one mentions execution of arbitrary shell via an --audit-cmd parameter. If the associated checkpoint/audit helper actually accepts and executes caller-provided shell, that would create a command-injection path inside a skill already authorized to touch repository content and state files, making the workflow materially more dangerous.
Referenced artifact was not completely inspected
4. 所有步骤都要走 `wiki_entry_step_checkpoint.sh` 记录状态。
Referenced artifact was not completely inspected
4. 所有步骤都要走 `wiki_entry_step_checkpoint.sh` 记录状态。
The script directly executes the user-supplied --audit-cmd with bash -lc, giving the caller arbitrary shell execution in the context of the agent/runtime. That is far broader than a checkpoint/status helper needs, and in this skill context it can be abused to run destructive commands, exfiltrate vault data, or modify unrelated files under the guise of an audit step.
The skill is explicitly designed to read environment variables and modify files, but it does not declare any tool/permission scope to bound those capabilities. In practice this weakens policy enforcement and reviewability: an operator or runtime cannot easily tell that the skill can read configuration and write wiki, index, state, and status files before invocation.
The instruction at L010 is written as a direct role definition in Chinese and sets the skill's operating behavior in a specific language, with no indication that the user may choose another language. Under the locale-policy rule, forcing a specific language without opt-in is a natural-language policy violation.
The skill is user-invocable and explicitly says the executor should continue after Step 3 without waiting for confirmation, while also modifying wiki content, metadata, indexes, and note status. Without a clear user-facing warning and confirmation model, an operator may trigger destructive or hard-to-reverse repository changes unexpectedly, especially because the workflow spans multiple files and status transitions.
The file title and all operational guidance are written entirely in Chinese, and there is no indication that language choice is optional or that the skill is intentionally region-specific. Under the policy, forcing a specific language without user opt-in can be a natural-language policy violation.
All user-facing instructions in this file are presented exclusively in Chinese, with no indication that language selection is optional or that the skill is intentionally limited to a Chinese-speaking context. This can conflict with language/locale policy requirements that prohibit forcing a specific language without user opt-in.
The file’s headings and checklist items are entirely written in Chinese, including operational instructions such as status checks and reporting steps. Under the policy, forcing a specific language without user opt-in or a documented justification is a natural-language policy violation.
The natural-language interface exposed by the script is entirely in Chinese in its usage output, and additional user-facing error/status messages throughout the file follow the same pattern. This imposes a specific language on users without any opt-in, fallback, or justification for a locale-specific scope.
The usage text is presented only in Chinese, and the rest of the script likewise emits Chinese status and error messages. For a shared shell utility, this is a natural-language locale policy issue because users are not given any language/locale opt-in and no region-specific justification is documented in the file.
This shell script rewrites the target wiki file in place using mv "$TMP_WIKI" "$WIKI", which can replace existing content and is potentially destructive, especially in replace mode. While the script prints a success message afterward, there is no prior confirmation prompt or explicit warning comment/docstring near the write operation itself disclosing that the file will be modified.
This shell script presents its argument error and usage text entirely in Chinese, and the rest of the script continues with Chinese status and failure messages. That imposes a specific language on users without any opt-in or justification, which matches the language/locale policy violation category.
This shell script replaces the target document by moving a temporary file over the original, which is a file write operation affecting user data. Although the script prints a success message afterward, there is no pre-action warning, confirmation prompt, or explanatory comment/docstring disclosing that the original file will be modified in place.
Because --audit-cmd is executed immediately and there is no confirmation, warning, or policy gate, any caller that can influence this argument can trigger arbitrary shell commands without meaningful user awareness. In an agent skill, this increases the risk of prompt-driven or workflow-driven command execution, especially since the feature is framed as a routine micro-audit rather than a dangerous operation.