Warden Messari Agent

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:43 PM UTC
• Version: 1.0.0

Overview

This skill is a coherent guide for querying a paid crypto research agent, but its payment instructions could authorize real USDC transfers without enough local spending controls or confirmation guidance.

Review the payment path before installing or using this skill. Use a low-balance dedicated wallet, require explicit approval for every paid request, and enforce local checks for network, USDC contract, recipient, amount, facilitator, and authorization expiry before signing. Pin and review any x402 client dependency instead of installing an unconstrained latest package.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:201
• Finding: Remote Payment Parameters Are Signed Without a Mandatory Local Spending Policy<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 201–215 **Vulnerability Type**: Insufficient validation of wallet payment authorization parameters **Risk Level**: High ### Vulnerable Code Snippet ```text ### Constructing the Payment Header For EVM networks (Base), the payment uses EIP-3009 (transferWithAuthorization on the USDC contract): 1. Parse the `PAYMENT-REQUIRED` header and select a payment option from `accepts` 2. Build an EIP-712 typed data structure with `from`, `to`, `value`, `validAfter`, `validBefore`, and `nonce` 3. Sign it with the client wallet's private key 4. Base64-encode the signed payload 5. Include it as `X-PAYMENT: <base64-payload>` The client does NOT submit a blockchain transaction. The authorization is gasless. The x402 facilitator submits the signed transfer on-chain on behalf of the client. ``` ### Technical Analysis The documented procedure instructs clients to parse payment parameters supplied by the remote endpoint and sign an EIP-3009 transfer authorization. It does not require the client to independently validate the requested network, token contract, recipient, transfer amount, authorization lifetime, or facilitator against a trusted local policy. The Skill states that a request costs $0.25 USDC, but the signing flow does not mandate an enforcement check that rejects any authorization exceeding that amount. It also does not require explicit user approval after displaying the final typed-data fields. An EIP-3009 authorization is not merely an authentication signature. It can authorize an on-chain token transfer when submitted by a facilitator. Consequently, blindly signing server-provided parameters exceeds the minimum privilege needed to pay the advertised fixed request price. ### Attack Path 1. The user or agent contacts the documented endpoint and receives an HTTP 402 response. 2. The endpoint, an intermediary, or compromised service supplies manipulated `PAYMENT-REQUIRED` parameters. 3. Th ...[truncated 1041 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Enforce a trusted local payment policy before signing: - Require network `eip155:8453`. - Require the expected Base USDC contract address. - Require an independently verified recipient address. - Reject any amount above exactly $0.25 USDC per request. - Reject unsupported schemes and facilitators. 2. Compare all server-provided payment fields against the agent card and a separately configured local allowlist. 3. Display the network, token, recipient, amount, and expiration to the user and require explicit confirmation before each signature. 4. Use short authorization validity periods and cryptographically random, single-use nonces. 5. Reject malformed, ambiguous, duplicated, or unexpectedly encoded payment requirements. 6. Use a dedicated low-balance wallet rather than a primary treasury or personal wallet. 7. Log payment decisions and settlement references without logging private keys or reusable authorization data. 8. Ensure redirects cannot silently change the payment recipient or destination origin. ]]>

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:220
• Finding: Unpinned npm Dependency Is Installed Into a Wallet-Capable Environment<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 220–246 **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Medium ### Vulnerable Code Snippet ```bash npm install @x402/client ``` ```typescript import { paymentFetch } from "@x402/client"; const response = await paymentFetch( "https://messari.agents.wardenprotocol.org/", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ jsonrpc: "2.0", method: "message/send", params: { message: { role: "user", parts: [{ type: "text", text: "What is Ethereum's TVL?" }] } }, id: "req-002" }) }, walletClient // viem WalletClient with USDC approval ); const result = await response.json(); ``` ### Technical Analysis The installation command does not pin `@x402/client` to a reviewed version or integrity-protected lockfile. It therefore resolves to whichever compatible release npm serves at installation time. npm dependencies and their transitive dependencies may also execute lifecycle scripts during installation. This risk is amplified because the installed package is subsequently invoked with `walletClient`, a wallet-capable object used to generate payment authorizations. A malicious or compromised package release could inspect wallet-related runtime data, alter payment requests, request deceptive signatures, access environment variables, or execute arbitrary code under the installing user's operating-system privileges. The audit found no evidence that the currently named package is malicious. The vulnerability is the unsafe, mutable dependency acquisition procedure documented by the Skill. ### Attack Path 1. An attacker compromises the package publisher, npm account, release pipeline, or a transitive dependency. 2. The attacker publishes a malicious package version under the expected package name. 3. A user follows the Skill and runs `n ...[truncated 1002 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the package to an exact version that has been reviewed, rather than using an unconstrained install command. 2. Commit a lockfile and use `npm ci` for reproducible dependency resolution. 3. Verify package provenance, publisher identity, release signatures, and registry source. 4. Review and monitor all transitive dependencies. 5. Use lockfile integrity hashes and reject unexpected dependency changes during CI. 6. Disable lifecycle scripts where operationally possible, such as with `npm ci --ignore-scripts`, and explicitly review any required scripts. 7. Run the payment client in an isolated, minimally privileged process with restricted filesystem and environment access. 8. Keep wallet confirmation controls enabled and use a dedicated low-balance wallet with strict spending limits. 9. Add automated dependency scanning and require manual review before upgrading the pinned version. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (6)

External Transmission

Medium

• Category: Data Exfiltration

Content

curl -s https://messari.agents.wardenprotocol.org/.well-known/agent-card.json | jq .

# Send a query (will return 402 if payments are enabled)
curl -s -X POST https://messari.agents.wardenprotocol.org/ \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",

• Confidence: 60% 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

}
```

### Minimal curl Example (Without Payment)

This will return a 402 if payments are enabled. Useful for testing connectivity.

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The payment section describes how to construct and submit a signed `X-PAYMENT` authorization, but it does not prominently warn users that a successful request can trigger a real USDC transfer. In a skill that facilitates paid requests, weak disclosure can cause unintended financial loss, especially if an agent or user automates repeated queries without clear consent boundaries.

External Transmission

Medium

• Category: Data Exfiltration

Content

```typescript
import { paymentFetch } from "@x402/client";

const response = await paymentFetch(
  "https://messari.agents.wardenprotocol.org/",
  {
    method: "POST",

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Intent-Code Divergence

Low

• Confidence: 95% confidence
• Finding: The quick reference at L019 says a 'streaming query' can be sent with JSON-RPC SSE, but the capability section at L025 explicitly says streaming is not supported in the current version. This is an active contradiction in the file's own documentation about supported behavior.

Intent-Code Divergence

Low

• Confidence: 88% confidence
• Finding: The message-parts table documents `file` and `data` request structures as usable types, but L164 states that this specific agent only accepts and returns `text` parts. That creates an intent/documentation contradiction about what inputs are actually supported for this skill.