Security audit
Security checks for vulnerabilities and agentic risk
This file manager claims to stay inside the working directory, but its implementation can run unsafe shell commands and has filesystem effects outside that boundary.
Treat this as needing review before installation. Only use it in a disposable, tightly sandboxed environment, and prefer a version that uses native filesystem APIs or execFile/spawn with argument arrays, resolves packaged scripts relative to the installed module, canonicalizes paths against cwd, blocks symlink escapes, enforces size limits, and makes logging opt-in or workspace-local.
index.ts:20Arbitrary Command Execution Through Shell Argument Injection
scripts/file_manager.sh:63Working-Directory Sandbox Escape Through Symbolic Links
index.ts:34Execution of an External Hard-Coded Script Instead of the Audited Package Script
scripts/file_manager.sh:93Declared File-Size Limit Is Not Enforced
The skill claims to be a cwd-local file manager, but it also documents directory creation, deletion, and out-of-cwd logging to ~/.openclaw/logs/file-manager.log. That inconsistency undermines the stated trust boundary and can lead users to expose or modify data outside the expected workspace.
The skill claims to be a cwd-local file manager, but it also documents directory creation, deletion, and out-of-cwd logging to ~/.openclaw/logs/file-manager.log. That inconsistency undermines the stated trust boundary and can lead users to expose or modify data outside the expected workspace.
The manifest promises operations in the session working directory, but the documentation includes writing logs and example outputs outside cwd. A manifest-to-behavior mismatch weakens security assumptions and can cause roles to enable the skill under false premises.
The safety section says the tool is sandboxed to cwd, yet later examples and configuration reference absolute or home-directory paths outside that boundary. Contradictory safety guidance is dangerous because users and downstream agents may rely on the sandbox claim when the documented behavior suggests broader file access is possible.
The documentation frames the skill as safe and cwd-confined, but the implementation constructs a shell command with interpolated inputs and delegates enforcement to an external script. In this context, the mismatch is dangerous because users and calling agents may trust the safety claim while the code path enables shell injection and possible escape from the intended working-directory boundary.
The skill claims to provide safe local file I/O in the working directory, but it actually delegates core operations to a shell script using child_process.exec. That expands the attack surface substantially because shell execution introduces command injection risk and makes the actual enforcement of cwd restrictions opaque and unverifiable from this file.
A local file manager does not need general shell execution, yet this file imports and uses exec to run a command string. Using a shell for file operations is dangerous because untrusted fields like path, dir, content, and pattern are concatenated into the command line, enabling injection or unintended command behavior if special characters are supplied.
The description says to use the skill whenever you need to persist output to disk, read input files, or manipulate the file system safely, which is a very broad natural-language activation scope. It does not provide explicit trigger phrases, exclusions, or negative examples to distinguish when this skill should or should not be invoked.
The natural-language guidance conflicts with itself by asserting cwd-only safety while examples and log paths imply broader filesystem interaction. Inconsistent guidance is risky because agents may choose permissive interpretations and perform operations users did not expect.
The capabilities list includes overwrite, delete, and move-like operations without prominent destructive-operation warnings. This is dangerous in an agent setting because users or downstream prompts may invoke data-loss actions without understanding that files can be overwritten or removed.
The skill explicitly enables persistence via write/append/delete operations, which creates lasting state in the session environment. While persistence is part of the intended function, it is still security-relevant because it can retain sensitive data, alter later agent behavior, or destroy previous artifacts if misused.
## Capabilities
- **Read file**: Get contents of a text file
- **Write file**: Create or overwrite a file
- **Append file**: Add content to existing file
- **List files**: Directory listing with filtering
- **Delete file**: Remove a file (with safety checks)
The manifest description says the skill can read, write, append, and list local files. The declared commands also include file-mkdir and file-delete, which are additional destructive or scope-expanding capabilities not described in the manifest.
The skill invokes an external shell script via child_process.exec, which is a safety-relevant operation. Although the header mentions file I/O generally, this file provides no user-facing confirmation, logging, or explicit warning that shell execution occurs when the skill runs.
The documented capability boundary says the skill is for reading, writing, appending, and listing files in the working directory, but the implementation also supports mkdir and delete. This kind of capability mismatch is dangerous because agents or users may invoke the skill under false assumptions, enabling destructive operations that were not disclosed or expected.
The log function writes to ${FILE_MANAGER_LOG:-$HOME/.openclaw/logs/file-manager.log}, which is outside the declared working-directory scope of the skill. This creates an undeclared side effect and can persist file names and operation history in a broader filesystem location than users or orchestrators expect.
Writing logs to $HOME violates the stated purpose of safely managing files only within the session working directory and may leave persistent traces across sessions. In multi-tenant or sensitive environments, these logs can disclose filenames, activity timing, and data-handling patterns outside the intended containment boundary.
The manifest describes a broader capability set than the user-facing skill metadata promises, including directory traversal, search, move, and delete. This mismatch can mislead users or higher-level policy checks into granting a skill more destructive authority than expected, especially because delete permission is explicitly declared for the workspace.
The manifest description is written entirely in Chinese and does not indicate that language is configurable, optional, or limited to a justified region-specific use case. This can violate language/locale policy when a skill implicitly forces a specific language without user opt-in.
The skill documents logging to a home-directory path but does not clearly warn that file names, paths, or operation metadata may be persisted outside the workspace. This creates a privacy and data-governance risk, especially if sensitive filenames or content-related metadata are logged.
The natural-language trigger list includes several Chinese terms alongside English phrases, but the skill does not document any language-selection behavior or explain the locale policy. This can create an implicit language/locale constraint without clear user opt-in.
The scripts section advertises a search capability that is not disclosed in the stated skill purpose. While search is less destructive than delete, undisclosed file discovery can expose sensitive filenames or contents within the allowed workspace and indicates the manifest is not faithfully representing behavior.
No suspicious patterns detected.