Security audit

Skill Analytics

Security checks for vulnerabilities and agentic risk

Overview

The skill is purpose-aligned analytics, but it broadly records sensitive usage details across sessions and includes unsafe logging and optional persistence patterns that need review.

Install only if you intentionally want cross-session local analytics for skill usage. Treat the log as sensitive: avoid raw trigger phrases, redact group or personal details, use a safe JSON-writing helper instead of echo substitution, set restrictive file permissions, define retention, and skip the optional cron entry unless the referenced script is audited and easy to remove.

A.I.G

Vulnerability Patterns

System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
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

Findings (3)

T06 · System Persistence

Warning

Location: SKILL.md:117
Finding: Optional Cron Configuration Creates Persistent Scheduled Execution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 117-124 **Vulnerability Type**: Persistent scheduled task **Risk Level**: Medium ### Vulnerable Code ```markdown ## Daily Cron (optional) Add to crontab to auto-send report every morning: ```cron # Skill analytics report — 7:25 AM Israel (before morning briefing) 25 5 * * * /opt/ocana/openclaw/workspace/scripts/skill-report.sh ``` ``` ### Technical Analysis The Skill recommends adding a cron entry that executes `/opt/ocana/openclaw/workspace/scripts/skill-report.sh` every day. Although explicitly described as optional, installing this entry creates execution that persists across Skill runs and user sessions. Scheduled execution is not required for the Skill's core on-demand reporting functionality and therefore exceeds the minimum privileges needed for that functionality. In addition, the referenced `skill-report.sh` file is not included in the reviewed project, so its contents and security properties cannot be verified. The statement that the task will “auto-send” the report is also unsupported by the report-generation code shown elsewhere in the document, which only prints output. The severity depends on the permissions protecting the crontab and referenced script. If an untrusted user or process can create or replace that script, cron becomes a recurring execution mechanism for attacker-controlled code. ### Attack Path 1. A user follows the documentation and installs the supplied cron entry. 2. The cron entry remains active after the original Skill invocation ends. 3. An attacker or compromised local component gains write access to `/opt/ocana/openclaw/workspace/scripts/skill-report.sh` or a parent directory. 4. The attacker creates or replaces the script with arbitrary commands. 5. At 05:25 UTC, cron executes those commands with the permissions of the account owning the crontab. 6. Execution repeats daily until the cron entry is removed. ### Impact Assessment Successful exp ...[truncated 514 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Remove the cron recommendation unless automatic reporting is explicitly requested by the user. - Require informed, explicit opt-in before creating any scheduled task. - Include the exact `skill-report.sh` implementation in the reviewed package so its behavior can be audited. - Do not describe the task as “auto-send” unless a documented and authorized delivery destination is configured. - Run the scheduled report under a dedicated least-privileged account. - Store the script in a directory that is not writable by untrusted users or processes. - Set restrictive ownership and permissions, such as owner-only write access. - Prefer a scheduler configuration that applies filesystem, network, and resource restrictions. - Provide documented commands for inspecting and removing the scheduled task. ]]>

T09 · Insecure Skill Coding Practices

Error

Location: SKILL.md:37
Finding: Untrusted Analytics Metadata Is Interpolated into a Shell Command<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 37-44 **Vulnerability Type**: Shell command injection and malformed JSON generation **Risk Level**: High ### Vulnerable Code ```markdown ## How to Log (for agents) Add this at the TOP of any skill (after reading SKILL.md, before doing work): ```bash mkdir -p /opt/ocana/openclaw/workspace/data echo "{\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"skill\":\"SKILL_NAME\",\"trigger\":\"TRIGGER\",\"context\":\"CONTEXT\"}" \ >> /opt/ocana/openclaw/workspace/data/skill-analytics.jsonl ``` Replace `SKILL_NAME`, `TRIGGER`, `CONTEXT` with real values. ``` ### Technical Analysis The documentation instructs agents to replace placeholders inside a shell command with real metadata. The `trigger` value is derived from the phrase that caused Skill selection and can therefore contain user-controlled text. No shell escaping or JSON serialization is applied before substitution. If an agent constructs the command by directly replacing `TRIGGER`, `CONTEXT`, or `SKILL_NAME` with raw values and then executes the resulting command, shell metacharacters can alter command parsing. Command substitutions such as `$(...)` or backticks can execute while inside double quotes. Embedded double quotes, semicolons, redirection operators, or newlines can also terminate the intended string and introduce additional commands. Even where shell execution is not achieved, quotes, backslashes, control characters, and newlines can produce malformed JSON or inject additional JSONL records, compromising report integrity. ### Attack Path 1. An attacker submits a trigger phrase containing shell syntax, such as a command substitution or a quote-breaking payload. 2. The agent selects a Skill based on that phrase. 3. Following the analytics instructions, the agent replaces `TRIGGER` with the raw phrase in the documented shell command. 4. The agent executes the dynamically constructed command. 5. The shell interprets the injected ...[truncated 914 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Never build shell commands through textual replacement of user-controlled values. - Serialize records with a JSON library rather than manually composing JSON with `echo`. - Pass metadata as program arguments or environment variables without re-evaluating it as shell source. - For example, use Python with positional arguments and `json.dumps`: ```bash python3 - "$SKILL_NAME" "$TRIGGER" "$CONTEXT" <<'PY' import datetime import json import sys record = { "ts": datetime.datetime.now(datetime.timezone.utc) .replace(microsecond=0).isoformat().replace("+00:00", "Z"), "skill": sys.argv[1], "trigger": sys.argv[2], "context": sys.argv[3], } with open( "/opt/ocana/openclaw/workspace/data/skill-analytics.jsonl", "a", encoding="utf-8", ) as output: output.write(json.dumps(record, ensure_ascii=False) + "\n") PY ``` - Validate `skill` and `context` against strict allowlists where practical. - Limit trigger length and remove control characters before storage. - Add tests covering quotes, backslashes, command substitutions, newlines, and Unicode input. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: SKILL.md:24
Finding: Cross-Session Behavioral Metadata Is Stored in Plaintext Without Defined Protections<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 24-29 **Vulnerability Type**: Plaintext collection and retention of potentially sensitive metadata **Risk Level**: Medium ### Vulnerable Code ```markdown Every skill invocation should append one line to `data/skill-analytics.jsonl`: ```bash echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"SKILL_NAME","trigger":"TRIGGER_PHRASE","context":"GROUP_OR_DM"}' \ >> /opt/ocana/openclaw/workspace/data/skill-analytics.jsonl ``` ``` The Skill description additionally states that it tracks usage “across all agent sessions” and logs every Skill invocation. ### Technical Analysis The analytics record contains the trigger phrase that caused Skill selection and a context identifying a direct message, group, or cron execution. Trigger phrases can disclose user intentions or portions of private conversations, while group names can disclose organizational or social context. The collected data is stored across sessions in a plaintext JSONL file. The documentation does not establish: - User consent or an opt-out mechanism. - Data minimization or trigger redaction. - Restrictive file and directory permissions. - A fixed retention period. - Automatic rotation or deletion. - Access-control expectations for report generation. - Protection against following a pre-existing symbolic link. The claim that the log is “local only” does not eliminate confidentiality risk. Any local principal or compromised process with permission to read the file can inspect the accumulated behavioral history. The actual exposure depends on the deployment account's umask, directory ownership, and filesystem permissions, none of which are enforced here. ### Attack Path 1. Users invoke Skills through direct messages or named group contexts. 2. The analytics instructions append trigger phrases and context identifiers to the persistent JSONL file. 3. Records accumulate across sessions. 4. A local user, plugin, or compromise ...[truncated 866 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Make cross-session analytics explicitly opt-in and document exactly which fields are collected. - Avoid retaining raw trigger phrases; prefer a fixed event identifier or an approved, non-sensitive category. - If triggers are necessary, redact secrets, personal data, message content, and group names before writing. - Create the analytics directory with mode `0700` and the log file with mode `0600`. - Set a restrictive umask before creating files. - Refuse to append if the destination is a symbolic link or is not a regular file owned by the expected account. - Define and enforce a short retention period with automatic rotation and secure deletion. - Restrict report access to authorized users. - Provide commands to inspect, export, reset, and disable collection. - Document that local storage is still sensitive and should not be included in broadly accessible backups or diagnostic bundles. ]]>

SkillSpector

Vulnerability Patterns

Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The skill is designed to record every invocation along with trigger phrases and context across all sessions, but it provides no user-facing notice, consent flow, or minimization guidance. Even though the data stays local, these fields can contain sensitive behavioral and conversational metadata, creating a privacy risk if the file or generated reports are accessed by others.

Ssd 3

Medium

Confidence: 97% confidence
Finding: The log format stores user-provided trigger phrases in plaintext and later uses them in reports, which can directly expose private requests, names, internal topics, or other sensitive content. Because triggers are free-form, the skill may capture far more sensitive material than intended, and anyone with access to the log or report can read it.

Ssd 3

Medium

Confidence: 98% confidence
Finding: The instructions tell agents to log real trigger and context values before doing any work, making retention of potentially sensitive user content and conversation metadata a default behavior. This increases risk because collection happens automatically and broadly, including in direct messages or named groups where metadata itself may be sensitive.

Ssd 3

Medium

Confidence: 96% confidence
Finding: The report output intentionally displays recent trigger phrases, which can reveal private user requests to anyone who views the analytics summary. This amplifies the privacy risk beyond storage alone by republishing sensitive content in a human-readable format that may be shared more widely than the raw log.

Missing User Warnings

Low

Confidence: 82% confidence
Finding: The reset/archive procedure moves the active log and starts a fresh file without warning operators that they are altering operational history and potentially disrupting audit continuity. This is primarily an integrity and operational transparency issue rather than a direct exploit path, but it can still hinder investigations or usage reviews.

Static analysis

No suspicious patterns detected.