T05 · Unauthorized Access and Privilege Escalation
- Location
scripts/task_briefing.py:55- Finding
Unscoped Drive and Workspace Enumeration During Briefing Generation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is mostly a project logging assistant, but it needs review because it can scan broad local project locations, persist cross-project summaries, and delete old briefing files without clear confirmation.
Review before installing. Use this only for projects where you are comfortable having development logs, paths, tasks, issues, and session summaries written to local JSON/Markdown files. Avoid storing secrets in project logs, and be aware that the stats command can delete older briefing JSON files from the skill's briefings directory.
scripts/task_briefing.py:55Unscoped Drive and Workspace Enumeration During Briefing Generation
scripts/project_admin.py:80Unscoped Filesystem Enumeration in Project Administration Statistics
scripts/task_monitor.py:24Unscoped Project Discovery and Log Aggregation by the Monitoring Script
scripts/project_admin.py:203Statistics Command Silently Deletes Historical Briefing Files
A cron-like or passive monitoring capability that scans multiple drives and writes monitoring summaries is far beyond 'log progress when asked.' In skill context, this increases danger because the anti-spam and trigger language may reassure users while background discovery and analysis continue to process local data they did not intend to share.
A cron-like or passive monitoring capability that scans multiple drives and writes monitoring summaries is far beyond 'log progress when asked.' In skill context, this increases danger because the anti-spam and trigger language may reassure users while background discovery and analysis continue to process local data they did not intend to share.
A cron-like or passive monitoring capability that scans multiple drives and writes monitoring summaries is far beyond 'log progress when asked.' In skill context, this increases danger because the anti-spam and trigger language may reassure users while background discovery and analysis continue to process local data they did not intend to share.
A cron-like or passive monitoring capability that scans multiple drives and writes monitoring summaries is far beyond 'log progress when asked.' In skill context, this increases danger because the anti-spam and trigger language may reassure users while background discovery and analysis continue to process local data they did not intend to share.
The skill clearly instructs the agent to read and write files, create directories, and persist state, but it declares no explicit tool scope or permissions boundary. That mismatch increases the chance the runtime grants broader filesystem access than users expect, making unintended file access or modification harder to constrain and audit.
The skill repeatedly emphasizes silent file writes and minimal chat output, which can hide material state changes from the user. Silent persistence is risky in a development assistant because it may create, alter, or overwrite project artifacts without a clear warning or confirmation, reducing transparency and recoverability.
The session archival flow writes conversation-derived summaries, conclusions, and unresolved issues to disk without any explicit privacy notice or consent step. This can persist sensitive project details, credentials, business context, or user-provided data into long-lived files that may later be read by other tools or users on the system.
The archive-and-reread design creates a durable natural-language memory channel outside the normal session boundary. Even if intended for continuity, it increases the risk of sensitive information being retained, replayed into future contexts, or used by later prompts in ways the user did not anticipate, especially because the archived content includes prior conclusions and task state.
The 'continue project' trigger includes very broad phrases like '继续' and '接着上次', which can appear in ordinary conversation and may cause the skill to activate unintentionally. In this skill, unintended activation can lead to local file inspection and project-log reads without a sufficiently explicit user request for those actions.
The daily logging trigger is defined as 'any important moment during development,' which is too subjective to serve as a safe activation boundary. That ambiguity can cause the agent to write logs or persist user content when the user only intended discussion, creating unwanted file writes and possible leakage of sensitive development details into logs.
The research-and-save workflow is triggered whenever documentation is needed during development, which is broad enough to match normal planning or brainstorming. Because the workflow includes external search and file saving, accidental activation could initiate network access and write downloaded or summarized materials into the project without clear consent.
This workflow explicitly instructs the agent to perform online searches and save external materials into local directories, but it does not require notifying the user or obtaining consent for network access and file writes. That increases the risk of silent data egress, ingestion of untrusted content, and unintended modification of the project workspace.
The natural-language instructions and user-facing text throughout the file are written exclusively in Chinese, including the declared tool description and usage guidance, without offering a language choice. Under the policy, forcing a specific language without user opt-in is a locale/language constraint that should be explicitly optional or justified.
The module-level description explicitly states '静默写入文件' (silent file writes), and the tool performs multiple writes to project files such as logs, index files, and state files. Because these writes can modify user project data without any runtime disclosure by default, this is a safety-relevant file write behavior lacking an adequate warning or confirmation for normal operations like log and state updates.
The module docstring and all user-facing CLI messages are presented only in Chinese, which imposes a specific language on users without any visible opt-in or locale selection. The policy requires flagging language or locale constraints when the skill forces a specific language without user choice or documented justification.
The top-level usage text describes stats as a global statistics command, but the implementation also performs deletion of old briefing files. This mismatch is dangerous because it conceals destructive behavior behind benign documentation, increasing the chance of accidental data loss and undermining informed user consent.
The script enumerates projects across ~/.openclaw/workspace and drive roots C: and D:, which exceeds the stated scope of operating on explicitly selected projects for logging and issue tracking. This broad discovery exposes unrelated project names and paths and creates unnecessary inventorying behavior that could leak metadata or violate user expectations.
Scanning global workspace and entire drive roots is unjustified for the declared purpose of a project logging assistant and creates unnecessary access to unrelated directories. Even without reading file contents, this reveals the existence of projects and expands the blast radius if the skill is triggered unexpectedly or misused.
The purge-test action deletes briefing files matching loose name patterns without any warning, preview, or confirmation. This can remove legitimate files whose names happen to contain test-like substrings, causing avoidable data loss in a shared briefings directory.
The stats action is presented as a reporting function but also deletes briefing files older than three days, introducing hidden side effects into a read-like command. Users invoking statistics may unintentionally lose stored project context, which is especially risky in an assistant skill where non-destructive behavior is expected unless clearly requested.
The script automatically deletes briefing files older than three days during stats execution, without explicit notice or user approval. Time-based silent deletion can destroy still-needed project metadata and is particularly unsafe because it occurs during an apparently non-destructive reporting operation.
The script enumerates multiple broad filesystem locations, including the user's workspace, drive-level Projects folders, and even root-level directories on several drives, then inspects any directory containing a logs folder. For a project-briefing utility, this exceeds a narrowly scoped data-access boundary and can expose unrelated project names, paths, and activity metadata, especially when run in an agent context with broad host access.
The code persistently writes per-project briefing JSON files containing project names, paths, timestamps, task summaries, and issue/interruption details into a central briefings directory. This creates a reporting artifact and metadata cache that may outlive the original logs and aggregate sensitive operational information in a way not obvious from the skill's stated behavior.
The module docstring presents all user-facing usage and behavior description only in Chinese, and later console output is also emitted in Chinese. For a general-purpose monitoring script, this imposes a specific language/locale without offering opt-in, fallback, or documenting a region-specific constraint.
The code performs autonomous health monitoring across multiple projects and writes a consolidated monitoring file, which exceeds a narrow logging/issue-tracking role and can enable passive surveillance of user activity. In an agent skill context, this kind of background cross-project state collection is dangerous because it can persistently observe unrelated work without a per-project trigger or explicit user request.
No suspicious patterns detected.