{"id":"GHSA-rp72-5v5q-2446","aliases":[],"status":"published","title":"@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url","description":"## Summary\n`@cardano402/mcp-server` versions `\u003c= 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\n\n## Impact\n### 1. No spending limits on signed payments\nAn 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.\n\n### 2. HTTP transport binds 0.0.0.0 without authentication\n`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.\n\n### 3. SSRF via `catalog.server.url`\nA 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.\n\n## Patches\nFixed in `@cardano402/mcp-server@0.1.2`:\n  - Per-call and per-day spending limits (default 5 ADA / 50 ADA) + optional recipient allowlist + MCP `elicitation/create` confirmation hook.\n  - HTTP transport defaults to `127.0.0.1`; non-loopback requires `--http-bearer-token`; per-request `Origin` allowlist + bearer check.\n  - `catalog.server.url` validated against private-CIDR rules (RFC1918, RFC4193, link-local, CGNAT, multicast, IPv4-mapped IPv6, loopback) unless `CARDANO402_ALLOW_INSECURE=true`.\n  - `endpoint.path` rejected if it contains `..`, NUL, whitespace/CRLF, an absolute URL, or `//host/...`.\n  - Per-tool mainnet opt-in via `--mainnet-confirmed-tools`.\n\n  ## Workarounds for 0.1.1 users\n  - Do not run with `--transport http` on an untrusted network; use `--transport stdio` (default).\n  - Only point the server at catalogs you control or have audited.\n  - Use a low-balance hot wallet, never your main wallet.\n  - Avoid `MAINNET=true` until upgraded to 0.1.2.","severity":{"version":"3.1","score":0,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N","level":"none","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-22","CWE-770","CWE-862","CWE-918"],"published":"2026-06-26T21:08:06Z","modified":"2026-09-10T03:50:50Z","fixes":[{"ecosystem":"npm","package":"@cardano402/mcp-server","fixed_in":["0.1.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@cardano402/mcp-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.1.1"},{"fixed":"0.1.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@cardano402/mcp-server","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.1.2"}]}]}],"references":[{"url":"https://github.com/MorganOnCode/cardano402/security/advisories/GHSA-rp72-5v5q-2446","tags":["web"]},{"url":"https://github.com/advisories/GHSA-rp72-5v5q-2446"},{"url":"https://github.com/MorganOnCode/cardano402","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-rp72-5v5q-2446","title":"@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url","description":"## Summary\n`@cardano402/mcp-server` versions `\u003c= 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\n\n## Impact\n### 1. No spending limits on signed payments\nAn 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.\n\n### 2. HTTP transport binds 0.0.0.0 without authentication\n`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.\n\n### 3. SSRF via `catalog.server.url`\nA 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.\n\n## Patches\nFixed in `@cardano402/mcp-server@0.1.2`:\n  - Per-call and per-day spending limits (default 5 ADA / 50 ADA) + optional recipient allowlist + MCP `elicitation/create` confirmation hook.\n  - HTTP transport defaults to `127.0.0.1`; non-loopback requires `--http-bearer-token`; per-request `Origin` allowlist + bearer check.\n  - `catalog.server.url` validated against private-CIDR rules (RFC1918, RFC4193, link-local, CGNAT, multicast, IPv4-mapped IPv6, loopback) unless `CARDANO402_ALLOW_INSECURE=true`.\n  - `endpoint.path` rejected if it contains `..`, NUL, whitespace/CRLF, an absolute URL, or `//host/...`.\n  - Per-tool mainnet opt-in via `--mainnet-confirmed-tools`.\n\n  ## Workarounds for 0.1.1 users\n  - Do not run with `--transport http` on an untrusted network; use `--transport stdio` (default).\n  - Only point the server at catalogs you control or have audited.\n  - Use a low-balance hot wallet, never your main wallet.\n  - Avoid `MAINNET=true` until upgraded to 0.1.2.","status":"published","published":"2026-06-26T21:08:06Z","modified":"2026-06-26T21:08:06Z","cvss":[{"version":"3.1","score":0,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N","level":"none"}],"cwes":["CWE-22","CWE-770","CWE-862","CWE-918"],"updated_at":"2026-11-02T14:40:34.713036Z"}],"osv":[{"id":"GHSA-rp72-5v5q-2446","title":"@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url","description":"## Summary\n`@cardano402/mcp-server` versions `\u003c= 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\n\n## Impact\n### 1. No spending limits on signed payments\nAn 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.\n\n### 2. HTTP transport binds 0.0.0.0 without authentication\n`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.\n\n### 3. SSRF via `catalog.server.url`\nA 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.\n\n## Patches\nFixed in `@cardano402/mcp-server@0.1.2`:\n  - Per-call and per-day spending limits (default 5 ADA / 50 ADA) + optional recipient allowlist + MCP `elicitation/create` confirmation hook.\n  - HTTP transport defaults to `127.0.0.1`; non-loopback requires `--http-bearer-token`; per-request `Origin` allowlist + bearer check.\n  - `catalog.server.url` validated against private-CIDR rules (RFC1918, RFC4193, link-local, CGNAT, multicast, IPv4-mapped IPv6, loopback) unless `CARDANO402_ALLOW_INSECURE=true`.\n  - `endpoint.path` rejected if it contains `..`, NUL, whitespace/CRLF, an absolute URL, or `//host/...`.\n  - Per-tool mainnet opt-in via `--mainnet-confirmed-tools`.\n\n  ## Workarounds for 0.1.1 users\n  - Do not run with `--transport http` on an untrusted network; use `--transport stdio` (default).\n  - Only point the server at catalogs you control or have audited.\n  - Use a low-balance hot wallet, never your main wallet.\n  - Avoid `MAINNET=true` until upgraded to 0.1.2.","status":"published","published":"2026-06-26T21:08:06Z","modified":"2026-09-10T03:50:50.562901781Z","cvss":[{"version":"3.1","score":0,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N","level":"none"}],"cwes":["CWE-22","CWE-770","CWE-862","CWE-918"],"updated_at":"2026-11-02T15:46:56.281047Z"}]}}