# GHSA-rp72-5v5q-2446: @cardano402/mcp-server missing spending limits, LAN-exposed HTTP transport, and SSRF via catalog.server.url

> Attackers can trigger SSRF to access internal metadata or drain funds via unauthenticated LAN access and missing spending limits in the Cardano MCP server.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 26 Jun 2026

## What is GHSA-rp72-5v5q-2446?

GHSA-rp72-5v5q-2446 is a server-side request forgery vulnerability in @cardano402/mcp-server, published on 26 Jun 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official 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.

## Which versions are affected by GHSA-rp72-5v5q-2446?

2 open source packages ship an affected version, including @cardano402/mcp-server.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@cardano402/mcp-server` | npm | All versions | 0.1.2 |
| `@cardano402/mcp-server` | npm | All versions | 0.1.2 |

## How do I fix GHSA-rp72-5v5q-2446?

Upgrade @cardano402/mcp-server to 0.1.2 or later.

## Is GHSA-rp72-5v5q-2446 being exploited?

There is no known exploitation of GHSA-rp72-5v5q-2446 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-rp72-5v5q-2446 and fix it if it is affected.

What it is: GHSA-rp72-5v5q-2446 is a server-side request forgery vulnerability in @cardano402/mcp-server, published on 26 Jun 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-rp72-5v5q-2446 in the wild and no public exploit code.

Affected packages and fixed versions:
- @cardano402/mcp-server (npm): affected all versions; fixed in 0.1.2
- @cardano402/mcp-server (npm): affected all versions; fixed in 0.1.2

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-rp72-5v5q-2446/ (Markdown: https://insights.sbomify.com/GHSA-rp72-5v5q-2446/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-rp72-5v5q-2446

---
From sbomify Insights: https://insights.sbomify.com/GHSA-rp72-5v5q-2446/
Summaries are generated and may contain mistakes; the official description above is the record.