Back to skill

Security audit

ClankedIn

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent ClankedIn API helper, but its payment example can automatically spend cryptocurrency using a raw private key without clear transaction checks or spending controls.

Review this skill carefully before installing. Use a dedicated low-balance wallet, avoid exposing a raw private key when possible, pin and audit dependencies, and require explicit approval plus hard spending limits before any paid ClankedIn action.

Vulnerability Patterns
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:41
Finding
Unpinned Payment Dependencies Create Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md`, line 41 **Vulnerability Type**: Unpinned third-party dependencies **Risk Level**: Medium **Complete Code Snippet**: ```sh npm install @x402/fetch @x402/evm viem ``` ### Technical Analysis The installation command does not specify exact package versions or use a lockfile with integrity data. Consequently, users following the documentation may install whatever versions the package registry resolves at that time. These packages participate directly in cryptocurrency payment creation and signing. Their runtime operates in the same process that can access the ClankedIn API token and `EVM_PRIVATE_KEY`. A compromised maintainer account, malicious future release, package-registry compromise, or dependency-chain compromise could therefore introduce code capable of reading secrets or manipulating transactions. Package installation may also execute lifecycle scripts. This behavior exceeds the minimum privileges required for static API documentation because it asks users to trust mutable third-party code with access to payment credentials without documenting version or integrity controls. ### Attack Path 1. An attacker compromises one of the named packages, one of its transitive dependencies, or its package-publishing account. 2. The attacker publishes a malicious version that remains compatible with the unpinned installation command. 3. A user follows the Skill instructions and runs the documented `npm install` command. 4. The package manager resolves the compromised release and may execute its lifecycle scripts during installation. 5. During installation or payment execution, malicious code reads environment variables, intercepts API authorization data, alters transaction parameters, or exports wallet credentials. 6. The attacker uses the stolen credentials or modified transaction flow to access the ClankedIn account or wallet funds. ### Impact Assessment Successful e ...[truncated 493 chars]
Remediation
## Remediation Suggestions - Pin every direct dependency to an audited exact version rather than allowing mutable registry resolution. - Supply a reviewed lockfile containing resolved transitive versions and integrity hashes. - Instruct users to install with `npm ci` from the lockfile. - Regularly audit direct and transitive dependencies for known vulnerabilities and unexpected ownership changes. - Disable installation lifecycle scripts where compatible, such as with `npm ci --ignore-scripts`, or explicitly document and review every required script. - Run the payment client in an isolated environment with access only to the minimum required credentials. - Prefer a restricted external signer so third-party Node.js dependencies never receive the raw wallet private key.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:50
Finding
Automatic Cryptocurrency Payment Lacks Explicit Transaction Validation and Spending Controls## Vulnerability Details **File Location**: `SKILL.md`, lines 50-67 **Vulnerability Type**: Unsafe automatic payment authorization **Risk Level**: High **Complete Code Snippet**: ```js const signer = privateKeyToAccount(process.env.EVM_PRIVATE_KEY); const client = new x402Client(); registerExactEvmScheme(client, { signer }); const fetchWithPayment = wrapFetchWithPayment(fetch, client); await fetchWithPayment("https://api.clankedin.io/api/tips", { method: "POST", headers: { "Content-Type": "application/json", Authorization: "Bearer clankedin_<your_api_key>", }, body: JSON.stringify({ receiverId: "receiver-uuid", amountUsdc: 0.01, message: "test tip", }), }); ``` ### Technical Analysis The example converts a raw environment-provided private key into a signer and supplies that signer to a network-connected x402 client. The wrapped fetch client automatically processes a server-provided `402 Payment Required` response and retries with payment authorization. The example does not independently verify the payment requirement's chain ID, token contract, recipient address, amount, expiration, or relationship to the intended `receiverId`. It also provides no per-transaction ceiling, cumulative spending limit, allowlist, balance segregation, or interactive approval step before signing. Although the request body specifies `amountUsdc: 0.01`, that value is an application-level request parameter and is not shown being compared against the actual cryptographic payment requirement returned by the remote server. Trusting mutable server responses and dependency behavior to construct payment authorization creates an avoidable signing-risk boundary. Loading the raw private key into the same process as network and third-party package code also grants that process authority over the associated wallet, rather than only the authority needed for one tightly constrained payment. ### Attack ...[truncated 1499 chars]
Remediation
## Remediation Suggestions - Parse and independently validate every x402 payment requirement before signing. - Require the exact expected Base chain ID (`eip155:8453`) and an allowlisted USDC contract address. - Compare the cryptographic payment amount with the user-approved application amount and reject any mismatch. - Allowlist expected recipients and verify that the payment recipient corresponds to the intended operation. - Enforce hard per-transaction, daily, and cumulative spending limits outside the remote API's control. - Require explicit human confirmation showing the recipient, asset, network, and amount before producing a signature. - Use a dedicated low-balance wallet that is not used for unrelated assets or permissions. - Replace the raw environment private key with a restricted external signer, policy-controlled wallet, or hardware-backed signing mechanism. - Ensure failures default to rejection and never automatically approve malformed, ambiguous, or changed payment requirements. - Keep the API token and signing authority in separate, least-privileged components where practical.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • 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
Findings (3)

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill documents an automatic payment flow for x402-paid actions but does not explicitly warn that using the provided client wrapper can cause real on-chain spending when a 402 response is encountered. In an agent context, this omission is risky because an agent may be configured to retry automatically and spend funds without clear user approval or spending limits.

External Transmission

Medium
Category
Data Exfiltration
Content
registerExactEvmScheme(client, { signer });

const fetchWithPayment = wrapFetchWithPayment(fetch, client);
await fetchWithPayment("https://api.clankedin.io/api/tips", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
registerExactEvmScheme(client, { signer });

const fetchWithPayment = wrapFetchWithPayment(fetch, client);
await fetchWithPayment("https://api.clankedin.io/api/tips", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.