01Alcance e inventario
Todo empieza por definir el objeto de la auditoría: transporte (stdio, Streamable HTTP o la vía obsoleta HTTP+SSE), revisión del protocolo y las tres partes implicadas: servidor, cliente/host y pasarela. Solo la revisión determina qué clases de ataque existen realmente; el secuestro de sesión mediante la cabecera Mcp-Session-Id, por ejemplo, ya no existe en la revisión 2026-07-28, mientras que se incorporan los state handles y la validación de cabecera y cuerpo. Catalogamos cada servidor, cada herramienta con su definición completa, cada credencial y cada sistema de destino accesible a través de ella, y fijamos por escrito de antemano con qué identidades de prueba y ámbitos se trabaja, ya que tools/list puede variar según la autorización presentada. Las propias herramientas de auditoría forman parte del alcance: el MCP Inspector —la herramienta de prueba oficial del proyecto— fue objeto de una vulnerabilidad crítica con CVE-2025-49596, corregida únicamente a partir de la versión 0.14.1; por ello debe llevarse su versión controlada e indicarse en el informe.
02Identidad y permisos (MCP07, MCP02)
Aquí auditamos frente a requisitos normativos y no frente a criterios de gusto: una llamada a una herramienta sin token o con un token inválido debe terminar con un 401 y una cabecera WWW-Authenticate correcta, y la cadena de discovery debe existir y estar correctamente enlazada. Conviene distinguir: los Protected Resource Metadata según RFC 9728 son obligatorios para los servidores MCP, mientras que en el servidor de autorización basta con RFC 8414 u OpenID Connect Discovery 1.0 indistintamente; quien solo comprueba RFC 8414 genera un falso hallazgo en servidores OIDC. Para las URL de OAuth, la especificación exige HTTPS fuera de las direcciones de loopback. El caso de prueba central es la validación de la audience, ya que la especificación prohíbe expresamente el token passthrough: un servidor no debe aceptar tokens que no se hayan emitido para él. En arquitecturas de proxy se añade la vía del confused deputy: página de consentimiento propia por cliente, comparación exacta de cadenas de la redirect_uri sin comodines y parámetro state generado criptográficamente y de un solo uso. De forma complementaria comprobamos la minimización de ámbitos: ámbitos comodín o genéricos, privilegios agrupados y servidores que confían en el claim de ámbito del token sin autorizar por sí mismos.
03Definiciones de herramientas: poisoning, shadowing, rug pull (MCP03)
Las descripciones de herramientas, la documentación de parámetros y los esquemas JSON son un canal de instrucciones que el modelo lee como autoritativo y que la persona, por regla general, nunca ve por completo en la interfaz. Primero generamos una línea base: cada definición de tools/list, resources/list y prompts/list se somete a hash campo por campo y sirve de referencia para comparaciones posteriores. A continuación se realizan tres comprobaciones: el contraste entre el texto visible en el cliente y la descripción realmente entregada al modelo, la prueba controlada de rug pull en el entorno de pruebas (si cambia una definición ya aprobada, el host debe volver a solicitar consentimiento o notificar el cambio) y la prueba de shadowing con dos servidores conectados en paralelo que ofrecen herramientas con el mismo nombre o funcionalmente solapadas. La clase está acreditada en la práctica: con CVE-2025-54136 en Cursor, los cambios en configuraciones MCP ya aprobadas surtían efecto sin un nuevo consentimiento.
04Inyección de prompt indirecta a través de salidas de herramientas (MCP06)
No solo la descripción, también el lado de la respuesta es superficie de ataque: la especificación obliga expresamente a los servidores a sanear las salidas de las herramientas (MUST) y recomienda a los clientes validar los resultados antes de entregarlos al modelo (SHOULD); el requisito más débil en el lado del cliente debe reflejarse en la redacción del hallazgo. Primero inventariamos todos los canales por los que entran contenidos ajenos en el contexto —respuestas de herramientas, páginas y documentos recuperados, contenidos de repositorios, tickets, buzones de correo, memoria persistida— e introducimos en cada canal un marcador inocuo y claramente rastreable para observar si el agente lo trata como instrucción o como dato. Con ello se examina una cuestión arquitectónica clave: ¿existe una separación de procedencia entre instrucción y datos, o ambos acaban en la misma ventana de contexto? Si en un agente concurren al mismo tiempo el acceso a datos sensibles, el procesamiento de contenidos no confiables y la posibilidad de comunicarse hacia el exterior —la lethal trifecta según Simon Willison—, el hallazgo ya es justificable desde el punto de vista arquitectónico, incluso sin una demostración individual exitosa.
05Transporte, ejecución y cadena de suministro (MCP05, MCP04, MCP09)
En el transporte rigen requisitos estrictos: los servidores deben validar la cabecera Origin de las conexiones entrantes y las instancias que se ejecutan localmente deberían escuchar en 127.0.0.1 en lugar de en 0.0.0.0; de lo contrario basta con visitar una página web para hablar con un servidor local mediante DNS rebinding. Comprobamos la validación del lado del servidor frente al esquema declarado, el tratamiento de las URL en la ruta de discovery de OAuth (rangos privados y link-local, cadenas de redirección, DNS rebinding como escenario TOCTOU), así como el sandboxing y el control de salida en la ejecución de herramientas; ya la mera demostración de que una entrada llega sin validar a un intérprete constituye el hallazgo. En el lado de la cadena de suministro cotejamos la entrada del registro, el repositorio y el mantenedor, y verificamos el fijado de versiones, las firmas y las puertas de aprobación para las actualizaciones: etiquetas como «official» o «verified» no son prueba de confianza, como demostró CVE-2025-6514 en el paquete ampliamente extendido mcp-remote (afectadas las versiones 0.0.5 a 0.1.15, corregido en 0.1.16). A ello se suma la búsqueda de servidores en la sombra mediante escaneos de repositorios y endpoints, escaneos de red repetidos con informe diferencial y la evaluación en la pasarela, porque es allí donde se mide qué servidores contacta realmente un agente, y no solo cuáles figuran en la configuración.
06Telemetría, evidencias e informe (MCP08)
La pregunta más dura llega al final: ¿puede reconstruirse a posteriori qué agente llamó a qué herramienta, en qué momento, con qué parámetros y por cuenta de qué identidad? Para ello ejecutamos una secuencia de acciones definida e inocua —conexión, listado de herramientas, varias llamadas, una llamada rechazada— y a continuación intentamos reconstruir exactamente esa secuencia únicamente a partir de los registros; un hallazgo negativo limpio es aquí un resultado de pleno valor, porque hace que todos los demás hallazgos resulten indemostrables en la operación. En el informe separamos dos categorías de prueba: los hallazgos de configuración y arquitectura son demostrables de forma determinista, los hallazgos basados en comportamiento no lo son; para estos indicamos el número de repeticiones, la tasa de aciertos, así como el modelo, el cliente y la versión. Además, cada hallazgo se asigna al nivel en el que se sitúa (protocolo y transporte, autorización, definición de herramienta, cliente/host, nivel de agente), porque la contramedida y el responsable difieren según el nivel.
