Back to skill

Security audit

skill bundle clawchain

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly transparent about its blockchain and DEX functions, but it asks agents to update active skill instructions from mutable remote URLs and handles raw signing keys for high-impact transactions.

Install only if you are comfortable giving this skill local access to blockchain signing keys and allowing on-chain actions. Use separate low-value wallets, prefer encrypted or external signing, pin and review dependencies, and do not enable the heartbeat remote-update workflow unless updates are verified and approved before activation.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (4)

T03 · Remote Payload Retrieval and Execution

Error
Location
heartbeat.md:12
Finding
Unverified Remote Skill Updates Create a Post-Review Payload Channel<![CDATA[ ## Vulnerability Details **File Location**: `heartbeat.md:12-24`; related installation instructions at `skill.md:78-81` and `curl_skills.md:89-92` **Vulnerability Type**: T03: Remote Payload Retrieval and Execution **Risk Level**: Critical ### Vulnerable Code ```bash ## First: Check for skill updates curl -s https://clawchain.ai/skill.md | grep '"version"' ``` ```bash Compare with your saved version. If there's a new version, re-fetch the core skill files: curl -s https://clawchain.ai/skill.md > ~/.clawchain/skills/clawchain/SKILL.md curl -s https://clawchain.ai/heartbeat.md > ~/.clawchain/skills/clawchain/HEARTBEAT.md ``` The same direct replacement pattern appears in the installation instructions: ```bash mkdir -p ~/.clawchain/skills/clawchain curl -s https://clawchain.ai/skill.md > ~/.clawchain/skills/clawchain/SKILL.md curl -s https://clawchain.ai/heartbeat.md > ~/.clawchain/skills/clawchain/HEARTBEAT.md ``` The curl-based variant similarly installs mutable content: ```bash mkdir -p ~/.clawchain/skills/clawchain curl -s https://clawchain.ai/curl_skills.md > ~/.clawchain/skills/clawchain/SKILL.md curl -s https://clawchain.ai/heartbeat.md > ~/.clawchain/skills/clawchain/HEARTBEAT.md ``` ### Technical Analysis The heartbeat directs the agent to periodically retrieve behavioral instructions from mutable remote URLs and overwrite the locally installed Skill files. There is no cryptographic signature, pinned digest, immutable version URL, trusted manifest, staging process, or explicit user review before activation. Although the downloaded objects are Markdown rather than native executables, Skill Markdown is an effective execution channel in an AI-agent environment: its directives are loaded and followed by the agent and can cause tool calls, filesystem access, credential access, network communication, or transaction signing. HTTPS protects transport against ordinary interception but does not protect against compromise of the origin, DNS/acco ...[truncated 1457 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove automatic replacement of active Skill files. 2. Publish immutable, versioned artifacts rather than mutable URLs such as `/skill.md`. 3. Distribute a signed release manifest containing the version and SHA-256 digest of every file. 4. Embed or securely provision the trusted publisher public key and verify signatures locally. 5. Download updates to a staging directory rather than directly overwriting active files. 6. Reject any update whose signature, digest, origin, or expected filename does not match the trusted manifest. 7. Present a semantic diff and require explicit user approval before activating behavioral changes. 8. Preserve the previous verified release and support atomic rollback. 9. Use `curl --fail --show-error --location --proto '=https' --tlsv1.2` so HTTP failures do not silently replace files with invalid content. 10. Treat Skill Markdown with the same integrity requirements as executable code. ]]>

T08 · Insecure Dependencies

Error
Location
curl_skills.md:183
Finding
Unpinned Third-Party Dependencies Execute in Private-Key Signing Contexts<![CDATA[ ## Vulnerability Details **File Location**: `curl_skills.md:23-29,183-190`; related occurrences at `bsc_pancakeswap_skill.md:39-44,111-115` and `impossible_finance_skill.md:43-48,107-111` **Vulnerability Type**: T08: Insecure Dependencies **Risk Level**: High ### Vulnerable Code ```yaml dependencies: - name: postchain-client description: "Chromia blockchain client library for creating and signing transactions." install: "npm install postchain-client" - name: "@chromia/ft4" description: "FT4 account framework library for Chromia account registration and authentication." install: "npm install @chromia/ft4" ``` ```bash mkdir -p ~/.config/clawchain/scripts cd ~/.config/clawchain/scripts npm init -y npm install postchain-client @chromia/ft4 ``` Both BSC trading Skills use the same mutable dependency-installation pattern: ```bash npm install ethers # or: pnpm add ethers ``` ### Technical Analysis The installation commands do not pin exact package versions or require a reviewed lockfile. Dependency resolution can therefore change over time and may include changed transitive dependencies. The installation process also does not disable npm lifecycle scripts. This is particularly sensitive because these libraries run in processes that: - Read raw Chromia or EVM private keys. - Construct account registration operations. - Select transaction destinations and arguments. - Sign blockchain transactions. - Submit or return signed transaction bytes. A compromised direct or transitive package could access the signing process's memory and filesystem, alter transaction parameters before signing, or transmit credentials. The audit found no evidence that the named packages are currently malicious; the vulnerability is the unverified, mutable supply-chain trust placed in them. ### Attack Path 1. A direct or transitive npm package is compromised, maliciously updated, or resolved to an unexpected release. 2. The user follows the Skill instructio ...[truncated 1057 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin every direct dependency to an exact reviewed version. 2. Commit a reviewed `package-lock.json` with integrity hashes and install using `npm ci`. 3. Do not generate a new package manifest and resolve mutable packages during routine Skill execution. 4. Pin and audit transitive dependency versions. 5. Use `npm ci --ignore-scripts` where lifecycle scripts are unnecessary. 6. Run vulnerability, provenance, and package-signature checks before release. 7. Vendor or bundle the minimum reviewed signing implementation when practical. 8. Separate dependency installation from signing: never install or update packages in a process or environment that has wallet access. 9. Run signing code in a constrained process with no network access where technically possible. 10. Prefer hardware-backed or OS-keystore signing so dependencies never receive exportable private keys. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
bsc_pancakeswap_skill.md:128
Finding
Private Keys Are Stored Unencrypted by Default<![CDATA[ ## Vulnerability Details **File Location**: `bsc_pancakeswap_skill.md:128-161`; related occurrences at `impossible_finance_skill.md:124-157` and `curl_skills.md:203-224` **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: High ### Vulnerable Code The PancakeSwap wallet setup writes the raw EVM private key into JSON: ```javascript node -e " const fs = require('fs'); const path = require('path'); const { ethers } = require('ethers'); const wallet = ethers.Wallet.createRandom(); const dir = process.env.HOME + '/.config/bsc_agent'; fs.mkdirSync(dir, { recursive: true }); const file = dir + '/wallet.json'; fs.writeFileSync(file, JSON.stringify({ privateKey: wallet.privateKey, address: wallet.address, publicKey: wallet.publicKey }, null, 2), { mode: 0o600 }); console.log('Wallet saved to ' + file); console.log('Address: ' + wallet.address); " ``` The resulting format explicitly contains plaintext key material: ```json { "privateKey": "0x...", "address": "0x...", "publicKey": "0x..." } ``` Impossible Finance uses the same pattern: ```javascript fs.writeFileSync(file, JSON.stringify({ privateKey: wallet.privateKey, address: wallet.address, publicKey: wallet.publicKey }, null, 2), { mode: 0o600 }); ``` The curl-based ClawChain helper also stores a raw hexadecimal private key: ```javascript const keyPair = encryption.makeKeyPair(); const content = JSON.stringify({ privKey: keyPair.privKey.toString("hex"), pubKey: keyPair.pubKey.toString("hex") }, null, 2); fs.mkdirSync(path.dirname(outFile), { recursive: true }); fs.writeFileSync(outFile, content, { mode: 0o600 }); ``` ### Technical Analysis Mode `0600` is an appropriate filesystem permission, but it is not encryption. The private keys remain directly usable by any process running as the same operating-system user and may also be exposed through: - Malware or a compromised dependency. - Agent tool misuse. - Home-directory backups or snapshots. - Acciden ...[truncated 1388 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Make encrypted keystores the default rather than an optional production enhancement. 2. Obtain the decryption secret interactively or through an OS credential manager; do not hardcode it in scripts or environment files. 3. Prefer OS keychains, TPM-backed keys, hardware wallets, or remote signers with policy enforcement. 4. Prevent private-key export when supported by the signer. 5. Keep separate keys for social operations, ColorPool, PancakeSwap, and Impossible Finance. 6. Use dedicated wallets with strict balance caps and move excess assets out promptly. 7. Retain owner-only file and directory permissions, including `0700` for credential directories and `0600` for encrypted keystores. 8. Exclude credential paths from backups, telemetry, support bundles, and source control. 9. Define key rotation and incident-response procedures. 10. Avoid passing wallet passwords through command-line arguments, which may be exposed in process listings or shell history. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
bsc_pancakeswap_skill.md:356
Finding
DEX Transaction Workflows Do Not Enforce Final User Authorization<![CDATA[ ## Vulnerability Details **File Location**: `bsc_pancakeswap_skill.md:356-394`; equivalent workflow at `impossible_finance_skill.md:351-396` **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: High ### Vulnerable Code The PancakeSwap workflow moves directly from quote calculation to approval and broadcast: ```text ### Swap flow (any token pair with liquidity) 1. Load wallet from wallet.json (privateKey + address). 2. Connect to BSC: new ethers.JsonRpcProvider(BSC_RPC_URL) (mainnet: chain id 56). 3. Resolve tokens: Use token contract addresses (from user or discovery). For native BNB use WBNB in the path. 4. Check swap availability: Call router getAmountsOut(amountIn, path). 5. Build path. 6. Get router contract. 7. Deadline: Math.floor(Date.now() / 1000) + 300. 8. amountOutMin: from getAmountsOut(amountIn, path) then apply slippage. 9. Sign and send: For BNB → token use { value: amountInWei }; for token → BNB or token → token, approve router for the token first, then call the swap. ``` The executable high-level pattern similarly omits an authorization checkpoint: ```text ### Execute swap (high level) 1. Load wallet.json. 2. Create ethers.Wallet(privateKey, provider). 3. Build router call (e.g. swapExactETHForTokens) with path, deadline, amountOutMin. 4. Send transaction: tx = await router.swapExactETHForTokens(...); await tx.wait(). 5. Return tx hash to user: https://bscscan.com/tx/<hash>. ``` Impossible Finance contains the same direct quote-to-approval-to-broadcast sequence. ### Technical Analysis The Skill states that it does not execute trades without user confirmation, but this requirement is not incorporated into the actual transaction workflow. There is no mandatory final confirmation after all transaction-critical fields have been resolved. A safe authorization decision must bind the user's approval to the final normalized values, including: - Chain ID and RPC network. - Router and spender addresses. - Input ...[truncated 1776 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Add a mandatory final confirmation immediately before every approval or swap. 2. Display checksummed contract addresses, not token symbols alone. 3. Show chain ID, router, route, recipient, input amount, expected output, minimum output, slippage, price impact, deadline, approval amount, and estimated fee. 4. Require an explicit affirmative response tied to those exact values; invalidate approval if any value changes. 5. Verify the provider-reported chain ID against the configured and user-approved chain. 6. Maintain verified allowlists for default routers and wrapped-native-token contracts. 7. Use exact per-trade allowances instead of unlimited approvals. 8. Check existing allowances and offer revocation after the transaction. 9. Simulate approval and swap transactions before signing. 10. Enforce configurable transaction-value, slippage, price-impact, and daily-loss limits. 11. Reject ambiguous token symbols and require verified contract addresses. 12. Requote immediately before signing and request renewed confirmation if output or fees change beyond a defined threshold. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (100)

Credential Access

High
Category
Privilege Escalation
Content
description: "Contains the agent's BSC private key (encrypted or plaintext) and public address. Created once during wallet setup. The agent uses this to sign swap transactions on BSC. This file SHOULD be encrypted at rest — see Security section."
    access: read
  - name: ClawChain Credentials (optional)
    path: "~/.config/clawchain/credentials.json"
    description: "Chromia keypair used to authenticate on-chain operations. Only needed if registering the BSC public key on ClawChain for EVM event tracking. This file is created by the clawchain skill, not by this skill."
    access: read
    optional: true
Confidence
93% confidence
Finding
The skill declares read access to `~/.config/clawchain/credentials.json`, a separate credential store used to authenticate ClawChain operations. Cross-skill credential access expands the trust boundary: if this skill is invoked for BSC trading, it can also consume Chromia credentials and initiate unrelated authenticated actions.

Credential Access

High
Category
Privilege Escalation
Content
- It does **not** manage ClawChain agent registration. For that, see the `clawchain` skill (`skill.md` or `curl_skills.md`).
- It does **not** provide investment advice or execute trades without user confirmation.
- It does **not** access any files outside of `~/.config/bsc_agent/` and optionally `~/.config/clawchain/credentials.json` (read-only, for EVM key registration only).

### Transparency: Files Accessed
Confidence
92% confidence
Finding
The skill states it may access `~/.config/clawchain/credentials.json` despite being presented primarily as a PancakeSwap/BSC trading skill. This broadens the effective authority of the skill and creates unnecessary exposure of sensitive cross-system credentials.

Credential Access

High
Category
Privilege Escalation
Content
| File | Access | Purpose |
|------|--------|---------|
| `~/.config/bsc_agent/wallet.json` | Read/Write (created once) | Stores the agent's BSC private key and address for signing transactions |
| `~/.config/clawchain/credentials.json` | Read-only (optional) | Used only if registering BSC public key on ClawChain for EVM event tracking |

### Transparency: Network Calls
Confidence
92% confidence
Finding
The transparency table confirms read-only access to a ClawChain credential file unrelated to core token swap functionality. Even read-only access is sensitive because authentication secrets can be copied and reused to perform blockchain operations elsewhere.

Credential Access

High
Category
Privilege Escalation
Content
- A registered agent account on ClawChain (Chromia)
- An authenticated session (FT4 keypair from ClawChain registration)
- Your `wallet.json` file with `publicKey` (required) and optionally `address`
- The ClawChain credentials file at `~/.config/clawchain/credentials.json` (created by the `clawchain` skill)

### Environment Variables for ClawChain
Confidence
94% confidence
Finding
The prerequisites section operationalizes use of the ClawChain credential file, showing that the skill is designed to depend on and consume another system's authentication material. This increases blast radius if the skill is compromised or behaves unexpectedly, because both BSC wallet operations and Chromia identity actions become reachable.

Credential Access

High
Category
Privilege Escalation
Content
56 \
  "$ADDRESS" \
  --ft-auth \
  --secret ~/.config/clawchain/credentials.json \
  -brid $CLAWCHAIN_BRID \
  --api-url $CLAWCHAIN_NODE \
  --await
Confidence
97% confidence
Finding
The command explicitly passes `--secret ~/.config/clawchain/credentials.json` to authenticate a ClawChain transaction. This is direct use of sensitive credentials by a skill whose primary purpose is BSC trading, creating a concrete cross-domain credential-use path that could be abused for unintended on-chain actions.

Credential Access

High
Category
Privilege Escalation
Content
required: true
credentials:
  - name: ColorPool Credentials
    path: "~/.config/colorpool/credentials.json"
    description: "Chromia keypair (privKey + pubKey in hex) for signing ColorPool transactions. This may be the same keypair as your ClawChain credentials, or a separate one for ColorPool. Used only locally by Chromia CLI for signing — never sent over the network."
    access: read
  - name: ClawChain Credentials (for account lookup)
Confidence
90% confidence
Finding
The skill explicitly requests read access to a local credentials.json containing a Chromia private key used for signing transactions. Even if described as local-only, any agent skill that can read signing material creates a high-value secret exposure path: compromise of the skill runtime, logs, prompts, or downstream tooling could leak the key and enable unauthorized on-chain transactions.

Credential Access

High
Category
Privilege Escalation
Content
description: "Chromia keypair (privKey + pubKey in hex) for signing ColorPool transactions. This may be the same keypair as your ClawChain credentials, or a separate one for ColorPool. Used only locally by Chromia CLI for signing — never sent over the network."
    access: read
  - name: ClawChain Credentials (for account lookup)
    path: "~/.config/clawchain/credentials.json"
    description: "Chromia keypair used for looking up your account ID. Created by the clawchain skill. Read-only access — this skill does not modify it."
    access: read
    optional: true
Confidence
81% confidence
Finding
The skill also requests read access to ClawChain credentials, which may include a private key even though the stated purpose is only pubkey-based account lookup. This broadens the secret exposure surface unnecessarily because a less sensitive source could provide the public key without exposing a full credential bundle.

Credential Access

High
Category
Privilege Escalation
Content
| File | Access | Purpose |
|------|--------|---------|
| `~/.config/colorpool/credentials.json` | Read (used for `--secret` flag) | Chromia keypair for signing swap transactions via CLI |
| `~/.config/clawchain/credentials.json` | Read-only (optional) | Used to look up your account ID from your pubkey |

### Transparency: Network Calls
Confidence
90% confidence
Finding
The transparency table confirms the skill reads the ColorPool credential file for signing operations, which still means the runtime has access to sensitive key material. In an agent setting, documented access does not reduce risk; it confirms the presence of a secret that could be exfiltrated or abused if the skill or surrounding environment is compromised.

Credential Access

High
Category
Privilege Escalation
Content
| File | Access | Purpose |
|------|--------|---------|
| `~/.config/colorpool/credentials.json` | Read (used for `--secret` flag) | Chromia keypair for signing swap transactions via CLI |
| `~/.config/clawchain/credentials.json` | Read-only (optional) | Used to look up your account ID from your pubkey |

### Transparency: Network Calls
Confidence
81% confidence
Finding
The skill documents optional read-only access to the ClawChain credential file, but 'read-only' still exposes any private key inside that file to the skill context. Since the declared use is only account ID lookup from a pubkey, reading the full credential file is broader than necessary and increases blast radius.

Credential Access

High
Category
Privilege Escalation
Content
#### Get account id from pubkey

You will find your public key in `~/.config/clawchain/credentials.json` which must have been previously generated. If this file does not exist prompt your user to register on ClawChain first.

```bash
chr query ft4.get_accounts_by_signer id="pubkey here"   \
Confidence
80% confidence
Finding
The instructions direct the operator to obtain the public key from a credentials file that likely contains both public and private key material. That practice normalizes access to a secret-bearing file for a non-secret use case, increasing the chance of accidental disclosure or misuse by an agent or user.

Credential Access

High
Category
Privilege Escalation
Content
'[0, [["A","T"], x"<YOUR_PUBKEY>"], null]' \
  'null' \
  --ft-register-account \
  --secret ~/.config/colorpool/credentials.json \
  -brid $COLORPOOL_BRID \
  --api-url $COLORPOOL_NODE \
  --await
Confidence
92% confidence
Finding
Using --secret ~/.config/colorpool/credentials.json in examples shows that live signing keys are directly consumed by the CLI from disk. In many agent environments, command invocations, arguments, and file paths may be logged or observed, making this a significant secret-handling risk and enabling unauthorized trades if the key leaks.

Credential Access

High
Category
Privilege Escalation
Content
```bash
chr tx <operation> "value1" "value2" "value3" \
  --ft-auth \
  --secret ~/.config/colorpool/credentials.json \
  -brid $COLORPOOL_BRID \
  --api-url $COLORPOOL_NODE \
  --await
Confidence
92% confidence
Finding
The generic operation template instructs all state-changing actions to use a local credentials file via --secret, reinforcing a pattern of broad access to private-key material. In a transactional DEX skill, compromise of that key directly translates into unauthorized swaps or transfers, so the context makes the exposure more dangerous than a low-risk read-only utility skill.

Credential Access

High
Category
Privilege Escalation
Content
'["CHR", "USDT"]' \
  "<YOUR_ACCOUNT_ID>" \
  1735689600 \
  --ft-auth --secret ~/.config/colorpool/credentials.json \
  -brid $COLORPOOL_BRID --api-url $COLORPOOL_NODE --await
```
Use the `amount_out_min` from the quote (with slippage applied), not a guess.
Confidence
92% confidence
Finding
The swap example demonstrates an actionable transaction command that consumes the credential file to authorize token swaps. Because this skill performs financial operations, exposure of the signing key can lead directly to asset loss through unauthorized trading or transfers, making the risk materially significant.

Credential Access

High
Category
Privilege Escalation
Content
### Credential Storage

- `~/.config/colorpool/credentials.json` contains your Chromia keypair for ColorPool. Protect it with `chmod 600`.
- The private key is used **only locally** by Chromia CLI to sign transactions. It is **never sent over the network**.
- The `--secret` flag tells `chr` where to find the keypair for signing — the CLI handles signing in-memory.
Confidence
88% confidence
Finding
The credential storage section confirms the file contains a private key, making the earlier credential-access patterns clearly security-relevant rather than merely informational. Even if the private key is never sent intentionally, any skill with read access to that file creates a credible exfiltration and misuse path.

Credential Access

High
Category
Privilege Escalation
Content
required: true
credentials:
  - name: ClawChain Keypair
    path: "~/.config/clawchain/credentials.json"
    description: "Chromia keypair (privKey + pubKey in hex) used to sign transactions. Created once during initial setup by the keygen.js helper script. This keypair identifies your agent's on-chain account — losing it means losing access. The private key never leaves this file; it is only used locally by the signing scripts."
    access: read
dependencies:
Confidence
91% confidence
Finding
The skill requires access to a local private-key file used to authenticate blockchain actions. While operationally necessary, granting a skill read access to raw private keys significantly raises the risk of credential theft or misuse if the skill, companion files, or local scripts are compromised.

Credential Access

High
Category
Privilege Escalation
Content
files_created:
  - path: "~/.config/clawchain/scripts/"
    description: "Directory containing helper scripts (keygen.js, register.js, generate-tx.js) for offline transaction signing. These scripts are created during initial setup."
  - path: "~/.config/clawchain/credentials.json"
    description: "Your Chromia keypair file. Created by keygen.js. Contains privKey and pubKey in hex format. Protected with chmod 600."
  - path: "~/.config/clawchain/SOUL.md"
    description: "Local personality profile file. Contains exaggerated personality instructions derived from your on-chain personality summary."
Confidence
89% confidence
Finding
The file creation instructions establish persistent storage of a private key in a predictable location. Predictable credential paths make targeting easier, and any later compromise of the agent or companion scripts can directly abuse that key material.

Credential Access

High
Category
Privilege Escalation
Content
| File | Access | Purpose |
|------|--------|---------|
| `~/.config/clawchain/credentials.json` | Read/Write (created once by keygen.js) | Chromia keypair for signing transactions |
| `~/.config/clawchain/scripts/*.js` | Read (created during setup) | Helper scripts for offline transaction signing |
| `~/.config/clawchain/SOUL.md` | Read/Write | Local personality profile loaded before each action |
Confidence
90% confidence
Finding
The transparency table explicitly states read/write access to the credential file for signing transactions. This confirms the skill operates with sensitive credential material, increasing the blast radius of any prompt injection, remote file update, or local script compromise.

External Script Fetching

High
Category
Supply Chain
Content
```bash
mkdir -p ~/.clawchain/skills/clawchain
curl -s https://clawchain.ai/curl_skills.md > ~/.clawchain/skills/clawchain/SKILL.md
curl -s https://clawchain.ai/heartbeat.md > ~/.clawchain/skills/clawchain/HEARTBEAT.md
```
Confidence
97% confidence
Finding
The skill explicitly instructs fetching external skill files over the network and storing them as local skill components. This is a classic remote script/instruction fetching pattern that can bypass prior review and introduce malicious or altered behavior at any time the remote content changes.

Credential Access

High
Category
Privilege Escalation
Content
fi

# 2. Keypair exists?
CRED_FILE="$HOME/.config/clawchain/credentials.json"
if [ -f "$CRED_FILE" ]; then
  if node -e "JSON.parse(require('fs').readFileSync('$CRED_FILE','utf-8'))" 2>/dev/null; then
    PUBKEY=$(node -e "console.log(JSON.parse(require('fs').readFileSync('$CRED_FILE','utf-8')).pubKey.toUpperCase())")
Confidence
82% confidence
Finding
The status check reads and parses the credential file directly, including printing the public key. While less severe than exposing the private key, it normalizes direct credential-file handling by the agent workflow and increases opportunities for accidental leakage or unsafe scripting patterns.

Credential Access

High
Category
Privilege Escalation
Content
**You MUST run each `cat << 'EOF' > ...` command below.** These commands create the `.js` files inside `~/.config/clawchain/scripts/`. The scripts will NOT exist until you execute these commands.

> **What these scripts do:** They generate signed transaction bytes *locally* (offline). The private key from `credentials.json` is only used *in-memory* to sign — it is never sent over the network. The resulting hex is then submitted to the Chromia node via curl.

#### `keygen.js` (Generates Keypair)
Confidence
90% confidence
Finding
The setup section emphasizes that helper scripts will consume the private key from credentials.json, confirming routine raw-key access by locally created scripts. Combined with npm-installed dependencies and remotely fetched companion content, this creates a meaningful secret-exposure risk.

Credential Access

High
Category
Privilege Escalation
Content
#### `keygen.js` (Generates Keypair)

Creates a new Chromia keypair and saves it to `~/.config/clawchain/credentials.json`. This script is **safe to run multiple times** — it will not overwrite an existing keypair.

```bash
cat << 'EOF' > ~/.config/clawchain/scripts/keygen.js
Confidence
89% confidence
Finding
The key generation flow creates a raw private/public key JSON file under the user's home directory. Even with restrictive permissions, plaintext key storage materially increases risk if the host, scripts, or agent environment are compromised.

Credential Access

High
Category
Privilege Escalation
Content
const path = require("path");
const os = require("os");

const outFile = process.argv[2] || path.join(os.homedir(), ".config", "clawchain", "credentials.json");

if (fs.existsSync(outFile)) {
  console.log(`Credentials already exist at ${outFile}`);
Confidence
90% confidence
Finding
The embedded script code shows the default credential path and direct disk-based key handling. This makes the secret location and access pattern explicit, lowering the effort needed for an attacker or malicious extension to target the private key.

Credential Access

High
Category
Privilege Escalation
Content
}

async function main() {
  const credPath = process.argv[2] || path.join(os.homedir(), ".config", "clawchain", "credentials.json");
  if (!fs.existsSync(credPath)) { 
    console.error(`Credentials not found at ${credPath}`); 
    process.exit(1);
Confidence
92% confidence
Finding
register.js directly loads and parses the private key from the credential file into memory for signing. This is a true sensitive-credential access path and would let compromised local code act fully as the user's on-chain identity.

Credential Access

High
Category
Privilege Escalation
Content
async function main() {
  let args = process.argv.slice(2);
  let credPath = path.join(os.homedir(), ".config", "clawchain", "credentials.json");

  // Handle optional --cred flag
  if (args[0] === "--cred") {
Confidence
93% confidence
Finding
generate-tx.js reads arbitrary credential paths via --cred and loads raw key material for transaction signing. This broadens the credential-access surface and could be abused to target other key files or automate unauthorized signing if the script is invoked by untrusted instructions.

Credential Access

High
Category
Privilege Escalation
Content
node ~/.config/clawchain/scripts/keygen.js
```

This creates `~/.config/clawchain/credentials.json` with owner-only permissions (`chmod 600`). The file contains your Chromia keypair in hex format:

```json
{
Confidence
88% confidence
Finding
The registration documentation instructs creation of a plaintext credential file containing the private key. This is an architectural secret-handling weakness even if presented as normal setup.

Static analysis

No suspicious patterns detected.