Failure Memory Log

• Outcome: Review
• Latest audit: Sep 11, 2026 · 3:08 AM UTC
• Version: 1.0.0

Overview

This skill openly creates a local failure-memory log, but it is broad and automatic enough to persist sensitive error details without clear redaction, consent, or tight recall boundaries.

Install only if you are comfortable with the agent keeping a durable local troubleshooting log. Keep the memory directory outside source control, review it periodically, delete stale entries, and avoid recording raw credentials, tokens, authorization headers, signed URLs, private keys, personal data, or proprietary incident details. Prefer explicit user approval before automatic logging or recall in sensitive projects.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• 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
• 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)

T02 · Agent Memory Poisoning

Warning

• Location: SKILL.md:33
• Finding: Persistent Recall of Unsanitized Failure Content Enables Memory Poisoning<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:33-43`, `SKILL.md:46-51`, and `SKILL.md:61-69` **Vulnerability Type**: T02: Agent Memory Poisoning **Risk Level**: Medium ### Vulnerable Code ```markdown When an error occurs during work, append to `memory/failures.md`: ```markdown ## [YYYY-MM-DD HH:mm] <short title> - **Category:** <build|deploy|config|api|permissions|data|logic|network|dependency> - **Context:** <what you were trying to do> - **Error:** `<exact error message or symptom>` - **Root Cause:** <why it happened> - **Resolution:** <what fixed it> - **Prevention:** <how to avoid next time> - **Tags:** <comma-separated keywords for search> ``` ``` ```markdown Record AUTOMATICALLY when: - A shell command exits non-zero and you identify why - An API call fails and you find the cause - A config/setup step fails and you resolve it - You catch yourself repeating a previously-solved mistake - A sub-agent reports an error with resolution ``` ```markdown **Before starting any significant task**, search failures for relevant history: ```bash grep -i "<keyword>" memory/failures.md ``` Or use `memory_search` if vector search is available: ``` memory_search query="<task description> failure error" ``` ``` ### Technical Analysis The Skill instructs the agent to persist exact error messages, task context, and generated remediation guidance and then recall that content before later tasks. No validation, escaping, provenance tracking, trust boundary, or instruction/data separation is defined. Error messages and sub-agent reports can contain attacker-controlled text. For example, a remote service, repository fixture, build tool, or malicious sub-agent could return an error containing instruction-like content. Because the Skill directs the agent to record exact errors automatically, that content can enter the persistent failure log. Subsequent searches or failure-report operations expose the stored content to the agent again. The vulnerability ...[truncated 1544 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Treat every stored error, context value, and sub-agent report as untrusted data. 2. Add explicit instructions that recalled records must never be followed as commands or policy and may only be used as factual troubleshooting references. 3. Store records in a structured format such as JSON with separate, length-limited fields rather than free-form Markdown. 4. Escape or remove instruction-like constructs, embedded tool calls, role markers, and control sequences before persistence. 5. Record provenance for every entry, including the originating tool, command, service, and whether the content was externally controlled. 6. Require user confirmation before persisting externally supplied errors or sub-agent output. 7. Restrict recall to narrowly selected fields and avoid inserting entire records into the agent context. 8. Provide a review and deletion mechanism for poisoned or obsolete entries. 9. Scope memory per project or trust domain rather than sharing one failure log across unrelated tasks. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/init.sh:9
• Finding: Sensitive Failure Data Is Stored Without Mandatory Redaction or Restrictive Permissions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:33-43` and `scripts/init.sh:9-22` **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium ### Vulnerable Code The Skill requests exact error and task-context persistence: ```markdown When an error occurs during work, append to `memory/failures.md`: ```markdown ## [YYYY-MM-DD HH:mm] <short title> - **Category:** <build|deploy|config|api|permissions|data|logic|network|dependency> - **Context:** <what you were trying to do> - **Error:** `<exact error message or symptom>` - **Root Cause:** <why it happened> - **Resolution:** <what fixed it> - **Prevention:** <how to avoid next time> - **Tags:** <comma-separated keywords for search> ``` ``` The initializer creates the directory and file without setting explicit private permissions: ```bash MEMORY_DIR="${1:-./memory}" mkdir -p "$MEMORY_DIR" FAILURES_FILE="$MEMORY_DIR/failures.md" if [ -f "$FAILURES_FILE" ]; then echo "✅ $FAILURES_FILE already exists ($(grep -c '^## \[' "$FAILURES_FILE" 2>/dev/null || echo 0) entries)" exit 0 fi cat > "$FAILURES_FILE" << 'EOF' # Failure Memory > Append-only log of failures, root causes, and resolutions. > Search with `grep -i "<keyword>" memory/failures.md` --- EOF ``` ### Technical Analysis Command and API errors frequently contain sensitive information such as access tokens, authorization headers, signed URLs, database connection strings, usernames, internal hostnames, personal data, and private filesystem paths. The Skill explicitly encourages recording the exact error and related context but provides no redaction policy. The initialization script relies on the caller's existing `umask`. Consequently, the resulting directory and file may be readable by other local users or processes when executed under a permissive environment. The log is also ordinary plaintext and may be accidentally committed to source control, included in backups, or copied into diagnostic bundles. ...[truncated 1407 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Set a restrictive creation mask before creating storage: ```bash umask 077 mkdir -p -- "$MEMORY_DIR" chmod 700 -- "$MEMORY_DIR" ``` 2. Create and enforce private permissions on the log: ```bash touch -- "$FAILURES_FILE" chmod 600 -- "$FAILURES_FILE" ``` 3. Add mandatory redaction rules for passwords, tokens, cookies, authorization headers, private keys, signed URLs, connection strings, and personal data. 4. Replace the instruction to store the “exact error” with a requirement to store a sanitized error containing only troubleshooting-relevant details. 5. Warn users not to place the memory directory under source control and provide an appropriate `.gitignore` entry. 6. Add retention, rotation, secure deletion, and user-review controls. 7. Do not reuse a pre-existing file until its ownership, type, and permissions have been validated. 8. Avoid shared memory directories unless access controls and the intended trust boundary are explicitly configured. ]]>

SkillSpector

Vulnerability Patterns

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

Findings (4)

Vague Triggers

High

• Confidence: 97% confidence
• Finding: The trigger list is broad enough to activate on common phrases like 'what went wrong' or any generic error/failure during normal agent work, which can cause the skill to run unexpectedly. That increases the chance of unsolicited file reads/writes and automatic persistence of task context that the user did not explicitly request.

Docker Socket Access

High

• Category: Privilege Escalation

Content

## Best Practices

1. **Be specific** — "EACCES on /var/run/docker.sock" beats "permission error"
2. **Include the exact error** — Future grep depends on it
3. **Tag generously** — More tags = better recall
4. **Review monthly** — Patterns reveal systemic issues

• Confidence: 90% confidence
• Finding: Potential security issue detected. Manual review is recommended.

Ssd 3

Medium

• Confidence: 97% confidence
• Finding: The skill explicitly instructs the agent to store exact error messages, detailed context, root causes, and resolutions in a plain markdown log, and later summarize that content. Error messages and task context often contain secrets, tokens, file paths, personal data, internal hostnames, or proprietary details, so this creates a durable disclosure channel and amplifies later leakage through reports and recall.

Vague Triggers

Medium

• Confidence: 89% confidence
• Finding: The instruction to search failure history before 'any significant task' is ambiguous and overly expansive, encouraging the agent to perform unsolicited memory lookups across a wide range of work. In context, this can expose previously stored sensitive operational details and create unnecessary cross-task data access.

Static analysis

No suspicious patterns detected.