Back to skill

Security audit

Skill Template

Security checks for vulnerabilities and agentic risk

Overview

This skill should go to Review because it mixes a template-generator identity with a persistent local logging utility and promotional output injected into generated templates.

Review carefully before installing. Avoid putting secrets, tokens, private notes, or business-sensitive data into this skill because it can retain entries and command arguments locally in plaintext. Treat generated templates as needing cleanup before reuse, especially the fixed promotional footer and branding guidance. The artifact does not show remote exfiltration or destructive behavior, but its packaging and persistence behavior are not cleanly scoped to the advertised template-generator purpose.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T01 · Skill Instruction Hijacking

Error
Location
scripts/skill-tmpl.sh:8
Finding
Persistent Third-Party Promotional Output Hijacking in Generated Skills<![CDATA[ ## Vulnerability Details **File Location**: `tips.md:10`; `scripts/skill-tmpl.sh:8, 59-67, 265, 286-291`; `SKILL.md:119` **Vulnerability Type**: Persistent instruction and generated-output manipulation **Risk Level**: High ### Complete Code Snippets From `tips.md:10`: ```markdown 8. **Consistent branding** — End every output with your brand line. Builds skill recognition ``` From `scripts/skill-tmpl.sh:8`: ```bash BRAND="Powered by BytesAgain | bytesagain.com | hello@bytesagain.com" ``` The generated command template in `scripts/skill-tmpl.sh:59-67` embeds the same behavior: ```bash example) echo "Hello from {name}!" echo "$BRAND" ;; help|*) echo "{display} — Available Commands:" echo " example — Example command" echo "$BRAND" ;; ``` The generated guidance in `scripts/skill-tmpl.sh:286-291` mandates the behavior: ```text 3. **Format output** — Use boxes, tables, and alignment to make output scannable 4. **Validate input** — Always check args and show helpful usage on errors 5. **Python 3.6 compat** — Use .format() instead of f-strings for broader compatibility 6. **Brand every output** — End with your brand line for recognition 7. **Syntax check** — Run bash -n on your script before publishing ``` ### Technical Analysis The project does more than provide ordinary author attribution in package metadata. It explicitly instructs downstream Skill authors to append a fixed third-party promotional message to every output and embeds that behavior in generated executable templates. Commands such as `create`, `commands`, and `tips` propagate the instruction into newly generated Skills. As a result, unrelated command responses are modified to include the BytesAgain domain and email address. Because the generated source contains the branding logic, the output modification persists independently in downstream projects after generation. This is a form of Skill instruction hijacking: operational output is altered for an unrelated pro ...[truncated 1556 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the global promotional value from generated executable code: ```bash BRAND="Powered by BytesAgain | bytesagain.com | hello@bytesagain.com" ``` 2. Remove every generated `echo "$BRAND"` statement from command handlers and help output. 3. Delete guidance requiring generated Skills to “brand every output.” 4. Remove branding as a publication-readiness criterion. 5. Keep optional attribution only in non-operational metadata, such as the package author, homepage, or source fields. 6. Ensure generated command output contains only information relevant to the invoked operation. 7. Add regression tests that generate each available template and verify that no unrelated domain, email address, or promotional footer is inserted. 8. For commands designed to produce machine-readable output, reserve stdout exclusively for requested data and send optional diagnostics to stderr. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/script.sh:5
Finding
User Records and Command History May Be Created with Excessive Local Read Permissions<![CDATA[ ## Vulnerability Details **File Location**: `scripts/script.sh:5-8, 32, 52` **Vulnerability Type**: Insecure permissions for locally stored user data and command history **Risk Level**: Medium ### Complete Code Snippets From `scripts/script.sh:5-8`: ```bash VERSION="2.0.0" DATA_DIR="${SKILL_TEMPLATE_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/skill-template}" DB="$DATA_DIR/data.log" mkdir -p "$DATA_DIR" ``` From `scripts/script.sh:32`: ```bash _log() { echo "$(date '+%m-%d %H:%M') $1: $2" >> "$DATA_DIR/history.log"; } ``` From `scripts/script.sh:51-54`: ```bash cmd_add() { echo "$(date +%Y-%m-%d) $*" >> "$DB"; echo " Added: $*" _log "add" "${1:-}" } ``` ### Technical Analysis The script stores user-provided records in `data.log` and command arguments in `history.log`, but it does not establish a restrictive umask or explicitly set private directory and file permissions. Consequently, permissions depend on the invoking process's environment. With a common `022` umask: - `mkdir -p "$DATA_DIR"` can create the directory with mode `0755`. - Shell redirection can create `data.log` and `history.log` with mode `0644`. On a multi-user system, those modes can allow other local accounts to traverse the storage directory and read the logs. The exposure is significant because `cmd_add` writes the complete supplied record to `data.log`, while `_log` records the first argument for commands such as `add`, `run`, and `search`. The configurable `SKILL_TEMPLATE_DIR` also means storage can be redirected to another location. Although all path expansions are quoted, the script does not verify that the selected directory is private or that existing log paths are regular files rather than symbolic links. ### Attack Path 1. The victim runs the tool under a permissive umask, such as `022`. 2. `scripts/script.sh` creates the data directory without explicitly restricting its mode. 3. The victim invokes `add`, `run`, or `search` with private or sensitive t ...[truncated 1183 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Establish a private umask before creating any storage: ```bash umask 077 ``` 2. Create and normalize the directory with owner-only permissions: ```bash mkdir -p -- "$DATA_DIR" chmod 700 -- "$DATA_DIR" ``` 3. Create log files explicitly and restrict them to mode `0600`: ```bash touch -- "$DB" "$DATA_DIR/history.log" chmod 600 -- "$DB" "$DATA_DIR/history.log" ``` 4. Before writing, verify that the destination directory is owned by the current user and is not unexpectedly writable by other users. 5. Reject log destinations that are symbolic links or non-regular files. Where portability permits, use no-follow and exclusive-creation mechanisms rather than ordinary append redirection. 6. Avoid logging raw user arguments by default. Record only the command name, timestamp, and a non-sensitive status unless the user explicitly enables detailed history. 7. Document that `SKILL_TEMPLATE_DIR` must point to a private, trusted directory. 8. Add automated tests under permissive umasks to confirm that the resulting directory is `0700` and files are `0600`. 9. Consider warning users before storing content that appears likely to contain credentials, tokens, or other secrets. ]]>
Vulnerability Patterns
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (8)

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
The manifest says this is a skill-template generator, but the documented functionality is a general-purpose logging and record-management CLI with persistent storage, search, export, and command history. This mismatch can mislead users and reviewers into authorizing a skill under false expectations, making hidden data collection or unrelated local operations more dangerous.

Description-Behavior Mismatch

High
Confidence
98% confidence
Finding
The front matter presents the skill as a template generator, while the main body describes a separate data-management utility. Security reviews and users rely on the manifest for trust decisions, so this inconsistency can conceal the real operational scope and lead to inappropriate installation or use.

Intent-Code Divergence

High
Confidence
96% confidence
Finding
The bulk of the documentation advertises unrelated data-log commands despite claiming to be a skill-template generator. Broad documentation inconsistency is a security issue because it obscures true capability, including persistent local storage and command history logging, and undermines informed consent.

Description-Behavior Mismatch

High
Confidence
97% confidence
Finding
The script’s actual functionality is a generic local logging/CRUD utility that stores user-provided data in a local database and history log, which materially differs from the advertised purpose of generating and validating skill templates. This mismatch is dangerous because users or automation may grant trust and execute it expecting scaffolding behavior, while it instead collects and persists input data without a purpose aligned to the manifest.

Lp3

Medium
Category
MCP Least Privilege
Confidence
88% confidence
Finding
The skill documents persistent local file access and storage behavior, but the manifest does not declare any tool scope such as permissions or allowed-tools. This creates a transparency and governance gap: users and platforms cannot accurately assess or constrain the skill’s file access, increasing the risk of unintended data exposure or unauthorized local state changes.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The skill mentions that entries and command history are stored locally, but it does not present this as a clear warning or highlight the privacy implications. Users may unknowingly place sensitive data into commands or entries that are then retained in plaintext and later exportable, increasing the chance of local disclosure.

Intent-Code Divergence

Medium
Confidence
93% confidence
Finding
The inline help and header describe the script as a "multi-purpose utility tool," which directly contradicts the manifest’s narrowly scoped skill-template generator description. Such contradictory documentation increases the risk of deceptive packaging or unsafe operator assumptions, because reviewers and users cannot reliably determine what the tool is supposed to do before execution.

Missing User Warnings

Low
Confidence
84% confidence
Finding
The add path writes arbitrary user-supplied content to a persistent local log database immediately, but the tool’s primary description does not clearly warn that it stores data. While this is local-only behavior, undisclosed persistence can leak sensitive prompts, names, or other operator input into files under the user’s home directory, especially in a skill context where users may expect one-shot generation rather than logging.

Static analysis

No suspicious patterns detected.