Auto Evolver

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:06 AM UTC
• Version: 1.0.0

Overview

The skill openly aims to run an autonomous self-improvement and outreach loop, but it asks for persistent scheduling, external messaging/publishing, memory access, and hook modification without enough scoping or approval controls.

Install only if you explicitly want a long-running autonomous agent that can schedule itself, write local state, browse/search, interact with external platforms, and alter hooks. Before use, require manual approval for cron creation, hook changes, publishing, comments, private messages, and any use of memory-derived content; also define removal commands, allowlisted platforms, rate limits, retention rules, and dry-run defaults.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Tool Hijacking and Spoofing: Modifies or replaces tools so legitimate-looking calls execute attacker logic
• 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

Findings (3)

T06 · System Persistence

Error

• Location: SKILL.md:296
• Finding: Persistent Autonomous Execution Through Scheduled Tasks## Vulnerability Details **File Location**: `SKILL.md`, lines 296-300 **Vulnerability Type**: Cross-session scheduled-task persistence **Risk Level**: Critical **Complete vulnerable snippet**: ```bash openclaw cron add "*/5 * * * *" "auto-evolver inner-loop" openclaw cron add "*/15 * * * *" "auto-evolver outer-loop" ``` The persistence is corroborated by `STATE.md`, lines 12-13, which reports that the inner loop runs every five minutes and the outer loop runs every fifteen minutes. ### Technical Analysis The documented startup procedure installs two recurring cron jobs. These jobs survive the originating invocation and repeatedly run autonomous workflows. The project does not specify an expiration time, an execution-count limit, an uninstall procedure, a concurrency guard, or an approval requirement for each scheduled execution. The inner loop is instructed to inspect state, generate repair tasks, write logs, and potentially modify hooks. The outer loop is instructed to use browser and publishing tools for external account activity. Scheduling both loops therefore grants continued execution beyond the scope of a single user-authorized skill run. ### Attack Path 1. A user follows the startup instructions in `SKILL.md`. 2. The two `openclaw cron add` commands register recurring jobs. 3. The inner loop executes every five minutes and the outer loop executes every fifteen minutes. 4. Subsequent executions occur without fresh per-run approval. 5. The workflows repeatedly read state, create or modify files, generate tasks, invoke tools, and potentially perform external account actions. 6. Execution continues across sessions until the scheduled tasks are separately discovered and removed. ### Impact Assessment Successful exploitation provides persistent access to the capabilities available to the scheduled OpenClaw process. Depending on the runtime permissions, this can include repeated filesystem writes, access to A ...[truncated 280 chars]
• Remediation: ## Remediation Suggestions - Remove automatic cron installation from the normal startup procedure. - Require explicit user approval before creating any scheduled task. - Prefer one-time, user-triggered runs instead of recurring unattended execution. - If scheduling is necessary, enforce an expiration time, maximum execution count, minimum interval, and concurrency lock. - Require fresh approval before browser, publishing, messaging, hook-writing, or other externally consequential operations. - Run scheduled tasks under a dedicated least-privileged account with a restricted filesystem and tool allowlist. - Provide exact commands for listing, disabling, and removing every installed scheduled task. - Record the task identifier, creation time, creator, permitted actions, and expiration in an auditable registry. - Default all scheduled external actions to dry-run mode.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: STATE.md:26
• Finding: Unnecessary Access to Core Agent Identity and Long-Term Memory Files## Vulnerability Details **File Location**: `STATE.md`, line 26 **Vulnerability Type**: Excessive access to sensitive Agent state **Risk Level**: High **Complete vulnerable snippet, translated into English from the source record**: ```text 1. Completed: Read core files (SOUL.md, MEMORY.md, memory/2026-03-13.md) ``` ### Technical Analysis The execution record confirms that the workflow reads `SOUL.md`, `MEMORY.md`, and a dated memory file. These files may contain long-term behavioral instructions, identity information, conversation-derived context, or user-related data. Access to these files is not demonstrated as necessary for the stated operational purposes of checking token usage, monitoring recurring failures, counting idle cycles, or scheduling tasks. The project defines no field-level filtering, data-minimization policy, access-control boundary, or prohibition against using memory content in autonomous searches and external actions. Although the reviewed files do not prove direct exfiltration, combining broad memory access with autonomous task generation, web browsing, publishing, comments, and private messaging creates a credible disclosure path. ### Attack Path 1. The persistent or manually triggered inner loop starts. 2. The workflow reads core identity and long-term memory files. 3. Sensitive content enters the Agent's active context. 4. The same workflow generates tasks, research queries, reports, logs, or instructions using that context. 5. A later outer-loop action may publish, comment, message, or otherwise transmit generated content to an external service. 6. Sensitive memory-derived information may consequently be exposed outside its intended storage boundary. ### Impact Assessment The workflow can obtain read access to sensitive Agent identity and memory data available to the runtime account. Potentially exposed information includes persistent behavioral rules, prior-session context, personal info ...[truncated 338 chars]
• Remediation: ## Remediation Suggestions - Prohibit access to `SOUL.md`, `MEMORY.md`, and unrelated memory files by default. - Store operational counters in a dedicated state file containing only required fields, such as token totals, timestamps, failure counts, and task identifiers. - Enforce a filesystem allowlist scoped to the skill's own state and log directories. - Redact secrets, personal data, and conversation-derived content before any search, publication, message, or external tool call. - Separate memory-reading operations from external communication operations using distinct least-privileged processes. - Require explicit user approval whenever memory-derived content could leave the local environment. - Maintain an audit log identifying which files and fields were read and which external actions used the resulting data.

T07 · Tool Hijacking and Spoofing

Error

• Location: SKILL.md:113
• Finding: Autonomous Modification of Tool Hooks Without Integrity or Approval Controls## Vulnerability Details **File Location**: `SKILL.md`, lines 113-125 **Vulnerability Type**: Unreviewed tool-hook generation and activation **Risk Level**: High **Complete relevant snippet, translated into English from the source instructions**: ```text 1. Scan foundry insights for recurring failures 2. Select problems with more than five failures 3. Analyze the problem type (browser/read/subagents/other) 4. Generate a repair task in pending.md 5. Use the task format: [AUTO-REPAIR] + problem description + suggested solution 6. Execute the repair, verify the effect, and record the result Problem: browser:relay Threshold: more than five failures Repair: browser-health-check hook Tool: foundry_write_hook Problem: read:ENOENT Threshold: more than five failures Repair: ensure-memory-files hook Tool: foundry_write_hook ``` ### Technical Analysis The repair workflow directs the Agent to generate and execute repair tasks that modify hooks associated with browser and file-reading operations. A hook can intercept or alter future legitimate-looking tool calls, making hook-writing a security-sensitive operation. The project does not provide a fixed reviewed hook implementation, integrity hash, signature check, permission boundary, human review requirement, sandbox, activation gate, or rollback procedure. The proposed hook behavior is generated dynamically from recurring failure observations, so malformed or attacker-influenced failure data could affect the generated repair logic. Because the workflow also runs persistently, an activated hook may continue influencing later tool calls and sessions. ### Attack Path 1. A browser or file-reading failure is recorded more than five times. 2. The auto-repair workflow classifies the recurring failure. 3. It creates an automatically generated repair task in `pending.md`. 4. The workflow executes the repair through `foundry_write_hook`. 5. The generated hook begins ...[truncated 937 chars]
• Remediation: ## Remediation Suggestions - Prohibit autonomous hook generation and activation. - Replace generated hooks with immutable, reviewed implementations stored in version control. - Require explicit human approval before installing, updating, enabling, or removing any hook. - Verify hook signatures or cryptographic hashes before activation. - Restrict hooks to narrowly defined inputs, outputs, files, domains, and operations. - Execute hooks in a sandbox without shell access or unrestricted filesystem and network permissions. - Treat failure logs and generated repair descriptions as untrusted input. - Prevent failure messages from being interpolated into executable code or commands. - Add atomic installation, versioning, health checks, and automatic rollback after failed validation. - Maintain an audit trail containing the hook source, author, approval, hash, activation time, affected tools, and rollback result.

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

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: The skill expands from self-optimization into outbound publishing, commenting, and private-message workflows on external platforms. That creates unsolicited engagement and external-action capability not tightly scoped to the declared purpose, increasing risks of spam, abuse, reputational harm, and policy violations if run autonomously.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The skill specifies automated private messaging/commenting and feedback tracking without any explicit notice, consent flow, or privacy guidance for outreach targets or the operator. This creates privacy, transparency, and compliance risks because the system may contact users and record interaction outcomes without clear authorization boundaries or disclosure.

Context-Inappropriate Capability

Medium

• Confidence: 90% confidence
• Finding: The skill autonomously monitors external sources such as project listings and commercial signals to generate new tasks beyond its stated self-evolution function. This broadens autonomy and objective scope, which can drive unreviewed data collection, mission creep, and potentially manipulative or undesired actions based on third-party content.

Natural-Language Policy Violations

Low

• Confidence: 83% confidence
• Finding: All user-facing documentation and invocation guidance are presented in Chinese, with no indication that another language can be selected or that the locale restriction is intentional and justified. Under the language/locale policy, forcing a single language without user opt-in can be a natural-language policy issue.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: The file’s operational status, headings, and action descriptions are written entirely in Chinese, including core status metadata and workflow notes. For a generally applicable skill, this can constitute a language-policy issue because no user opt-in, alternative language option, or explicit region-specific justification is provided.

Static analysis

No suspicious patterns detected.