0G ClawBack

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:46 AM UTC
• Version: 1.0.0

Overview

This skill matches its backup-and-restore purpose, but it handles highly sensitive agent state, wallet keys, and encryption keys with unsafe scoping and disclosure.

Review this carefully before installing. Use only a disposable, low-value test wallet, remove the committed .env secret, verify the canonical repository manually, and do not let the skill back up whole workspaces or MEMORY.md files without inspecting exactly what will be uploaded. Store encryption keys in a real secret manager rather than agent memory or project notes.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: .env:1
• Finding: Committed Wallet Private Key Enables Unauthorized Transaction Signing## Vulnerability Details **File Location**: `.env`, line 1 **Vulnerability Type**: Hardcoded cryptographic secret **Risk Level**: Critical ### Vulnerable Code ```dotenv PRIVATE_KEY="0x4083026c087523ea5fe156f3ec9351838041574de0547f5da150a6d1c80d246a" ``` The upload scripts directly consume this secret when creating the transaction signer: ```javascript const signer = new ethers.Wallet(process.env.PRIVATE_KEY, provider) ``` ### Technical Analysis A complete Ethereum wallet private key is stored in a project-level `.env` file. Files included in project archives, source-control history, CI artifacts, developer backups, or shared workspaces must be treated as accessible to anyone who can obtain the project. Possession of an Ethereum private key is sufficient to impersonate the wallet. No additional password, host access, or authorization is required to generate valid signatures. The public and encrypted upload scripts load the key through `dotenv` and use it to construct an `ethers.Wallet`, confirming that it is an operational signing credential rather than an inert example value. Because private keys cannot be made safe again by deleting the current file if they have already been distributed, the exposed wallet must be considered compromised. ### Attack Path 1. An attacker obtains a copy of the repository, archive, development workspace, CI artifact, or source-control history. 2. The attacker reads `.env` and extracts the wallet private key. 3. The attacker imports the key into an Ethereum-compatible wallet or uses `ethers.Wallet`. 4. The attacker queries the associated address and balances through a compatible RPC endpoint. 5. The attacker signs and broadcasts arbitrary transactions as that wallet. 6. Any funds, tokens, or protocol permissions controlled by the wallet can be used without the legitimate operator's consent. ### Impact Assessment The attacker obtains the full cryptographic identity and tran ...[truncated 467 chars]
• Remediation: ## Remediation Suggestions 1. Immediately treat the exposed wallet as compromised and rotate to a newly generated key. 2. Transfer any assets and revoke protocol approvals associated with the exposed address. 3. Stop reusing the exposed key on every network and external service. 4. Remove `.env` from the repository and purge it from source-control history and published artifacts. 5. Add `.env` and related secret files to `.gitignore`. 6. Commit only an `.env.example` containing placeholders such as `PRIVATE_KEY=`. 7. Inject the key at runtime through a protected secret manager, CI secret facility, hardware wallet, or restricted environment variable. 8. Add secret scanning to pre-commit and CI workflows to reject wallet keys and similar credentials. 9. Validate that production deployments do not copy secret-bearing files into images, logs, backups, or build artifacts.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:63
• Finding: Encryption Keys Are Exposed Through Plaintext Agent Memory and Process Output## Vulnerability Details **File Location**: `SKILL.md`, lines 63-77 **Vulnerability Type**: Plaintext storage and logging of encryption keys **Risk Level**: High ### Vulnerable Code ```markdown Every secure upload returns a structured JSON response containing `rootHash` and `encryptionKeyHex`. Immediately record both values in the active tracking database or `MEMORY.md` under this dedicated Markdown header: ```markdown # ClawBack Registry Logs - Date: Payload: Root Hash: Encryption Key Hex: Notes: ``` There is no server-side or protocol-level recovery for `encryptionKeyHex`. If the key is lost, the uploaded encrypted state cannot be recovered. Treat the hex key as a private security credential. ``` The upload script also returns and prints the key: ```javascript return { rootHash: tx.rootHash, txHash: tx.txHash, encryptionKeyHex: encryptionKey.toString('hex') } ``` ```javascript console.log('ClawBack Secure Upload Completed Complete!') // Pretty-print the JSON output for the agent framework to read easily console.log(JSON.stringify(result, null, 2)) ``` ### Technical Analysis The script generates a random 256-bit symmetric encryption key, uses it for the storage upload, converts it to hexadecimal, and prints it to standard output. The skill instructions then require the agent to persist that key together with the corresponding root hash in `MEMORY.md` or another active tracking database. This defeats separation between encrypted content and key material. Terminal capture, application logs, CI output, shell-session recording, telemetry, agent transcripts, memory snapshots, project backups, or later ClawBack archives can contain the plaintext key. Storing the root hash and decryption key together further reduces exploitation to obtaining a single record. The issue is amplified by the project's purpose: agent memory and workspace state may include credentials, personal ...[truncated 1399 chars]
• Remediation: ## Remediation Suggestions 1. Store encryption keys in an operating-system keychain, hardware-backed keystore, or dedicated secret manager. 2. Record only a non-secret key identifier or secret-manager reference in `MEMORY.md`. 3. Do not print `encryptionKeyHex` to standard output by default. 4. If one-time key display is necessary, require an explicit flag, write only to an interactive terminal, and clearly warn against logging or transcript capture. 5. Return sensitive values through a protected file descriptor or restricted file with owner-only permissions rather than ordinary console output. 6. Keep root hashes and decryption keys in separate storage systems with independent access controls. 7. Prevent secret-bearing memory files from being included automatically in later archives. 8. Apply restrictive permissions to any temporary key file and securely remove it immediately after import. 9. Document key rotation, backup, recovery, and revocation procedures. 10. Review existing `MEMORY.md` files, logs, and backups for exposed keys and re-encrypt sensitive payloads with newly protected keys where feasible.

T08 · Insecure Dependencies

Warning

• Location: README.md:48
• Finding: Installation Link Displays a Different Repository Than Its Actual Destination## Vulnerability Details **File Location**: `README.md`, line 48 **Vulnerability Type**: Ambiguous and misleading source-repository reference **Risk Level**: Medium ### Vulnerable Code ```markdown git clone [https://github.com/web3senior/clawback.git](https://github.com/mch01-labs/clawback.git) ``` ### Technical Analysis The installation instruction presents `https://github.com/web3senior/clawback.git` as visible text while linking to `https://github.com/mch01-labs/clawback.git`. The repositories identify different GitHub owners. A user who visually verifies the displayed owner but clicks the hyperlink is directed to a different source. Conversely, copying the displayed text and clicking the link produce inconsistent results. The entire line is also Markdown embedded in a shell code block rather than a valid direct `git clone` command. No evidence establishes that either referenced repository is malicious. The confirmed issue is the source ambiguity, which weakens repository provenance and can facilitate supply-chain substitution if either location is compromised or controlled by an unintended party. ### Attack Path 1. A user reviews the visible installation command and believes the source is the `web3senior` repository. 2. The user follows the embedded Markdown hyperlink rather than copying the visible URL. 3. The browser opens the different `mch01-labs` repository. 4. The user clones or downloads that repository without noticing the owner mismatch. 5. The user runs `npm install` and invokes scripts from a source different from the one visually reviewed. 6. If that alternate source is compromised, substituted code or dependency metadata executes with the user's development-account privileges. ### Impact Assessment The direct confirmed impact is loss of reliable source provenance and inconsistent installation behavior. Under a compromised-source scenario, impact could include execution of modified package lifec ...[truncated 321 chars]
• Remediation: ## Remediation Suggestions 1. Select and verify one canonical repository owner and URL. 2. Replace the Markdown hyperlink with a directly executable command: ```bash git clone https://github.com/VERIFIED_OWNER/clawback.git ``` 3. Ensure all documentation, package metadata, badges, and contribution guides use the same canonical source. 4. Recommend installing a signed release or a reviewed, pinned commit rather than an unqualified moving branch. 5. Publish release checksums or signatures where practical. 6. Add automated documentation checks that detect mismatches between visible link text and hyperlink destinations. 7. If ownership was intentionally transferred, document the transfer and configure a clear redirect from the previous repository.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence

Findings (25)

Credential Access

High

• Category: Privilege Escalation

Content

npm install
```

Configure your environment variables by creating a .env file in the root directory:
```bash
RPC_URL="https://evmrpc-testnet.0g.ai"
INDEXER_RPC="https://indexer-storage-testnet-turbo.0g.ai"

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: This variant is security-relevant because the skill frames itself as secure state persistence while instructing users to handle and store `encryptionKeyHex` directly, creating a false sense of protection. The undeclared need for filesystem and environment/wallet access also increases the chance that sensitive data is exposed or recovered into unsafe locations during use.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: This variant is security-relevant because the skill frames itself as secure state persistence while instructing users to handle and store `encryptionKeyHex` directly, creating a false sense of protection. The undeclared need for filesystem and environment/wallet access also increases the chance that sensitive data is exposed or recovered into unsafe locations during use.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: This variant is security-relevant because the skill frames itself as secure state persistence while instructing users to handle and store `encryptionKeyHex` directly, creating a false sense of protection. The undeclared need for filesystem and environment/wallet access also increases the chance that sensitive data is exposed or recovered into unsafe locations during use.

Intent-Code Divergence

High

• Confidence: 97% confidence
• Finding: The document says not to upload or expose sensitive material, yet later requires recording `encryptionKeyHex` in `MEMORY.md` or a tracking database. That key is effectively a secret credential for recovering encrypted backups, so storing it in broadly accessible agent memory or general notes creates a direct confidentiality risk and can defeat the intended protection model.

Description-Behavior Mismatch

High

• Confidence: 96% confidence
• Finding: The script performs a direct upload of an arbitrary local file to a remote 0G indexer/network, but it does not implement any encryption, access control, or confidentiality safeguards despite the skill description claiming secure, encrypted state persistence. That mismatch is security-relevant because users may reasonably trust this tool with sensitive agent memory or state data and unintentionally publish it or otherwise transmit it without protection.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The README promotes uploading agent memories, state snapshots, and evolved skills to decentralized storage without a clear warning about privacy, permanence, and recoverability risks. Because such data may include credentials, prompts, internal reasoning artifacts, or proprietary logic, mistaken publication can create long-lived exposure that is difficult or impossible to revoke.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The README instructs users to place a wallet private key in a .env file without any warning about the sensitivity of that credential. In a web3/storage context, compromise of the private key can enable account takeover, unauthorized transactions, or malicious data operations, especially if users copy the pattern into insecure environments or commit the file accidentally.

Intent-Code Divergence

Medium

• Confidence: 88% confidence
• Finding: The README claims the system encrypts agent state before persistence, but the documented command is explicitly a public upload path. For a skill focused on backing up agent memories and evolved skills to decentralized storage, this mismatch can cause users to upload sensitive state under a false assumption of confidentiality, leading to irreversible exposure on a persistent network.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 70% confidence
• Finding: Without declared permissions the skill's intent is opaque and cannot be validated.

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: The trigger conditions are extremely broad and can cause routine development events to invoke archival and upload behavior. In practice, this can lead to over-collection of local state, accidental persistence of sensitive files, and repeated transmission of data to an immutable public network when no true backup event was intended.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
# Step A: Freeze the current active workspace into a tarball container.
openclaw backup create

# Step B: Parse the absolute path of the generated .tar.gz from the console output.
npm run upload:secret -- <PARSED_FILE_PATH>

• Confidence: 84% confidence
• Finding: The workflow explicitly instructs creating a tarball of the active workspace and uploading it for persistence, which is a form of session/state persistence. In context, this is the skill's purpose, but it is dangerous because active workspaces commonly contain source code, config files, tokens, logs, and other sensitive residue that may be unintentionally archived and retained on a public immutable network.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The instructions normalize placing `encryptionKeyHex` in `MEMORY.md` without a strong warning that this file may be readable by the agent, other tools, backups, or source-control mistakes. This creates a likely local secret exposure path that can allow anyone with access to the note store to decrypt recovered state.

Context-Inappropriate Capability

Medium

• Confidence: 90% confidence
• Finding: The skill directs inspection and classification of broad local memory and identity files, including cross-workspace personal context, beyond what is minimally required for a backup utility. In an agent context, this expands access to sensitive personal and operational data and can normalize exfiltration of high-value local state into archives or uploads.

Context-Inappropriate Capability

Medium

• Confidence: 81% confidence
• Finding: The script loads a PRIVATE_KEY from the environment to construct a signer and perform blockchain-backed upload operations, but the manifest emphasizes encrypted and secured state persistence rather than wallet-based transaction signing as part of its declared scope. While anchoring may require chain interaction, the exposed CLI behavior here is a generic public uploader rather than a clearly bounded state-persistence workflow.

Context-Inappropriate Capability

Medium

• Confidence: 87% confidence
• Finding: The uploadFile function accepts any caller-supplied path, resolves it, and uploads the referenced file to the remote service with no validation that it is an intended state snapshot or safe-to-publish artifact. In the context of an agent skill advertised for secure persistence, this broad capability increases the risk of accidental exfiltration of arbitrary local files such as secrets, configs, or workspace data.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The script uploads a user-specified local file to a remote indexer/network but provides no explicit warning that data will leave the machine and may become publicly exposed or persist externally. That omission is dangerous because users may invoke it on sensitive files under the mistaken belief that the skill provides secure or encrypted state handling.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The script directly reads a sensitive private key from environment variables and immediately constructs a signer without any user-facing notice, confirmation, or scope limitation. In an autonomous agent skill focused on persistence and uploads, silent access to wallet credentials increases the risk of unintended transaction signing or misuse if the skill is invoked in a broader workflow.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The script uploads a local file to a remote 0G storage network without any explicit disclosure, confirmation prompt, or policy gate, which can cause unintentional exfiltration of sensitive data. Although the file is encrypted before upload, the skill also returns the encryption key to the caller, so the overall safety depends entirely on how downstream agent components handle that key.

Intent-Code Divergence

Low

• Confidence: 78% confidence
• Finding: The documentation says encryption uses a public key or wallet-derived password, but the recovery example requires supplying a raw encryption key on the command line. This inconsistency can lead users to mishandle keys, store them insecurely, or misunderstand the actual trust and key-management model protecting their backups.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

"author": "Amir Rahimi",
  "license": "ISC",
  "dependencies": {
    "@0gfoundation/0g-ts-sdk": "^1.2.8",
    "crypto": "^1.0.1",
    "dotenv": "^17.4.2",
    "ethers": "^6.16.0"

• Confidence: 95% confidence
• Finding: The dependency uses a caret version range, which allows automatic installation of newer minor/patch releases. In a security-sensitive skill that handles encrypted state persistence and storage interactions, this increases supply-chain risk because a compromised or breaking upstream release could be pulled without explicit review.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

"license": "ISC",
  "dependencies": {
    "@0gfoundation/0g-ts-sdk": "^1.2.8",
    "crypto": "^1.0.1",
    "dotenv": "^17.4.2",
    "ethers": "^6.16.0"
  }

• Confidence: 98% confidence
• Finding: The package declares an external "crypto" dependency with a floating version range even though Node.js already provides a built-in crypto module. This creates unnecessary supply-chain exposure and possible module confusion, where code may import the external package instead of the trusted built-in cryptography implementation.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

"dependencies": {
    "@0gfoundation/0g-ts-sdk": "^1.2.8",
    "crypto": "^1.0.1",
    "dotenv": "^17.4.2",
    "ethers": "^6.16.0"
  }
}

• Confidence: 90% confidence
• Finding: The dotenv dependency is not pinned to an exact version, so future installs may resolve to different releases. While dotenv is common, unreviewed updates still create a supply-chain risk, especially in a skill likely to manage secrets for uploads and downloads.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

"@0gfoundation/0g-ts-sdk": "^1.2.8",
    "crypto": "^1.0.1",
    "dotenv": "^17.4.2",
    "ethers": "^6.16.0"
  }
}

• Confidence: 94% confidence
• Finding: The ethers dependency is allowed to float within the major version, which can introduce unreviewed code changes into blockchain signing or transaction logic. Because this skill interacts with 0G storage and may rely on cryptographic or wallet operations, dependency drift here can have direct security consequences.

Missing User Warnings

Low

• Confidence: 84% confidence
• Finding: At L13 the code loads a signing key from process.env.PRIVATE_KEY to authorize the upload transaction. There is no visible disclosure in output, comments, or inline documentation warning that sensitive credentials are required and will be used for signing.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: .env:1