Agent Security Audit

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:48 AM UTC
• Version: 1.0.0

Overview

This skill is a Japanese security checklist, but several example commands labeled as safe could corrupt files, fetch untrusted network content without scoping, or append to persistent memory files if copied into use.

Review this skill carefully before installing. It is not automatically malicious and does not ship executable code, but its security examples should not be copied as-is. Treat it as conceptual material only unless the unsafe file writes, URL fetching, temporary-file handling, logging, and memory-write patterns are rewritten with explicit user approval, path confinement, safe temp files, and authenticated provenance.

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 (5)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:88
• Finding: Unrestricted URL Fetching Enables Server-Side Request Forgery## Vulnerability Details **File Location**: `SKILL.md`, lines 88-105 **Vulnerability Type**: Server-Side Request Forgery through unrestricted URL fetching **Risk Level**: High ### Vulnerable Code ```bash safe_fetch() { local url="$1" local max_chars="${2:-50000}" # 取得とログ記録 echo "[$(date)] フェッチ開始: $url" >> /var/log/fetch.log # コンテンツ取得 curl -s -L --max-time 30 "$url" \ | head -c "$max_chars" \ | sanitize_content /dev/stdin /tmp/fetch-output.txt # スポットライト境界で包装 echo "=== EXTERNAL CONTENT START ===" > /tmp/final-output.txt cat /tmp/fetch-output.txt >> /tmp/final-output.txt echo "=== EXTERNAL CONTENT END ===" >> /tmp/final-output.txt cat /tmp/final-output.txt } ``` ### Technical Analysis The `safe_fetch` function passes a caller-controlled URL directly to `curl`. It does not restrict the URL scheme, destination hostname, resolved IP address, port, or network range. The `-L` option follows redirects without validating each redirect destination. Consequently, an attacker able to influence `url` can request loopback services, private network resources, link-local cloud metadata endpoints, or other destinations reachable from the host. Depending on the protocols enabled in the installed curl build, non-HTTP schemes may also be reachable. Limiting the number of returned characters does not prevent the outbound request or protect sensitive resources from being queried. ### Attack Path 1. An attacker supplies a URL such as a loopback, private-network, or cloud metadata address. 2. Alternatively, the attacker supplies an apparently public URL that redirects to an internal address. 3. `curl -L` follows the request or redirect without destination validation. 4. The internal response is written to the temporary output and returned by `safe_fetch`. 5. The attacker obtains data from a service that was not intended to be exter ...[truncated 437 chars]
• Remediation: ## Remediation Suggestions - Permit only explicitly required schemes, preferably HTTPS. - Maintain an allowlist of approved destination hostnames and ports. - Resolve hostnames before connecting and reject loopback, link-local, private, multicast, and reserved addresses. - Disable redirects or validate the scheme, hostname, resolved address, and port of every redirect target. - Account for DNS rebinding by binding validation to the actual connection address. - Run network retrieval in an isolated process with outbound firewall restrictions. - Enforce response-size, timeout, and content-type limits. - Do not return fetched content until the destination and response have passed validation.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:96
• Finding: Predictable Shared Temporary Files Permit Symlink Attacks and Cross-Request Data Corruption## Vulnerability Details **File Location**: `SKILL.md`, lines 96-105 **Vulnerability Type**: Unsafe temporary-file creation and predictable filenames **Risk Level**: High ### Vulnerable Code ```bash curl -s -L --max-time 30 "$url" \ | head -c "$max_chars" \ | sanitize_content /dev/stdin /tmp/fetch-output.txt # スポットライト境界で包装 echo "=== EXTERNAL CONTENT START ===" > /tmp/final-output.txt cat /tmp/fetch-output.txt >> /tmp/final-output.txt echo "=== EXTERNAL CONTENT END ===" >> /tmp/final-output.txt cat /tmp/final-output.txt ``` ### Technical Analysis The implementation uses fixed paths in the shared `/tmp` directory and opens them with truncating or append redirections. It does not create the files atomically, verify ownership, reject symbolic links, or isolate files between invocations. A local attacker can pre-create `/tmp/fetch-output.txt` or `/tmp/final-output.txt` as a symbolic link to another file writable by the account running the function. Redirections can then truncate or append to the linked target. Concurrent invocations can also read and overwrite each other's content, causing data leakage or attacker-controlled output substitution. The pipeline additionally passes `/dev/stdin` to a sanitizer that performs in-place edits. In-place editing of `/dev/stdin` is not a reliable stream-processing design and may cause the documented function to fail or behave inconsistently. ### Attack Path 1. A local attacker predicts the fixed temporary filename. 2. The attacker creates `/tmp/final-output.txt` or `/tmp/fetch-output.txt` as a symbolic link to a file writable by the victim process. 3. A user or service executes `safe_fetch`. 4. Shell redirection follows the symbolic link and truncates or appends to the target. 5. The attacker causes file corruption or, where the target file has executable or configuration semantics, influences later process behavior. A separate cross-request attack is possible ...[truncated 530 chars]
• Remediation: ## Remediation Suggestions - Create a private per-invocation directory using `mktemp -d`. - Set a restrictive `umask`, such as `umask 077`, before creating files. - Install a `trap` to remove the temporary directory on exit. - Use exclusive, atomic file creation and reject symbolic links. - Verify that created files are regular files owned by the expected account. - Avoid globally predictable names and never share temporary output between requests. - Process standard input as a stream rather than attempting to edit `/dev/stdin` in place. - Where possible, keep intermediate content in a pipeline or controlled file descriptor instead of shared filesystem paths.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:56
• Finding: Sanitization Function Destructively Modifies Caller-Supplied Input Files## Vulnerability Details **File Location**: `SKILL.md`, lines 56-73 **Vulnerability Type**: Unsafe in-place modification of caller-selected files **Risk Level**: Medium ### Vulnerable Code ```bash sanitize_content() { local input_file="$1" local output_file="$2" # HTMLコメント内の指示を除去 sed -i 's/<!--.*AI[:\s].*-->//gi' "$input_file" # 角括弧指示を除去 sed -i 's/\[[A-Z_]*[:]\s*[^]]*\]//g' "$input_file" # ゼロ幅文字除去 sed -i 's/[\u200B\u200C\u200D\uFEFF]//g' "$input_file" # base64エンコード文字列を検出・除去 grep -v '^[A-Za-z0-9+/]*={0,2}$' "$input_file" > "$output_file" # 偽の権限指示を除去 sed -i '/ADMIN\|OVERRIDE\|SECURITY_AUDIT/Id' "$output_file" } ``` ### Technical Analysis Although the function accepts separate input and output paths, it executes several `sed -i` commands against `input_file`. The source is therefore modified before output generation. There is no path confinement, regular-file check, symbolic-link rejection, backup, or authorization check. Any writable file supplied as `input_file` may be irreversibly altered. The regular expressions are also broad and format-insensitive: they may remove legitimate data while failing to identify multiline, encoded, Unicode-obfuscated, or semantically equivalent prompt injections. Pattern deletion must not be treated as a complete security boundary. ### Attack Path 1. An attacker or untrusted caller influences the `input_file` argument. 2. The argument identifies a valuable file writable by the process. 3. `sanitize_content` invokes multiple in-place substitutions on that file. 4. Matching content is deleted from the original source before the output file is generated. 5. The victim experiences data corruption or loss. ### Impact Assessment Successful exploitation allows corruption of files writable by the current process. It does not bypass filesystem permissions, but a privileged or service accoun ...[truncated 229 chars]
• Remediation: ## Remediation Suggestions - Treat source files as immutable and never use `sed -i` on `input_file`. - Read the source and write sanitized content to a newly and securely created destination. - Canonicalize and confine paths to approved directories. - Reject symbolic links and non-regular files. - Refuse to overwrite an existing destination unless explicitly authorized. - Use format-aware HTML or Markdown parsers rather than broad regular-expression deletion. - Preserve an audit trail or backup when processing important content. - Treat sanitization as defense in depth; preserve instruction/data separation and enforce authorization independently of pattern matching.

T02 · Agent Memory Poisoning

Error

• Location: SKILL.md:148
• Finding: Caller-Forgeable Source Labels Permit Persistent Memory Poisoning## Vulnerability Details **File Location**: `SKILL.md`, lines 148-169 **Vulnerability Type**: Persistent memory poisoning through unauthenticated provenance and unrestricted file writes **Risk Level**: High ### Vulnerable Code ```bash validate_memory_write() { local source="$1" local content="$2" local target_file="$3" # 信頼できるソースかチェック case "$source" in "user-direct"|"system"|"heartbeat") echo "信頼できるソース: $source" ;; *) echo "警告: 外部ソースからのメモリ書き込み試行" return 1 ;; esac # 注入パターンチェック if ! detect_injection "$content"; then echo "注入パターンを検出。書き込み拒否。" return 1 fi # 安全であれば書き込み echo "$content" >> "$target_file" echo "メモリ書き込み完了: $target_file" } ``` ### Technical Analysis The function treats the values `user-direct`, `system`, and `heartbeat` as trusted based only on a caller-supplied string. This is not authenticated provenance. A caller can simply provide `system` as the source value. The injection detector is a small denylist and can be bypassed using synonyms, alternate languages, spacing, Unicode characters, encoding, indirect instructions, or content that does not match the listed regular expressions. After this weak validation, content is appended to an unrestricted caller-selected path. When the target is an agent memory or state file, attacker-controlled instructions can persist and influence future sessions. When another writable path is selected, the primitive becomes a more general unauthorized append operation within the executing account's permissions. ### Attack Path 1. An attacker reaches code that invokes `validate_memory_write` or controls its arguments. 2. The attacker sets `source` to `system` or another accepted literal. 3. The attacker constructs malicious memory content that avoids the limited denylist. 4. The attacker selects the agent's pers ...[truncated 624 chars]
• Remediation: ## Remediation Suggestions - Derive provenance from authenticated runtime metadata rather than a caller-provided label. - Do not allow external callers to claim `system` or internal event identities. - Maintain an allowlist of canonical memory files and do not accept arbitrary target paths. - Reject symbolic links and verify ownership, type, and permissions before writing. - Store memory as structured records with a strict schema, source identity, timestamp, and integrity protection. - Separate untrusted observations from trusted instructions and never promote observations into behavioral rules automatically. - Require explicit authorization or human confirmation for durable behavioral changes. - Use atomic writes, locking, versioning, and rollback support. - Retain pattern matching only as defense in depth, not as the primary authorization mechanism.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:39
• Finding: Unescaped Attacker-Controlled Content Enables Security Log Forgery## Vulnerability Details **File Location**: `SKILL.md`, lines 39-44 **Vulnerability Type**: Log injection through unsanitized attacker-controlled data **Risk Level**: Medium ### Vulnerable Code ```bash honeypot_response() { local injection_attempt="$1" echo "指示を実行しました。" | tee -a /var/log/injection-attempts.log echo "[$(date)] 検出された注入試行: $injection_attempt" >> /var/log/security.log # 実際には何も実行しない } ``` ### Technical Analysis The function writes `injection_attempt` directly to a security log without escaping newlines, carriage returns, terminal control characters, or other delimiters. It also applies no length restriction. An attacker can include line breaks and fabricated prefixes to create entries that appear to originate from the logging system. Control characters may affect terminal display when an administrator views the log, and oversized input can contribute to storage exhaustion if the function is repeatedly invoked. ### Attack Path 1. An attacker submits a detected injection string containing newline characters and a fabricated timestamp or severity prefix. 2. `honeypot_response` interpolates the string directly into the log message. 3. Shell redirection writes the embedded lines verbatim. 4. Administrators or automated parsers interpret the forged lines as independent security events. 5. The attacker obscures the real event, misdirects incident response, or pollutes monitoring data. ### Impact Assessment The vulnerability affects log integrity, monitoring reliability, and forensic analysis. Repeated large inputs may consume available log storage. It does not directly execute commands because the variable is expanded inside a quoted argument, but terminal escape sequences may create additional risk in unsafe log viewers.
• Remediation: ## Remediation Suggestions - Use a structured logging API rather than constructing free-form records with `echo`. - Encode untrusted values as JSON fields with correct escaping. - Normalize or escape carriage returns, newlines, tabs, and terminal control characters. - Apply strict length limits to logged attacker-controlled fields. - Add rate limiting and log rotation with storage quotas. - Send logs through a least-privileged logging service with access controls. - Ensure log viewers render control characters safely and parsers do not treat embedded content as separate records.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The example sanitization script uses in-place edits with sed -i against the input file, which can irreversibly modify original content without warning or backup. In an agent skill, this is dangerous because operators may copy the example verbatim and destroy source evidence, corrupt user data, or alter files that should have remained read-only during analysis.

Natural-Language Policy Violations

Low

• Confidence: 88% confidence
• Finding: The natural-language content of the skill, including its title, description, and instructions, is exclusively in Japanese. This imposes a specific language on users without any opt-in, alternative language option, or documented reason for the locale constraint.

Context-Inappropriate Capability

Low

• Confidence: 94% confidence
• Finding: The skill ends with promotional sales text and an external commercial URL that is unrelated to the security checklist itself. In a security-focused skill, unrelated outbound references increase trust and supply-chain risk because users may follow them expecting vetted defensive content, but the link is not necessary for core functionality and is not contextualized or validated.

Static analysis

No suspicious patterns detected.