T09 · Insecure Skill Coding Practices
- Location
references/protocol.md:54- Finding
Hard-Coded Persistent Task Records Outside the Active Project
- Content
View full analysis
Vulnerability Details
File Location:
references/protocol.md:54-63
Related Locations:SKILL.md:43-44,references/templates.md:35-52
Vulnerability Type: Hard-coded external storage path and unsafe persistent state handling
Risk Level: MediumVulnerable Code
markdown ## Layer 3 rule Active work lives in: - `/Users/weweclaw/.openclaw/workspace/TASK_QUEUE.md` Completed work lives in: - `/Users/weweclaw/.openclaw/workspace/TASK_ARCHIVE.md` Rule: - active board keeps only in-progress / blocked / waiting-for-confirmation work - completed work should be removed from active view and archived promptlyTechnical Analysis
The protocol instructs the agent to persist task records at absolute, user-specific paths outside the skill and active project directories. These destinations are used regardless of the current user, workspace ownership, project context, or sensitivity of the task.
The task-board schemas can contain task descriptions, status information, timestamps, output paths, and links. The skill provides no requirements to:
- Obtain user approval before writing persistent records.
- Confirm that the destination belongs to the current user or project.
- Restrict file permissions.
- Prevent concurrent or conflicting updates.
- Separate records belonging to different projects or users.
- Redact credentials, private URLs, sensitive paths, or confidential task details.
- Use atomic writes or preserve unrelated existing records.
This violates least-privilege and safe-storage principles. Progress reporting does not inherently require writing potentially sensitive metadata into a fixed external workspace.
Attack Path
- The skill is activated for a non-instant or multi-step task.
- The task includes sensitive metadata, such as a confidential project name, internal output path, private link, or operational status.
- The agent follows the mandatory Layer 3 rule ...[truncated 1294 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace absolute user-specific paths with a caller-provided location or a path relative to the active project.
- Require explicit user approval before creating or modifying persistent task-board files.
- Verify that the selected destination is within an authorized workspace by resolving and validating its canonical path.
- Default to session-only progress messages when persistent storage is not necessary.
- Define a data-minimization policy that excludes credentials, tokens, private URLs, confidential task content, and unnecessary local paths.
- Apply restrictive file permissions appropriate to the current user and workspace.
- Use atomic writes, locking, and conflict detection to prevent corruption or lost updates during concurrent agent activity.
- Namespace records by project and task identifier to prevent cross-project state mixing.
- Define retention and deletion rules for archived task metadata.
- Before modifying an existing board, preserve unrelated records and confirm that the file format and ownership match the active workflow.