Every CVESearch/Get API key

GHSA-rp72-5v5q-2446

@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url

0.0 NoneFix available

GHSA-rp72-5v5q-2446 is a none vulnerability (CVSS 0.0) in @cardano402/mcp-server, published June 26, 2026. No source lists public exploit code. Fixed in @cardano402/mcp-server 0.1.2.

Severity
0.0 NoneCVSS 3.1, GitHub Advisories
Exploit chance
UnscoredNo EPSS score yet
Exploitation
None knownNot on CISA’s or ENISA’s lists

Description

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/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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
None

Affected packages

Affected packages
PackageAffectedFixed
@cardano402/mcp-server
npm
through 0.1.1
0.1.2
@cardano402/mcp-server
npm
before 0.1.2
0.1.2

What each source reports

GitHub Advisories Score used0.0

@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url

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/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.
Record
GHSA-rp72-5v5q-2446
CVSS 3.1
0.0 NoneCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
Weakness
CWE-22, CWE-770, CWE-862, CWE-918
Updated
2026-11-02
OSV0.0

@cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url

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/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.
Record
GHSA-rp72-5v5q-2446
CVSS 3.1
0.0 NoneCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
Weakness
CWE-22, CWE-770, CWE-862, CWE-918
Updated
2026-11-02

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

References

MoveEnter Open