@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url
@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
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.
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.
catalog.server.urlA 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.
Fixed in @cardano402/mcp-server@0.1.2:
elicitation/create confirmation hook.127.0.0.1; non-loopback requires --http-bearer-token; per-request Origin allowlist + bearer check.catalog.server.url validated against private-CIDR rules (RFC1918, RFC4193, link-local, CGNAT, multicast, IPv4-mapped IPv6, loopback) unless CARDANO402_ALLOW_INSECURE=true.endpoint.path rejected if it contains .., NUL, whitespace/CRLF, an absolute URL, or //host/....--mainnet-confirmed-tools.--transport http on an untrusted network; use --transport stdio (default).MAINNET=true until upgraded to 0.1.2.왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 0.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 0.00 |
VPI 공식 vpi-v1 기준