lista-wallet-connect

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 0.90). The skill requires the agent to include sensitive values verbatim (WALLETCONNECT_PROJECT_ID example, session topics and pairing URIs passed as CLI args or delivered as URIs) when running commands or delivering fallback URIs, which creates an exfiltration risk.

MEDIUM W011: Third-party content exposure detected (indirect prompt injection risk).

• Third-party content exposure detected (high risk: 0.80). The skill directly queries untrusted public services — it uses external RPC nodes (DEFAULT_EVM_RPCS in rpc.ts), calls the 4byte.directory API in dist/commands/call/simulate.js, and consumes WalletConnect peer/session metadata and deliveryPlan during pairing — and those responses are parsed and used to decide simulation success, revert reasons, delivery fallbacks, and whether to proceed with/suppress transactions, so third-party content can materially influence agent actions.

HIGH W008: Secret detected in skill content (API keys, tokens, passwords).

• Secret detected (high risk: 1.00). I scanned for high-entropy, literal values that look like real credentials. I found one: the WalletConnect project id set in the example export line:

export WALLETCONNECT_PROJECT_ID=c9e9af475f95d71b87da341e0b1e2237

This is a long, random-looking hex string included as the default in skills/lista-wallet-connect/.env — it is a literal, high-entropy value that could be a usable project credential, so it should be treated as a secret. All other values in the document are placeholders (e.g., , 0xADDRESS, sk-xxxx style examples), simple/non-secret tokens, or command examples and were ignored per the provided rules.

MEDIUM W009: Direct money access capability detected (payment gateways, crypto, banking).

• Direct money access detected (high risk: 1.00). The skill is explicitly a WalletConnect/EVM wallet integration that performs signing and on-chain transaction operations. It provides commands to "send-tx" (native and ERC-20 transfers), "call" (eth_sendTransaction / contract transactions), "sign" and "sign-typed-data", and manages sessions/pairing for wallets on Ethereum and BSC. Those are specific crypto/transaction execution capabilities (wallet signing and sending on-chain transactions), not generic tooling. Therefore it grants direct financial execution authority.