Security audit

Session Cleanup

Security checks for vulnerabilities and agentic risk

Overview

This is a disclosed local cleanup utility for OpenClaw session files, with some retention and reliability caveats but no evidence of hidden, deceptive, or exfiltrating behavior.

Before installing, be comfortable with a local script inspecting and moving old OpenClaw session artifacts. Run --dry-run first, keep ~/.openclaw permissions restrictive, do not rely on automatic 30-day trash removal, and only add the cron job if you want recurring cleanup.

A.I.G

Vulnerability Patterns

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
Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally

Findings (5)

T09 · Insecure Skill Coding Practices

Warning

Location: cleanup.sh:107
Finding: Sensitive session artifacts are retained indefinitely with permissions dependent on the caller's umask
Content: View full analysis
/dev/null || { echo -e "${RED}Failed to move: $basename_file${NC}" return 1 } ``` The documentation states: ```markdown - **Moves to `.trash/` first** instead of permanent deletion (recoverable for 30 days) - **Logs all actions** to `~/.openclaw/logs/session-cleanup.log` ``` ### Technical Analysis The Skill moves session backups, checkpoints, trajectory logs, and index files into a trash directory, but it never removes trash entries after the documented 30-day recovery period. Consequently, cleanup does not actually eliminate sensitive data; it relocates and retains it indefinitely. The trash and log directories are created with `mkdir -p` without an explicit permission mode or a restrictive `umask`. Their effective permissions therefore depend on the environment in which the script is run. Session and trajectory artifacts can contain private conversation data, model reasoning traces, file paths, or other operational information. This behavior contradicts the documented 30-day retention guarantee and unnecessarily increases the duration and number of locations in which sensitive data remains available. ### Attack Path 1. A user runs the cleanup script manually or through the documented weekly scheduler. 2. Aged session or trajectory artifacts are moved into `$OPENCLAW_STATE_DIR/.trash/sessions/YYYYMMDD`. ...[truncated 773 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Note

Location: cleanup.sh:146
Finding: Nonzero cleanup counts terminate the script because they are used as shell return statuses
Content: View full analysis
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Note

Location: cleanup.sh:65
Finding: Stale lock files can never be cleaned because each lock identifies itself as active
Content: View full analysis
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Warning

Location: cleanup.sh:132
Finding: Activity validation and file relocation are vulnerable to a time-of-check to time-of-use race
Content: View full analysis
/dev/null || stat -c %s "$file" 2>/dev/null || echo 0) total_size=$((total_size + size)) count=$((count + 1)) move_to_trash "$file" done < <(find "$SESSION_DIR" -maxdepth 1 -name "$pattern" -mtime +"$days" 2>/dev/null) ``` The eventual relocation occurs separately: ```bash mv "$file" "$trash_subdir/$basename_file" 2>/dev/null || { echo -e "${RED}Failed to move: $basename_file${NC}" return 1 } ``` ### Technical Analysis The script first checks whether a candidate belongs to an active session and later performs `mv` as a separate filesystem operation. There is no lock or atomic coordination covering both actions. A session can become active, or the candidate path can be replaced, after `is_active_session` returns but before `mv` executes. The script then acts on filesystem state different from the state it validated. The three-second delay before cleanup increases the broader opportunity for state changes between discovery and processing, although the direct race is between the per-file check and move. The use of path-based operations also means that a process with write access to the session directory may replace or rename an entry during this interval. ### Attack Path 1. The cleanup process discovers an aged artifact. 2. `is_active_session` determines that its session is inactive. 3. Before `mv` executes, OpenClaw resumes that session or another process replaces the candidate path. 4. The cleanup process moves the now-active or substituted file. 5. The active se ...[truncated 652 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Note

Location: cleanup.sh:107
Finding: Trash relocation may overwrite an existing artifact with the same basename
Content: View full analysis
/dev/null || { echo -e "${RED}Failed to move: $basename_file${NC}" return 1 } echo -e "${GREEN}✓ Moved to trash: $basename_file${NC}" log "MOVED: $file -> $trash_subdir/$basename_file" ``` ### Technical Analysis The destination is derived only from the current date and source basename. The script does not check whether the destination already exists and does not request non-clobbering behavior from `mv`. If cleanup processes another source with the same basename on the same day, or a destination already exists from an earlier partial run, standard `mv` behavior may replace the prior destination. The current layout normally scans a single flat session directory, reducing the likelihood of natural duplicate basenames, but collisions remain possible across reruns, restored files, concurrent executions, or attacker-created entries. The result conflicts with the stated goal of recoverability because an older trashed artifact can be silently lost. ### Attack Path 1. A file is moved to `.trash/sessions/YYYYMMDD/`. 2. A file with the same basename later appears again in the session directory, or two cleanup instances process equivalent entries concurrently. 3. Cleanup computes the same destination path. 4. `mv` replaces the existing destination. 5. The previously retained artifact is no longer recoverable. A local process with write access to the relevant directories could intentionally pre-create or recreate colliding filenames. ### Impact Assessment No additional system privilege is obtained. The impact is integrity and availability loss for trashed session artifacts, including failure of the documen ...[truncated 91 chars]
Remediation: View remediation

SkillSpector

Vulnerability Patterns

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
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.