USDC Krump EVVM x402 Payment

• Outcome: Review
• Latest audit: May 28, 2026 at 6:01 AM UTC
• Version:
  0.1.2

Overview

This appears to be a real crypto payment skill, but it should be reviewed carefully because it can sign and submit fund-moving transactions while some token, credential, and signing-scope details are unclear.

Install only if you intentionally want to give an agent payment-signing authority. Use a dedicated low-balance testnet wallet, prefer Privy policies with strict spend and contract limits, verify token and adapter addresses before each run, avoid passing real private keys inline in shells or CI, and treat the examples as code that can move funds.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (18)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 93% confidence
• Finding: The skill clearly documents access to environment variables for credentials and network/RPC/API interactions, yet it declares no permissions. This weakens platform trust boundaries because users and orchestrators are not accurately informed that the skill can read secrets and communicate with external services, including blockchain RPCs and Privy APIs.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 87% confidence
• Finding: The documented behavior extends beyond the declared purpose: it references direct x402 transfers, broader token/payment flows, and Privy wallet/signing operations not cleanly captured in the top-level description. That mismatch can cause operators to approve a narrower payment skill while actually granting broader transaction and external-wallet capabilities, increasing the chance of misuse or unsafe deployment.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The security section claims the skill does not store or transmit secrets, but the Privy integration necessarily uses app credentials to authenticate to Privy services. Misstating this can mislead users into underestimating secret exposure and can result in insecure handling assumptions for high-value payment credentials.

Intent-Code Divergence

Medium

• Confidence: 94% confidence
• Finding: The example documentation says the flow pays with USDC.d, while the skill metadata says the skill is for USDC.k on Story Aeneid EVVM. In a payment skill, token/asset confusion is security-relevant because users or integrating agents can send, test, or verify the wrong asset and make incorrect trust decisions about settlement.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: The code defaults to bridge-style adapter and token addresses labeled for USDC.d, which conflicts with the manifest's stated USDC.k EVVM payment purpose. In a financial/payment context this mismatch is dangerous because an agent may transfer funds to the wrong contract or use the wrong asset flow while believing it is executing the declared USDC.k path, causing loss, failed settlement, or incorrect payment verification.

Context-Inappropriate Capability

Medium

• Confidence: 93% confidence
• Finding: The function logs the EVVM core address, hashPayload, full message string, and message length immediately before signing. While this does not print the private key itself, it exposes sensitive payment-signing context, including nonce and transfer parameters indirectly embedded in the hash and message, which can leak operational details into logs, CI output, or telemetry systems beyond the skill's stated purpose. In a payment-signing skill, such leakage is more dangerous because logs may be accessible to operators, other tools, or multi-tenant environments and can aid transaction correlation, replay troubleshooting, and privacy loss.

Intent-Code Divergence

Low

• Confidence: 95% confidence
• Finding: The code emits debug logs containing EVVM service address, hashed payload, full message contents, and message length during payment signing. While this is not a secret like a private key, it exposes payment metadata and signed-message material to logs that may be collected by hosting platforms or shared with operators, increasing privacy leakage and operational risk.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: This signer exposes broad `signMessage` and `signTypedData` capabilities even though the skill is described as payment-focused. In an agent setting, arbitrary message and EIP-712 signing can authorize off-chain logins, attestations, token permits, delegated approvals, or other wallet actions unrelated to USDC payment flow, substantially expanding abuse potential if a prompt, tool, or upstream caller is compromised.

Context-Inappropriate Capability

Medium

• Confidence: 97% confidence
• Finding: Arbitrary message signing is dangerous because signatures can be reused outside the intended payment context for authentication, consent receipts, or malicious workflows that trick users into authorizing actions they do not understand. In this skill, there is no visible restriction tying signed messages to a specific payment protocol or format, so any caller that reaches this method can obtain a wallet-backed signature.

Context-Inappropriate Capability

Medium

• Confidence: 99% confidence
• Finding: Unrestricted EIP-712 signing is especially dangerous because typed-data signatures are commonly used for permits, delegated approvals, marketplace orders, and other actions with direct asset impact. In a payment-only skill, exposing raw `domain`, `types`, and `message` parameters creates a generic signing oracle that could be abused to authorize token approvals or other high-value actions beyond the intended USDC transfer flow.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The function signs typed data using `verifyingContract = explicitVerifyingContract ?? usdcDanceAddress`, but the returned `domainSeparator`/`digest` are recomputed with `usdcDanceAddress` unconditionally. If `verifyingContract` is provided, the metadata no longer represents what was actually signed, which can mislead downstream verification, logging, auditing, or debugging and cause payment failures or incorrect trust decisions. In a payment-signing skill, incorrect signature metadata is especially risky because callers may rely on the returned digest to validate or display transaction details.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The README instructs users to pass private keys directly on the shell command line, which can expose secrets through shell history, process listings, terminal logging, CI logs, and shared session tooling. Because these keys authorize blockchain payments, exposure can lead to irreversible theft of funds or account compromise.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: This example repeats the unsafe pattern of supplying private keys directly in the command invocation without any handling warning. In the context of a payment skill, leaked keys can be immediately abused to sign transactions and move funds, making the risk more serious than a generic secret leak.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The deposit instructions ask the user to perform a live fund movement using a private key, but provide no warning that the operation is irreversible and no guidance on secret hygiene. This combines credential-exposure risk with the possibility of unintentionally depositing or losing real funds on-chain, which is especially dangerous in a blockchain payment workflow.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The example initiates a live payment transaction immediately with caller-provided configuration and no explicit confirmation, simulation, or guardrail before funds are sent. In an agent setting, copy-pasting this pattern can normalize autonomous value transfer, increasing the chance of unintended or prompt-induced payments to attacker-controlled recipients.

Missing User Warnings

Low

• Confidence: 94% confidence
• Finding: These debug statements disclose transaction and payment metadata during signing without any guard, which can leak recipient information, payload structure, and execution details into centralized logs. In an agent/payment environment, such metadata may reveal sensitive business activity or user behavior even if funds are not directly at risk.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: This code forwards arbitrary message content to an external API for signing without any visible approval, warning, or contextual validation. In an agent workflow, that increases the risk of users unknowingly having sensitive or deceptive content signed and shared with a third party, especially because message-signing is already broader than the payment use case.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

"author": "",
  "license": "MIT",
  "dependencies": {
    "ethers": "^6.13.0"
  },
  "devDependencies": {
    "@types/node": "^20.19.33",

• Confidence: 89% confidence
• Finding: "ethers": "^6.13.0"

VirusTotal

64/64 vendors flagged this skill as clean.