Back to skill

Security audit

Zooidfund Skill

Security checks for vulnerabilities and agentic risk

Overview

This skill is a transparent donation workflow for zooid.fund, but users should treat the wallet, MCP adapter, hosted service, and irreversible payments with care.

Start in read-only mode, use a dedicated low-balance Base USDC wallet, require manual approval before registration, evidence payments, or transfers, and independently review any wallet skill or MCP adapter before giving it API keys or signing authority.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:60
Finding

Unpinned and Unaudited Third-Party Wallet Integration

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:60
Vulnerability Type: Unpinned third-party dependency with access to wallet credentials and transaction authority
Risk Level: Medium

Vulnerable Code Snippet

markdown
**Your agent has no wallet skill yet.** The most direct option is [`Ales375/openclaw-cdp-wallet-skill`](https://github.com/Ales375/openclaw-cdp-wallet-skill) — a minimal wrapper around the official Coinbase CDP server wallet SDK. Three env vars, one command to get the wallet's address, keys held in Coinbase's TEE infrastructure. Handles both donation transfers and x402 evidence-access settlement using the same CDP credentials, so one wallet skill covers everything zooidfund needs. Other valid options that handle both: Coinbase's `agentic-wallet-skills` package (consumer wallet, requires interactive auth — heavier setup), or a custom integration using the `x402` and `@coinbase/cdp-sdk` packages directly. Options that handle donations only (no x402): basic OnchainKit `send-usdc` skills, viem-based EOA `send-usdc` skills, Bankr-style hosted wallets without explicit x402 support. Pick a both-capable option if you want evidence access; pick a donations-only option if you're fine reasoning from prose alone.

Technical Analysis

The Skill recommends installing an external wallet Skill using a mutable repository reference without specifying an immutable commit, verified release, package checksum, or reproducible dependency lock. The referenced component would handle Coinbase CDP credentials, x402 payment authorizations, donation destinations, and transaction submission.

Because the external implementation is not included in the audited project, its behavior cannot be verified from this artifact. If the repository, maintainer account, release process, or transitive dependencies were compromised, later installations could execute code different from the version that an operator previously reviewed.

The wa ...[truncated 1678 chars]

Remediation
View remediation

Remediation Suggestions

  1. Pin the recommended wallet Skill to an immutable, reviewed commit hash or cryptographically signed release rather than a mutable repository reference.
  2. Publish the expected package version, commit identifier, checksums, and exact installation command.
  3. Audit and lock all transitive dependencies using a committed lockfile and integrity metadata.
  4. Prefer reproducible builds and signed release artifacts with documented verification steps.
  5. Require operators to review the wallet Skill independently before providing CDP credentials or signing authority.
  6. Use a dedicated donation wallet with a minimal balance and enforce wallet-layer per-transaction and cumulative spending limits.
  7. Restrict signing policies to Base, the expected USDC contract, approved x402 facilitator contracts, and operator-approved maximum amounts.
  8. Display and independently validate the chain, token contract, recipient, and amount immediately before each signature.
  9. Document credential revocation and wallet-rotation procedures for suspected dependency compromise.

T08 · Insecure Dependencies

Warning
Location
SKILL.md:157
Finding

Unconstrained Installation of Community MCP Adapters

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:157
Vulnerability Type: Unpinned community dependency with access to authenticated MCP traffic
Risk Level: Medium

Vulnerable Code Snippet

markdown
OpenClaw does not ship first-party MCP support. Install one of the community adapters from ClawHub (`androidStern-personal/openclaw-mcp-adapter`, `Helms-AI/openclaw-mcp-server`, or others) and configure it per that adapter's docs. Same endpoint URL.

Technical Analysis

The Skill directs operators to install community MCP adapters without pinning a version, commit, checksum, or audited implementation. The phrase “or others” leaves component selection open-ended and provides no security criteria for determining whether an adapter is trustworthy.

An MCP adapter occupies a privileged interception point between the agent and the hosted service. After registration, it may process the ZOOIDFUND_API_KEY bearer token and all tool requests and responses. It could therefore observe or alter campaign identifiers, donation reasoning, registration data, evidence URLs, payment instructions, and transaction-confirmation data.

This is a supply-chain and trust-boundary concern rather than evidence that either specifically named adapter is malicious. The risk arises because executable third-party components are recommended without immutable provenance or validation requirements.

Attack Path

  1. An operator selects and installs a community adapter based on the Skill instructions.
  2. The selected adapter is malicious, has been compromised, or later receives a malicious update.
  3. The operator configures the adapter to connect to the zooidfund MCP endpoint and attach the bearer API key.
  4. The adapter captures the API key or changes MCP requests and responses.
  5. The attacker uses the stolen key for authenticated operations or substitutes malicious payment instructions in the data shown to the agent.
  6. If the alte ...[truncated 795 chars]
Remediation
View remediation

Remediation Suggestions

  1. Replace the open-ended adapter recommendation with a short allowlist of reviewed implementations.
  2. Pin each approved adapter to an immutable commit or signed release and publish its expected checksum.
  3. Provide a documented source-review and permission-review process before installation.
  4. Require adapters to obtain only the zooidfund-specific bearer token, not unrelated agent or wallet secrets.
  5. Isolate the adapter in a restricted process or container with minimal filesystem, environment, and network access.
  6. Configure outbound network allowlisting so the adapter can communicate only with the documented MCP endpoint where feasible.
  7. Independently verify donation recipient, amount, token contract, and Base network outside the adapter before authorizing a transfer.
  8. Add API-key rotation and revocation support, and instruct operators to rotate the key immediately after suspected adapter compromise.
  9. Avoid instructions such as “or others” unless explicit trust, provenance, and verification requirements are supplied.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.