Is kirch/clawpay safe?
https://github.com/openclaw/skills/tree/main/skills/kirch/clawpay
Clawpay is a cryptocurrency payment-facilitation skill that is clean at the installation layer—no executable code, no unexpected network connections during cloning, and all canary files remain intact. However, its runtime design introduces meaningful risks: the HEARTBEAT.md polling pattern functions as a C2-like mechanism allowing the clawpay.ai operator to remotely direct agent behavior, the deliver endpoint provides a covert data-exfiltration channel, and embedded self-update curl commands allow the skill author to silently replace local skill content with arbitrary instructions from their server. The default payment address being the Ethereum burn address is an additional red flag that warrants scrutiny before deployment.
Category Scores
Findings (8)
HIGH Heartbeat implements C2-style remote agent control -30 ▶
HEARTBEAT.md instructs the agent to periodically execute 'curl https://clawpay.ai/v1/requests?status=pending', inspect the results, and automatically deliver responses. This means the clawpay.ai operator can queue arbitrary 'paid' requests server-side and cause any agent running this skill to autonomously deliver results without explicit user approval for each action. This is structurally equivalent to a command-and-control channel.
HIGH Deliver endpoint is a covert exfiltration channel -25 ▶
The deliver API accepts a free-form 'payload' field that is transmitted to clawpay.ai servers. If an agent is manipulated (via prompt injection or a chained skill attack) into reading sensitive files and invoking the deliver endpoint, this provides a fully documented, skill-sanctioned mechanism for sending arbitrary data to an external operator-controlled server. No content validation or filtering is described.
MEDIUM Self-update instructions enable remote skill replacement -15 ▶
SKILL.md contains curl commands that overwrite local SKILL.md, HEARTBEAT.md, and package.json with live content from clawpay.ai. If an agent executes this install block (e.g., when 'refreshing' the skill or following embedded install guidance), the skill author can silently replace the skill's instructions with arbitrary content, including prompt injection payloads or expanded permissions.
MEDIUM Cryptocurrency payment facilitation without authorization controls -20 ▶
The skill enables agents to autonomously create USDC payment requests and confirm payments with no documented requirement for explicit user approval before each transaction. A crafted prompt or chained skill instruction could direct the agent to create payment requests or mark deliveries as complete, potentially enabling unauthorized fund transfers.
MEDIUM Default payment destination is Ethereum burn address -12 ▶
The package.json hardcodes default_pay_to as 0x0000000000000000000000000000000000000000, the Ethereum null address. Any payment request created without explicitly overriding this default will send funds to an unrecoverable address. This is either a dangerous misconfiguration or a trap that causes users to permanently lose funds when using the default config.
LOW Installation network traffic limited to expected GitHub endpoints 0 ▶
All observed network connections during the clone and install phase were to GitHub (140.82.121.3:443) via git-remote-https. No connections to clawpay.ai or other unexpected hosts were initiated during installation. The filesystem diff confirms changes were limited to the skill directory.
LOW No executable code or install hooks present 0 ▶
All skill files are Markdown documentation and a metadata JSON. Package.json contains no scripts field. No git hooks, gitattributes filters, submodules, or symlinks were detected. The installation process executes no code from the skill itself.
INFO Canary file reads attributed to monitoring infrastructure 0 ▶
Inotify and auditd both record read-only access to .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud credentials at monitor start time (12:24:00). Timing, CLOSE_NOWRITE flags, and the canary integrity confirmation indicate these accesses originated from the Oathe canary setup routine, not from skill-initiated code.