Back to skill

Security audit

File Management by Brian

Security checks for vulnerabilities and agentic risk

Overview

This is a file-management guidance skill with a read-only audit script; the main caution is that one documented Git cleanup sequence could accidentally publish unintended files if followed uncritically.

Review the audit output before sharing it because filenames may reveal private context. If using the cleanup Git commands, run `git status` and inspect the staged diff first, stage only intended paths, and avoid pushing until you are sure no memory, logs, credentials, or personal configuration files are included.

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

T09 · Insecure Skill Coding Practices

Warning
Location
FILE-MANAGEMENT.md:158
Finding
Indiscriminate Git Staging and Push May Disclose Sensitive Workspace Data## Vulnerability Details **File Location**: `FILE-MANAGEMENT.md:158-162` **Vulnerability Type**: Unsafe source-control workflow **Risk Level**: Medium ```bash ### Before Cleanup ```bash git add -A git commit -m "Cleanup: Remove dead files" git push ``` ``` ### Technical Analysis The documented workflow stages every unignored change in the current repository with `git add -A`, commits the resulting index, and pushes it to the configured remote without an explicit review step. The same documentation describes a workspace that can contain sensitive files such as `MEMORY.md`, `USER.md`, logs, configuration files, state files, and agent-related data. If any such files are inside the repository and are not adequately excluded, this workflow can commit and transmit them unintentionally. Git ignore rules are recommended for logs, but the instructions do not require verification of ignore rules or inspection of staged changes before committing and pushing. This is a documentation-driven unsafe practice rather than automatic malicious behavior: `audit-workspace.sh` does not execute these Git commands. ### Attack Path 1. Sensitive memory, profile, configuration, state, log, or credential-bearing data exists in the workspace repository and is not excluded by `.gitignore`. 2. The user follows the documented cleanup procedure from the repository root. 3. `git add -A` stages all unignored additions, modifications, and deletions. 4. `git commit` records the sensitive files or changes in repository history. 5. `git push` transmits the commit to the configured remote. 6. Anyone with access to that remote may retrieve the exposed data; removing it in a later commit does not erase it from prior history. ### Impact Assessment Successful exploitation or accidental triggering does not grant additional operating-system privileges. Its scope is the data readable by the user and located in the Git working tree. The potential impact ...[truncated 203 chars]
Remediation
## Remediation Suggestions 1. Replace `git add -A` with explicit path-based staging, such as `git add -- path/to/intended-file`. 2. Require `git status --short` before staging and `git diff --cached` before committing. 3. Remove `git push` from the default cleanup sequence or require explicit user confirmation after reviewing the commit. 4. Provide and validate a restrictive `.gitignore` covering logs, state, secrets, credentials, personal profiles, memory files, environment files, and generated artifacts. 5. Add a secret-scanning step before commit and push. 6. Warn that deleting a secret in a later commit does not remove it from repository history; documented incident response should include credential rotation and proper history rewriting where necessary.
Vulnerability Patterns
  • Rogue AgentSelf-Modification, Session Persistence
  • 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 (2)

Session Persistence

Medium
Category
Rogue Agent
Content
1. **No active cron references it**
   ```bash
   crontab -l | grep filename
   openclaw cron list | grep filename
   ```
Confidence
85% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Session Persistence

Medium
Category
Rogue Agent
Content
- [ ] Check if loaded by any skill
- [ ] Check git history for recent changes (may indicate active use)
- [ ] Document what the file did (in case of rollback need)
- [ ] Create git commit with message describing removal
- [ ] Use `trash` not `rm` (recoverable)

---
Confidence
60% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Static analysis

No suspicious patterns detected.