Back to skill

Security audit

Clawshell 0.1.0

Security checks for vulnerabilities and agentic risk

Overview

This skill claims to add a human-approval shell guard, but the package does not include the tools it tells users to rely on.

Review this before installing. The documented security model depends on tools that are not present in the package, so copying the TOOLS.md instructions could break shell use or create false confidence that risky commands require approval. Do not rely on this as a shell safety layer unless the publisher supplies the missing implementation, tool registration, fail-closed behavior, and tests proving dangerous commands are blocked or approved as described.

Vulnerability Patterns
  • Tool Hijacking and SpoofingModifies or replaces tools so legitimate-looking calls execute attacker logic
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T07 · Tool Hijacking and Spoofing

Error
Location
SKILL.md:81
Finding
Nonexistent Security Wrapper Is Presented as an Operational Shell Control<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:81-95`; supporting package evidence in `package.json:1-5` **Vulnerability Type**: Tool hijacking and spoofing through an advertised but absent security wrapper **Risk Level**: High ### Vulnerable Code Snippet ```markdown ### 3. Add to TOOLS.md Add the following to your OpenClaw `TOOLS.md` so the agent uses ClawShell for shell commands: ```markdown ## Shell Access Use `clawshell_bash` for ALL shell command execution. Do not use `bash` directly. ClawShell will analyze commands for risk and require human approval for dangerous operations. Available tools: - `clawshell_bash(command, workingDir)` — Execute a shell command with risk analysis - `clawshell_status()` — Check pending approvals and recent decisions - `clawshell_logs(count)` — View recent audit log entries ``` ``` The package manifest contains no implementation or executable entry point for these tools: ```json { "dependencies": { "package-lock.json": "^1.0.0" } } ``` ### Technical Analysis The skill claims that `clawshell_bash` intercepts shell commands, classifies their risk, requests approval for dangerous commands, and blocks critical operations. It also directs users to modify `TOOLS.md` so that agents use this wrapper for all shell execution. However, the audited project contains only `SKILL.md`, two lockfiles, and a minimal `package.json`. There are no source files, tool registration definitions, executable entry points, `main` or `bin` declarations, notification clients, risk-analysis rules, or logging implementation. Consequently, none of the advertised tools—`clawshell_bash`, `clawshell_status`, or `clawshell_logs`—can provide the represented security controls. This creates a spoofed security boundary: users may configure an agent as though a human-approval mechanism exists even though the package does not supply it. The persistent `TOOLS.md` instruction is aligned with the stated purpose and therefore is not independe ...[truncated 1464 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Include the complete implementation of every advertised tool, including command parsing, risk classification, approval handling, timeout behavior, execution, and audit logging. 2. Add explicit package entry points through appropriate `main`, `exports`, or `bin` fields and provide the tool-registration metadata required by OpenClaw. 3. Make initialization fail closed if the wrapper or notification provider is unavailable. Never silently fall back to direct shell execution. 4. Verify tool registration and health before instructing users to disable direct shell access. 5. Add integration tests proving that critical commands are blocked, high-risk commands require approval, rejected and timed-out requests do not execute, and logs are generated. 6. Document the exact behavior when the approval service, network, credentials, or wrapper process is unavailable. 7. Remove the persistent `TOOLS.md` modification instructions until installation and operational verification can be completed automatically. ]]>

T08 · Insecure Dependencies

Note
Location
package.json:1
Finding
Installation Pulls an Unrelated Third-Party Package Without Providing the Claimed Functionality<![CDATA[ ## Vulnerability Details **File Location**: `package.json:1-5`; resolved dependency details in `package-lock.json:6-14` and `pnpm-lock.yaml:8-18`; installation instruction in `SKILL.md:58-63` **Vulnerability Type**: Unnecessary third-party supply-chain dependency **Risk Level**: Low ### Vulnerable Code Snippet ```json { "dependencies": { "package-lock.json": "^1.0.0" } } ``` The npm lockfile resolves that dependency as follows: ```json "node_modules/package-lock.json": { "version": "1.0.0", "resolved": "https://registry.npmjs.org/package-lock.json/-/package-lock.json-1.0.0.tgz", "integrity": "sha512-+yEXtNdlCs5N0Zy/9uvkifgf/RqnGu0WqP4j9Wu1Us4YReFe1YNBh2Krmf8B1xGxjpYnta63K55QP8bkafnOzA==" } ``` The pnpm lockfile confirms the same dependency: ```yaml dependencies: package-lock.json: specifier: ^1.0.0 version: 1.0.0 packages: package-lock.json@1.0.0: resolution: {integrity: sha512-+yEXtNdlCs5N0Zy/9uvkifgf/RqnGu0WqP4j9Wu1Us4YReFe1YNBh2Krmf8B1xGxjpYnta63K55QP8bkafnOzA==} ``` ### Technical Analysis The documented setup directs users to run `npm install`, but the only declared dependency is an npm package literally named `package-lock.json`. No evidence in the project shows that this package implements or supports the advertised shell wrapper, approval mechanism, notification integration, or audit logging. The package is fetched from the standard npm registry and is protected by an integrity hash in both lockfiles. The lockfile metadata does not declare a lifecycle script, and the audit found no evidence that the dependency is malicious. The confirmed issue is therefore unnecessary supply-chain exposure rather than demonstrated malicious-package execution. Using the permissive version range `^1.0.0` in the manifest also means that dependency resolution without the existing lockfile could select a later compatible release. Any third-party dependency expands the trusted computing base, and this dependency provides no demonstra ...[truncated 1483 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the `package-lock.json` dependency unless a concrete, reviewed requirement can be demonstrated. 2. Implement the advertised functionality directly and declare only dependencies required by that implementation. 3. Pin reviewed dependency versions and preserve lockfile integrity hashes for reproducible installation. 4. Run automated vulnerability, provenance, license, and lifecycle-script checks on every dependency before release. 5. Use `npm ci` in controlled deployment environments so installation strictly follows the reviewed lockfile. 6. Consider disabling lifecycle scripts during dependency validation with `npm ci --ignore-scripts`, then explicitly enable only scripts that have been reviewed and are required. 7. Add a clean-environment installation test that verifies the expected tools are actually registered and operational after setup. ]]>
Vulnerability Patterns
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (3)

Tool Parameter Abuse

High
Category
Tool Misuse
Content
1. The agent calls `clawshell_bash` instead of `bash`
2. ClawShell analyzes the command against built-in and configurable risk rules
3. Based on risk level:
   - **Critical** (e.g. `rm -rf /`, fork bombs) — automatically blocked
   - **High** (e.g. `rm -rf`, `curl` to external URLs, credential access) — sends a push notification and waits for your approval
   - **Medium** (e.g. `npm install`, `git push`) — logged and allowed
   - **Low** (e.g. `ls`, `cat`, `git status`) — allowed
Confidence
90% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High
Category
Tool Misuse
Content
1. The agent calls `clawshell_bash` instead of `bash`
2. ClawShell analyzes the command against built-in and configurable risk rules
3. Based on risk level:
   - **Critical** (e.g. `rm -rf /`, fork bombs) — automatically blocked
   - **High** (e.g. `rm -rf`, `curl` to external URLs, credential access) — sends a push notification and waits for your approval
   - **Medium** (e.g. `npm install`, `git push`) — logged and allowed
   - **Low** (e.g. `ls`, `cat`, `git status`) — allowed
Confidence
85% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Unpinned Dependencies

Low
Category
Supply Chain
Content
{
	"dependencies": {
		"package-lock.json": "^1.0.0"
	}
}
Confidence
40% confidence
Finding
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.

Static analysis

No suspicious patterns detected.