Resumen

@cardano402/mcp-server en versiones <= 0.1.1 presenta tres brechas de seguridad que pueden derivar en movimiento no autorizado de fondos cuando el paquete se utiliza según su diseño previsto: un servidor MCP que expone herramientas de pago Cardano a un agente de IA.

Impacto

1. Ausencia de límites de gasto en pagos firmados

Un LLM (o un LLM comprometido mediante inyección de prompt) que invoque las herramientas registradas por el servidor MCP puede llamarlas en bucle. Cada llamada firma una transacción Cardano real por el importe anunciado en el catálogo. No existe ningún tope por llamada, límite diario, paso de confirmación mediante elicitación MCP ni lista de destinatarios permitidos.

La variable de entorno MAINNET=true, concebida como salvaguarda, puede ser eludida por cualquier LLM con acceso a herramientas de shell. En el peor caso, el resultado es el vaciado completo de la billetera.

2. Transporte HTTP enlazado a 0.0.0.0 sin autenticación

Al ejecutar cardano402-mcp --transport http, el servidor escucha en todas las interfaces de red sin lista de orígenes permitidos, sin requisito de token bearer y sin verificación CORS. Cualquier equipo en la misma LAN puede enviar una petición POST con tools/call de MCP y desencadenar pagos firmados desde la billetera del operador.

3. SSRF mediante catalog.server.url

Un catálogo malicioso puede declarar un campo server.url apuntando a infraestructura interna, por ejemplo:

code
http://169.254.169.254/latest/meta-data

La comprobación allowInsecure presente en la versión 0.1.1 solo valida la URL del catálogo en sí, no el valor de server.url que este devuelve. Adicionalmente, el campo endpoint.path no se normaliza, por lo que son funcionales tanto la traversal con .. como el uso de URLs absolutas.

Parches

Corregido en @cardano402/mcp-server@0.1.2 con las siguientes medidas:

  • Límites de gasto por llamada y por día (5 ADA y 50 ADA por defecto), lista opcional de destinatarios permitidos y gancho de confirmación mediante elicitation/create de MCP.
  • El transporte HTTP enlaza por defecto a 127.0.0.1. El uso en interfaces no loopback requiere --http-bearer-token. Se añade lista de orígenes permitidos por petición y verificación de token bearer.
  • catalog.server.url se valida contra reglas de CIDR privado (RFC1918, RFC4193, link-local, CGNAT, multicast, IPv6 mapeado a IPv4, loopback) salvo que se establezca CARDANO402_ALLOW_INSECURE=true.
  • endpoint.path es rechazado si contiene .., NUL, espacios en blanco o CRLF, una URL absoluta o la secuencia //host/....
  • Habilitación de mainnet por herramienta individual mediante --mainnet-confirmed-tools.

Mitigaciones para usuarios de la versión 0.1.1

Para quienes no puedan actualizar de inmediato, se recomiendan las siguientes medidas paliativas:

  • No ejecutar el servidor con --transport http en redes no confiables. Utilizar --transport stdio (opción por defecto).
  • Apuntar el servidor únicamente a catálogos propios o que hayan sido auditados previamente.
  • Emplear una billetera caliente con saldo reducido y nunca la billetera principal.
  • Evitar el uso de MAINNET=true hasta haber actualizado a la versión 0.1.2.