Skip to content

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

Low severity GitHub Reviewed Published May 25, 2026 in MorganOnCode/cardano402

Package

npm @cardano402/mcp-server (npm)

Affected versions

<= 0.1.1

Patched versions

0.1.2

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.

References

@MorganOnCode MorganOnCode published to MorganOnCode/cardano402 May 25, 2026
Published to the GitHub Advisory Database Jun 26, 2026
Reviewed Jun 26, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N

EPSS score

Weaknesses

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Learn more on MITRE.

Allocation of Resources Without Limits or Throttling

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. Learn more on MITRE.

Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action. Learn more on MITRE.

Server-Side Request Forgery (SSRF)

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. Learn more on MITRE.

CVE ID

No known CVE

GHSA ID

GHSA-rp72-5v5q-2446

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.