GHSA-RP72-5V5Q-2446
Vulnerability from github – Published: 2026-06-26 21:08 – Updated: 2026-06-26 21:08Summary
@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/create confirmation hook.
- HTTP transport defaults to 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/....
- Per-tool mainnet opt-in via --mainnet-confirmed-tools.
## Workarounds for 0.1.1 users
- Do not run with --transport http on an untrusted network; use --transport stdio (default).
- Only point the server at catalogs you control or have audited.
- Use a low-balance hot wallet, never your main wallet.
- Avoid MAINNET=true until upgraded to 0.1.2.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.1"
},
"package": {
"ecosystem": "npm",
"name": "@cardano402/mcp-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-770",
"CWE-862",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T21:08:06Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## 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\u0027s 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.",
"id": "GHSA-rp72-5v5q-2446",
"modified": "2026-06-26T21:08:06Z",
"published": "2026-06-26T21:08:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MorganOnCode/cardano402/security/advisories/GHSA-rp72-5v5q-2446"
},
{
"type": "PACKAGE",
"url": "https://github.com/MorganOnCode/cardano402"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.