Back to skill

Security audit

ClawTank ARO

Security checks for vulnerabilities and agentic risk

Overview

The skill mostly does what it claims, but its bearer token handling is under-scoped and can send credentials to an undocumented, environment-selected hub endpoint.

Review before installing. Use only in a controlled environment, do not set CLAW_HUB_URL unless you fully trust the destination, avoid placing .clawtank_identity inside project repositories or shared directories, restrict the token file permissions, and rotate the token if it may have been exposed.

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

T09 · Insecure Skill Coding Practices

Error
Location
clawtank.js:12
Finding
Bearer Token Can Be Redirected to an Arbitrary Network Endpoint## Vulnerability Details **File Location**: `clawtank.js:12-13`, with credential transmission at `clawtank.js:60-62`, `103-113`, `130-141`, `158-170`, and `220-231` **Vulnerability Type**: Unrestricted credential forwarding to a configurable endpoint **Risk Level**: High ### Vulnerable Code ```js const IDENTITY_FILE = path.resolve(process.cwd(), '.clawtank_identity'); const DEFAULT_HUB = 'https://clawtank.vercel.app'; const HUB_URL = process.env.CLAW_HUB_URL || DEFAULT_HUB; ``` Representative authenticated request: ```js const res = await fetch(`${HUB_URL}/api/swarm/signals?unresolved=true`, { headers: { 'Authorization': `Bearer ${auth.api_key}` } }); ``` The same bearer-token pattern is used for peer reviews, finding submissions, votes, and chat messages: ```js headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${auth.api_key}` } ``` ### Technical Analysis The `CLAW_HUB_URL` environment variable can replace the documented hub with any URL. The implementation does not validate the URL scheme, hostname, port, or origin before attaching the bearer token. Consequently, authenticated commands may transmit the token to an attacker-controlled server or over unencrypted HTTP. Supporting custom deployments can be legitimate, but unrestricted forwarding of an existing production credential is broader than the minimum privileges required. The documentation only identifies the default hub and does not warn users that an environment variable can redirect credentials. This is not evidence of deliberate exfiltration because the default destination is the documented HTTPS service. It is nevertheless an exploitable credential-disclosure path. ### Attack Path 1. An attacker gains influence over the execution environment, such as a shell profile, environment file, task runner, wrapper script, CI configuration, or parent process. 2. The attacker sets `CLAW_H ...[truncated 1197 chars]
Remediation
## Remediation Suggestions 1. Parse the configured endpoint with `new URL()` and reject malformed values. 2. Require the `https:` scheme; permit plaintext HTTP only for an explicitly enabled local-development mode restricted to loopback addresses. 3. Use an allowlist of trusted hostnames and ports. If custom hubs are necessary, require explicit enrollment rather than trusting an ambient environment variable. 4. Store separate credentials per hub. Never send the default service's bearer token to a custom origin. 5. Disable automatic cross-origin redirects for authenticated requests, or verify every redirect target before forwarding authorization headers. 6. Document `CLAW_HUB_URL`, its security implications, and the exact destination receiving credentials. 7. Consider displaying the authenticated destination before first use and requiring confirmation when it differs from the default origin. 8. Apply short token lifetimes, narrowly scoped API permissions, rotation support, and server-side revocation.

T09 · Insecure Skill Coding Practices

Warning
Location
clawtank.js:12
Finding
Plaintext Credential File Uses an Undocumented Working-Directory Location Without Permission Validation## Vulnerability Details **File Location**: `SKILL.md:20-26`; `clawtank.js:12`, `51-54` **Vulnerability Type**: Insecure local secret storage and documentation-to-implementation path mismatch **Risk Level**: Medium ### Vulnerable Code and Documentation The documentation instructs users to place the token in their home directory: ```md Ensure your `~/.clawtank_identity` contains your Bearer Token for write access: ```json { "agent_id": "your-uuid", "api_key": "ct_your_secret_token" } ``` ``` The implementation instead resolves the file from the current working directory: ```js const IDENTITY_FILE = path.resolve(process.cwd(), '.clawtank_identity'); ``` It reads the file without validating ownership or permissions: ```js function getAuth() { if (!fs.existsSync(IDENTITY_FILE)) return null; return JSON.parse(fs.readFileSync(IDENTITY_FILE)); } ``` ### Technical Analysis The documented `~/.clawtank_identity` location does not match the implemented `process.cwd()` location. A user following the runtime behavior may create or copy the credential file into a project directory. Project directories are more likely to be shared, archived, uploaded, included in build contexts, or committed to source control. The Skill does not verify that the credential file is owned by the current user or inaccessible to group and other users. The documentation also does not require restrictive permissions such as `0600`. Plaintext storage may be necessary for a simple CLI, but locating the secret relative to the working directory and omitting permission checks creates avoidable exposure beyond the minimum access needed for authentication. ### Attack Path 1. A user creates `~/.clawtank_identity` according to the documentation. 2. The command fails to find that file because it searches the current working directory. 3. To make the Skill work, the user copies or creates `.clawta ...[truncated 892 chars]
Remediation
## Remediation Suggestions 1. Make the implementation match the documentation by resolving the file from the user's home directory, such as with `os.homedir()`. 2. Prefer an operating-system credential store or dedicated secret-management facility instead of a plaintext JSON file. 3. If a file remains necessary, create it with mode `0600` and reject it when group or other users have access. 4. Validate that the file is a regular file owned by the current user and avoid following unsafe symbolic links where practical. 5. Provide a secure command for creating and updating the identity file rather than requiring manual editing. 6. Recommend adding `.clawtank_identity` to global and project-specific ignore rules. 7. Avoid storing the credential inside repositories, build contexts, temporary directories, or shared working directories. 8. Document token rotation and revocation procedures for suspected exposure.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Lp3

Medium
Category
MCP Least Privilege
Confidence
92% confidence
Finding
The skill advertises networked behavior and token-based coordination but does not declare any explicit tool scope or permission boundary for those capabilities. That creates a transparency and least-privilege problem: an agent or user may invoke a skill with network and environment access without clear consent or policy restriction, increasing the chance of unintended outbound communication or credential exposure.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The documentation instructs users to store a bearer token in a predictable local file and states that the token is sent on all POST requests, but it provides no warning about credential sensitivity, file permission hardening, rotation, or risks of transmitting the token to a remote service. In this skill context, the token enables authenticated writes to an external hub, so leakage could let an attacker impersonate the agent, submit fraudulent findings, manipulate votes, or exfiltrate identity information.

Static analysis

Detected: suspicious.env_credential_access

Environment variable access combined with network send.

Critical
Code
suspicious.env_credential_access
Location
clawtank.js:13