Test Publish Check

• Outcome: Review
• Latest audit: Sep 11, 2026 · 1:41 PM UTC
• Version: 2.3.6

Overview

The release-checklist prompts are mostly coherent, but an included utility silently stores command inputs/history locally and claims removal without deleting the stored data.

Review before installing. The checklist generator itself is low risk, but avoid passing secrets, tokens, internal hostnames, or sensitive release details to the included utility commands because they may be saved under the local test-publish-check data directory. Do not rely on its remove command to erase stored records; inspect and delete the local data files manually if needed.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/script.sh:4
• Finding: Undisclosed Persistent Storage and Raw Activity Logging<![CDATA[ ## Vulnerability Details **File Location**: `scripts/script.sh:4-7`, `scripts/script.sh:30`, and `scripts/script.sh:44-52` **Vulnerability Type**: Undisclosed persistence of user-supplied data and command arguments **Risk Level**: Medium ### Vulnerable Code ```bash VERSION="2.0.0" DATA_DIR="${TEST_PUBLISH_CHECK_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/test-publish-check}" DB="$DATA_DIR/data.log" mkdir -p "$DATA_DIR" ``` ```bash _log() { echo "$(date '+%m-%d %H:%M') $1: $2" >> "$DATA_DIR/history.log"; } ``` ```bash cmd_list() { [ -f "$DB" ] && cat "$DB" || echo " (empty)" _log "list" "${1:-}" } cmd_add() { echo "$(date +%Y-%m-%d) $*" >> "$DB"; echo " Added: $*" _log "add" "${1:-}" } ``` ### Technical Analysis The script creates a persistent data directory and stores user-supplied content in `data.log`. It also silently records command activity and the first supplied argument in `history.log`. This behavior is not aligned with the functionality documented in `SKILL.md`, which presents the skill as a generator of release-readiness checklists for code, APIs, deployment, versioning, launches, and regression tests. The documentation does not disclose that user input or command activity may be retained on disk. The storage destination is derived from `TEST_PUBLISH_CHECK_DIR`, `XDG_DATA_HOME`, or the user's home directory. Consequently, data can persist across executions and outside the audited project directory. Raw arguments are written without data classification, redaction, retention controls, or restrictive file permissions. This is not agent memory poisoning because the stored content is not shown to be loaded as future agent instructions. It is an insecure data-handling and privacy practice. ### Attack Path 1. A user or agent invokes `scripts/script.sh`, believing it provides the documented release-checking functionality. 2. The script creates a persistent directory under the configured data path. 3. The caller executes ...[truncated 1203 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `scripts/script.sh` if it is unrelated to the documented checklist-generation capability. 2. If persistence is intentional, clearly document: - What data is stored. - The storage location. - The retention period. - How users can inspect and permanently delete records. 3. Require explicit user consent before writing supplied content to disk. 4. Do not log raw command arguments. Record only non-sensitive event metadata, or redact secrets and identifiers before logging. 5. Create the data directory and files with restrictive permissions, such as a `umask` of `077`. 6. Validate and constrain environment-controlled storage paths where the execution environment requires path isolation. 7. Add retention limits and secure deletion behavior. 8. Add automated tests confirming that sensitive arguments are not written to logs and that persistence does not occur unless explicitly requested. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/script.sh:54
• Finding: Removal Command Falsely Reports Success Without Deleting Stored Data<![CDATA[ ## Vulnerability Details **File Location**: `scripts/script.sh:54-57` **Vulnerability Type**: Misleading deletion behavior and insecure data-retention handling **Risk Level**: Medium ### Vulnerable Code ```bash cmd_remove() { echo " Removed: $1" _log "remove" "${1:-}" } ``` ### Technical Analysis The `cmd_remove` function prints a successful removal message but never opens, rewrites, or otherwise modifies `data.log`. It therefore provides false assurance that a stored record has been deleted. The function also sends the supplied removal argument to `_log`, causing the attempted deletion to create an additional persistent record in `history.log`. Because `cmd_list`, `cmd_search`, and `cmd_export` can still read the original database, content that the user believes was removed remains retrievable. The defect is especially significant when the script stores sensitive or operational information. A user may rely on the success message as confirmation that the information is no longer retained. ### Attack Path 1. A user stores content through the `add` command. 2. The content is appended to `data.log`. 3. The user invokes `remove` for that content or its identifier. 4. `cmd_remove` prints `Removed`, even though it performs no deletion. 5. The attempted deletion is recorded in `history.log`. 6. The original content remains in `data.log`. 7. A later `list`, `search`, or `export` operation—or direct filesystem access—recovers the supposedly deleted content. No additional privileges are gained through this path. The security consequence is continued access to data that the user was explicitly told had been removed. ### Impact Assessment The flaw breaks expected deletion and retention guarantees. Potentially sensitive records remain exposed for as long as `data.log` exists, and the misleading success response may prevent users from taking alternative cleanup measures. The scope is limited to records stored by this utility under the invoking ...[truncated 147 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Implement actual record deletion before reporting success. 2. Assign stable record identifiers during insertion and require `remove` to operate on an exact identifier rather than ambiguous free-form text. 3. Rewrite the database atomically: - Create a temporary file in the same protected directory. - Copy all records except the selected record. - Apply restrictive permissions. - Atomically replace the original database. 4. Verify that the target record existed and was removed. Return a nonzero status when no matching record is found. 5. Avoid logging the raw deletion argument. Log only a non-sensitive record identifier and outcome if auditing is necessary. 6. Define whether deletion must also remove corresponding history entries and communicate that policy clearly. 7. Add tests proving that removed records cannot subsequently be retrieved through `list`, `search`, `export`, or direct inspection of active data files. 8. Until deletion is correctly implemented, remove the command rather than presenting a false success message. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (12)

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The description contains broad activation language such as 'Use when you need test publish check capabilities' and 'Use before releasing any software, website, app, or content to production,' which can cause the skill to trigger outside a narrowly defined invocation. Overbroad routing is dangerous because it can hijack unrelated release, QA, or deployment conversations, causing unintended skill execution and reducing user control over which tool is invoked.

Natural-Language Policy Violations

Medium

• Confidence: 98% confidence
• Finding: This shell script embeds natural-language instructions that require the model to 'Use Chinese' for generated output. The policy allows locale constraints only when the user can opt in or when the restriction is clearly justified, neither of which is present here.

Natural-Language Policy Violations

Medium

• Confidence: 98% confidence
• Finding: This prompt mandates 'Use Chinese' for API checklist generation. Because the file provides no opt-in or rationale for restricting output language, it violates the language/locale policy for natural-language behavior.

Natural-Language Policy Violations

Medium

• Confidence: 98% confidence
• Finding: The deploy checklist prompt explicitly instructs the model to respond in Chinese. There is no indication that this is optional or required for a specific region-specific compliance context, so it constitutes a locale policy violation.

Natural-Language Policy Violations

Medium

• Confidence: 98% confidence
• Finding: The version-management prompt requires Chinese output while offering no alternative language path. Under the stated policy, mandatory language restrictions need user opt-in or clear justification, which is absent here.

Natural-Language Policy Violations

Medium

• Confidence: 98% confidence
• Finding: This launch-day checklist prompt directs the model to produce output in Chinese only. Because the file does not present this as an opt-in preference or justify it as region-specific, it violates the language/locale policy.

Natural-Language Policy Violations

Medium

• Confidence: 98% confidence
• Finding: The regression-test prompt mandates Chinese output in a hard-coded way. The policy permits such constraints only with user choice or a documented, justified locale restriction, neither of which appears in this file.

Intent-Code Divergence

Medium

• Confidence: 84% confidence
• Finding: The help text presents a multi-command utility with commands like 'remove', 'init', and 'config', implying meaningful operational behavior. In the implementation, several of these commands only print a message and append to a history log, while 'remove' does not modify stored data at all, which contradicts the apparent intent communicated to users.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The helper appends command names and arguments to "$DATA_DIR/history.log", and the script also persists entries to "$DB". While there is some runtime output for commands, there is no warning in comments, docstrings, or help text that user input and activity will be stored on disk, which is relevant to user data and privacy expectations.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The add command appends the user's supplied arguments directly into the data log file and only reports that an item was added, not that it is being permanently written to disk. The help text describes the tool only as a "Multi-purpose utility tool" and does not warn that user-provided content is stored locally.

Natural-Language Policy Violations

Medium

• Confidence: 91% confidence
• Finding: This markdown file presents its operational guidance entirely in Chinese, including section headings and instructions, but does not state that the skill is region-specific or provide any user opt-in for language preference. Under the policy, forcing a specific language without user choice can be a natural-language policy violation.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: The file presents core skill description and instructions in both Chinese and English, but does not state whether the skill adapts to the user's preferred language or requires a specific locale. This can violate language/locale policy expectations when no opt-in or selection mechanism is documented.

Static analysis

No suspicious patterns detected.