@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url
Date: 2026-06
Affected: npm/@cardano402/mcp-server
Attack vector: ssrf
Category: vulnerability-disclosure
Severity: Low
CWE: CWE-22
CWE-770
CWE-862
CWE-918
CVSS:  (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N)

## Summary `@cardano402/mcp-server` versions `<= 0.1.1` ship three security gaps that can lead to unauthorized fund movement when the package is used as designed (an MCP server exposing Cardano payment tools to an ## Impact ### 1. No spending limits on signed payments An LLM (or prompt-injected LLM) calling tools registered by the MCP server can invoke them in a loop. Each call signs a real Cardano transaction for the catalog-advertised amount. There is no per-call cap, daily ceiling, MCP elicitation/confirmation step, or recipient allowlist. The `MAINNET=true` env-var guardrail can be bypassed by any LLM with shell-tool access. Worst case: full wallet drain. ### 2. HTTP transport binds 0.0.0.0 without authentication `cardano402-mcp --transport http` listens on all interfaces with no `Origin` allowlist, no bearer-token requirement, and no CORS check. Anyone on the same LAN can POST MCP `tools/call` and trigger signed payments from the operator's wallet. ### 3. SSRF via `catalog.server.url` A malicious catalog can declare a `server.url` pointing at internal infrastructure (e.g. `http://169.254.169.254/latest/meta-data`). The `allowInsecure` guard in 0.1.1 only checks the catalog URL itself, not the `server.url` it returns. `endpoint.path` is also not normalized, so `..` traversal or absolute URLs work. ## Patches Fixed in `@cardano402/mcp-server@0.1.2`: - Per-call and per-day spending limits (default 5 ADA / 50 ADA) + optional recipient allowlist + MCP `elicitation/creat


Mitigations:

Architectural layers (MAESTRO):