SixHack Academy Formación ofensiva
ES Español ✓ EN English ✓
Entrar
Seguridad en MCP: el nuevo eslabón débil de los agentes de IA
07 de octubre de 2026

Seguridad en MCP: el nuevo eslabón débil de los agentes de IA

Qué es el Model Context Protocol (MCP) y por qué se ha convertido en un nuevo terreno de ataque en 2026: tool poisoning, inyección de comandos, los CVEs del año y cómo auditar un servidor MCP.

Durante los primeros años de la inteligencia artificial generativa, gran parte de la conversación sobre seguridad se centró en lo que ocurría dentro del propio modelo: respuestas incorrectas, filtraciones de información, jailbreaks o inyecciones de prompts.

Los agentes han cambiado esa frontera. Un modelo ya no tiene por qué limitarse a responder con texto. Puede consultar una base de datos, leer un repositorio, analizar documentos, acceder a APIs, crear incidencias, interactuar con servicios cloud o ejecutar herramientas capaces de modificar sistemas reales.

Una de las tecnologías que más ha acelerado esa transición es Model Context Protocol (MCP). Anthropic presentó MCP en noviembre de 2024 como un estándar abierto para conectar aplicaciones de IA con herramientas y fuentes de datos. La idea era sencilla: ofrecer una interfaz común para evitar que cada aplicación tuviera que desarrollar una integración diferente para cada servicio.

La comparación habitual es la de un “USB-C para aplicaciones de IA”. Y precisamente ahí aparece el problema de seguridad: cuanto más sencillo es conectar un agente con nuevas capacidades, más importante se vuelve controlar qué se conecta, con qué permisos, qué información recibe el modelo y qué acciones puede realizar.

La adopción ha sido extraordinariamente rápida. En diciembre de 2025, Anthropic hablaba ya de más de 10.000 servidores MCP públicos activos y de adopción en productos como ChatGPT, Cursor, Gemini, Microsoft Copilot y Visual Studio Code. En julio de 2026, los responsables del protocolo indicaban que sus SDK Tier 1 se acercaban conjuntamente a los 500 millones de descargas mensuales.

Con esa adopción ha aparecido también una nueva superficie de ataque: tool poisoning, prompt injection indirecta, configuraciones MCP manipuladas, servidores sin autenticación, SSRF, robo de tokens OAuth, herramientas excesivamente privilegiadas y problemas de cadena de suministro.

Nota: este artículo está orientado al análisis defensivo y a auditorías autorizadas. Los ejemplos explican modelos de amenaza y fronteras de confianza sin proporcionar cadenas de explotación contra sistemas de terceros.

En esta guía

Qué es MCP y qué cambia realmente

Model Context Protocol es un protocolo abierto que estandariza cómo una aplicación de inteligencia artificial puede conectarse con herramientas, recursos y sistemas externos.

Sin MCP, una aplicación que quisiera trabajar con GitHub, una base de datos, un sistema de ficheros y una API interna tendría que integrar cada servicio de manera independiente. MCP introduce una interfaz común entre la aplicación de IA y esos sistemas.

El servidor MCP puede exponer diferentes capacidades. Entre las más importantes están las tools, que permiten realizar acciones, y los resources, que proporcionan información o contexto.

La diferencia respecto a una integración tradicional no es que desaparezca la lógica de aplicación, sino que el modelo puede participar ahora en la decisión sobre qué herramienta utilizar, cuándo utilizarla y con qué parámetros.

En una aplicación clásica, un desarrollador define explícitamente qué ocurre cuando un usuario pulsa un botón. En un sistema agente, el usuario puede expresar una intención en lenguaje natural, el modelo interpreta esa intención, selecciona una herramienta y construye los parámetros que se enviarán al servidor.

Eso introduce una nueva capa de decisión entre la entrada del usuario y la acción final.

MCP no convierte automáticamente una herramienta en segura. El protocolo estandariza cómo se describe, descubre e invoca, pero la autorización, la validación de entrada y los límites de cada acción siguen siendo responsabilidad de las aplicaciones y servidores que lo implementan.

La arquitectura y sus fronteras de confianza

MCP separa conceptualmente tres componentes principales: el host, que es la aplicación donde vive la experiencia del usuario o del agente; el cliente MCP, que mantiene la comunicación con el servidor; y el servidor MCP, que expone herramientas, recursos u otras capacidades.

Desde el punto de vista de seguridad, sin embargo, esa representación se queda corta. Detrás del servidor puede haber un sistema operativo, una base de datos, una API corporativa, un proveedor SaaS, infraestructura cloud o credenciales con privilegios importantes.

Por eso una auditoría debe reconstruir toda la cadena de confianza. Hay que identificar quién controla la información que llega al modelo, quién puede modificar las descripciones de las herramientas, quién registra nuevos servidores MCP, con qué identidad se ejecutan, qué credenciales reciben y qué sistemas pueden alcanzar.

También importa qué acciones pueden realizarse sin intervención del usuario. Una herramienta que únicamente consulta información pública tiene un modelo de amenazas muy distinto al de otra capaz de desplegar código, modificar infraestructura o borrar recursos.

La seguridad de MCP no puede evaluarse observando únicamente el protocolo. Hay que analizar la arquitectura completa y las identidades que atraviesan cada componente.

La nueva superficie de ataque

OWASP mantiene actualmente un proyecto específico dedicado a los principales riesgos de MCP. Entre ellos aparecen problemas como tool poisoning, command injection, prompt injection contextual, gestión insegura de tokens, permisos excesivos, autenticación insuficiente y servidores MCP utilizados fuera del control de la organización.

Muchas de estas vulnerabilidades no son nuevas por sí mismas. Command injection, SSRF, OAuth mal implementado o privilegios excesivos llevan años formando parte de las auditorías tradicionales.

Lo que cambia con los agentes es la posición que ocupan dentro de la arquitectura.

Una entrada controlada por un atacante puede llegar al modelo. El modelo puede utilizarla como contexto para tomar una decisión. Esa decisión puede seleccionar una herramienta privilegiada y terminar alcanzando una API, un sistema de ficheros, una shell o un servicio interno.

La superficie de ataque ya no está únicamente en el endpoint. También existe en la forma en la que el agente interpreta información y decide qué capacidad utilizar.

Por eso algunas de las preguntas tradicionales adquieren una nueva dimensión: no solo debemos preguntar si un parámetro llega a una shell, sino también si contenido no confiable puede convencer al modelo para que invoque la herramienta que llega a esa shell.

Tool poisoning: cuando la propia herramienta se convierte en una entrada

Para poder elegir una herramienta, el modelo necesita conocer qué hace. Esa información suele incluir su nombre, una descripción y el esquema de parámetros que acepta.

Eso significa que una descripción de herramienta no es simplemente documentación destinada a un desarrollador. Puede terminar formando parte del contexto sobre el que razona el modelo.

Si esa descripción procede de una fuente no confiable, un atacante puede intentar introducir instrucciones diseñadas para modificar el comportamiento del agente. El modelo podría interpretar información que aparentemente describe una herramienta como si fueran instrucciones adicionales sobre cómo debe actuar.

OWASP incluye esta categoría como MCP03: Tool Poisoning.

El problema puede ser todavía más sutil cuando las herramientas cambian después de haber sido aprobadas. Un usuario puede autorizar inicialmente un servidor que expone una herramienta aparentemente inocua. Si posteriormente su descripción cambia y el cliente obtiene automáticamente la nueva versión, la confianza concedida originalmente puede extenderse a contenido que nunca fue revisado.

Por eso nombres, descripciones, metadatos y resultados deben considerarse entradas no confiables. Instalar un servidor MCP no debería implicar que cualquier texto producido por ese servidor se convierta automáticamente en una instrucción fiable para el modelo.

El problema de tool poisoning aparece cuando se mezcla información sobre una herramienta con instrucciones que el modelo interpreta como parte de su objetivo. La defensa empieza separando claramente datos, metadatos e instrucciones de confianza.

Prompt injection indirecta a través de MCP

Un servidor MCP ni siquiera necesita ser malicioso para introducir una prompt injection.

Imaginemos un agente conectado a GitHub mediante MCP. El usuario pide resumir las incidencias abiertas de un proyecto y el servidor recupera el contenido de varias issues. Una de ellas ha sido creada por una persona externa y contiene instrucciones dirigidas al modelo.

Cuando el contenido de esa issue entra en el contexto, el agente puede encontrarse procesando al mismo tiempo la petición legítima del usuario y las instrucciones introducidas por el atacante.

El mismo patrón puede aparecer al leer correos electrónicos, documentos, páginas web, comentarios de pull requests, tickets de soporte, entradas de bases de datos, logs o resultados generados por otras herramientas.

Esta es la esencia de la prompt injection indirecta: el atacante no necesita hablar directamente con el modelo. Basta con controlar una fuente de información que el agente vaya a consultar.

El impacto depende entonces de las herramientas disponibles. Un agente capaz únicamente de resumir texto tendrá un riesgo limitado. Uno que además pueda enviar información a Internet, modificar repositorios o ejecutar operaciones administrativas puede convertir la misma inyección en un problema mucho más serio.

Por eso no es razonable confiar únicamente en que el modelo distinguirá correctamente entre “contenido que debe analizar” e “instrucciones que debe obedecer”. Esa separación debe estar reforzada por la arquitectura.

STDIO y ejecución de comandos: qué es vulnerabilidad y qué no

Uno de los puntos que más confusión ha generado en la seguridad de MCP es el funcionamiento de los servidores locales mediante STDIO.

En este modelo, el cliente MCP arranca un proceso local y se comunica con él mediante la entrada y salida estándar. La configuración indica qué programa debe ejecutarse y qué argumentos necesita.

Por tanto, que el cliente ejecute el comando configurado no constituye por sí solo una vulnerabilidad. Es precisamente el comportamiento esperado de este tipo de servidor.

El propio proyecto MCP lo deja explícito en su política de seguridad: ejecutar el comando configurado para iniciar un servidor STDIO forma parte del diseño.

La verdadera frontera aparece en quién puede controlar esa configuración.

Si únicamente una configuración local fiable puede establecer el programa y sus argumentos, se está ejecutando aquello que el usuario o administrador ha decidido instalar. Pero si una issue de GitHub, un fichero del proyecto, una página web o cualquier otra entrada no confiable puede modificar esa configuración, el registro de un servidor puede convertirse en una vía hacia ejecución de código.

La investigación de OX Security

En abril de 2026, OX Security publicó una investigación centrada precisamente en esta frontera. Según sus datos, el trabajo produjo más de 30 disclosures y más de 10 CVEs en productos donde entradas no confiables podían alcanzar la configuración de servidores STDIO o sus parámetros.

OX describió el problema como un riesgo sistémico del ecosistema MCP y estimó una exposición asociada a más de 150 millones de descargas de SDK y hasta 200.000 servidores.

El proyecto MCP mantiene una interpretación más estricta: la ejecución del servidor configurado es comportamiento esperado y la vulnerabilidad aparece en la aplicación que permite controlar esa configuración sin las protecciones adecuadas.

Que STDIO ejecute el servidor configurado no es el bug. El problema aparece cuando contenido no confiable puede modificar el comando, alterar los argumentos, registrar servidores sin una confirmación adecuada o manipular la configuración que termina convirtiéndose en ejecución.

Esta diferencia es importante porque cambia completamente cómo debe auditarse la funcionalidad.

OAuth, tokens y servidores MCP remotos

Cuando el servidor MCP es remoto, la superficie de ataque empieza a parecerse mucho más a la de una API moderna.

Aparecen problemas conocidos de autenticación, autorización, scopes, gestión de secretos, SSRF y OAuth. Un servidor puede exigir identidad, actuar en nombre de un usuario y necesitar tokens para acceder a otros recursos.

Eso introduce preguntas muy similares a las que haríamos al analizar cualquier integración OAuth: qué Authorization Server se utiliza, para qué recurso se emite cada token, qué scopes recibe, dónde se almacena y qué componente puede acceder a él.

LibreChat proporciona varios ejemplos reales publicados durante 2026.

Una vulnerabilidad afectaba a la validación del parámetro OAuth resource. La implementación no comprobaba correctamente que el recurso descubierto correspondiera con el servidor MCP configurado. En determinadas condiciones, un servidor malicioso podía intentar recibir tokens destinados a otro recurso.

Otra vulnerabilidad permitía utilizar headers configurables de servidores MCP junto con mecanismos de sustitución de placeholders que contenían credenciales OAuth. El resultado podía terminar exponiendo el token al servidor controlado por el atacante.

También aparecieron problemas de SSRF relacionados con la forma en que LibreChat validaba los destinos que podían alcanzar determinadas funcionalidades MCP.

La conclusión es importante: MCP no sustituye a OAuth ni elimina sus problemas. En muchas arquitecturas los combina con una nueva capa agente.

CVEs reales relacionados con MCP

Contar vulnerabilidades no es una buena forma de medir por sí sola la seguridad de un protocolo. Resulta mucho más interesante observar qué tipos de problemas están apareciendo en productos reales.

CVE Producto Problema
CVE-2025-49596 MCP Inspector Falta de autenticación entre Inspector y su proxy que podía terminar en ejecución de comandos mediante servidores STDIO. CVSS 4.0: 9.4.
CVE-2025-59536 Claude Code Un proyecto no confiable podía provocar ejecución antes de que el usuario completara correctamente el diálogo de confianza. CVSS 4.0: 8.7.
CVE-2026-22252 LibreChat La configuración MCP STDIO aceptaba comandos arbitrarios y permitía obtener ejecución como root dentro del contenedor. CVSS 3.1: 9.1.
CVE-2026-30615 Windsurf Contenido controlado mediante prompt injection podía modificar la configuración MCP y registrar automáticamente un servidor STDIO malicioso.
CVE-2026-31945 LibreChat SSRF en funcionalidades relacionadas con Actions y MCP debido a una validación insuficiente tras la resolución DNS.
CVE-2026-31951 LibreChat Headers controlados en configuraciones MCP podían provocar exposición de tokens OAuth mediante placeholders de credenciales.
CVE-2026-33032 nginx-ui Un endpoint MCP no aplicaba correctamente autenticación y permitía utilizar herramientas administrativas capaces de modificar la configuración y reiniciar NGINX.
CVE-2026-54030 LibreChat Validación insuficiente del parámetro OAuth resource podía permitir que un servidor MCP malicioso recibiera tokens destinados a un servidor legítimo.

Los identificadores son menos importantes que el patrón que muestran. En una misma arquitectura aparecen fallos de autenticación, control de configuración, OAuth, gestión de secretos, SSRF, prompt injection y ejecución de procesos.

MCP no ha inventado todas esas vulnerabilidades. Lo que ha hecho es acercarlas a una capa donde un modelo puede participar en la decisión que conduce hasta ellas.

Qué ha cambiado en MCP durante 2026

MCP tampoco es un protocolo estático. La revisión publicada el 28 de julio de 2026 introdujo el conjunto de cambios más importante desde su lanzamiento.

Entre las novedades está un núcleo de protocolo stateless para servidores remotos, un sistema de routing mediante headers como Mcp-Method y Mcp-Name, cambios en las interacciones de varias rondas, un framework formal de extensiones y una política de deprecación.

También hubo cambios relevantes en autorización.

La especificación incorporó validaciones relacionadas con el parámetro iss siguiendo RFC 9207 para reducir ataques de mix-up, estableció una relación más clara entre las credenciales del cliente y el issuer que las creó y añadió aclaraciones alrededor de los scopes y de los procesos de autorización.

La evolución del protocolo también está alejándose de algunos mecanismos anteriores, como Dynamic Client Registration, en favor de modelos como Client ID Metadata Documents.

Estas mejoras reducen determinados riesgos de infraestructura y autorización, pero no resuelven categorías como tool poisoning o prompt injection. Tampoco pueden compensar una herramienta que haya sido diseñada con más privilegios de los necesarios.

Cómo auditar un servidor MCP

Una auditoría MCP útil empieza reconstruyendo la arquitectura completa y no simplemente revisando el código de cada herramienta.

1. Identifica qué hay detrás del servidor

Hay que saber qué host utiliza el servidor, cómo se establece la conexión, qué dependencias existen y qué sistemas puede alcanzar. También deben identificarse las cuentas, credenciales y tokens utilizados en cada salto.

Un servidor aparentemente sencillo puede estar actuando con acceso a una base de datos corporativa, un repositorio privado o infraestructura cloud. Ese contexto modifica completamente la severidad de cualquier fallo.

2. Inventa y clasifica todas las herramientas

Cada herramienta debería clasificarse según el efecto que puede producir.

Una herramienta de lectura puede exponer información. Una herramienta de escritura puede alterar integridad. Una herramienta administrativa puede desplegar, borrar o reiniciar sistemas. Y una herramienta genérica capaz de ejecutar comandos o consultas arbitrarias puede proporcionar una superficie prácticamente ilimitada.

Esta clasificación permite detectar rápidamente cuándo una capacidad aparentemente cómoda proporciona al agente demasiado poder.

3. Revisa las descripciones y metadatos

Las descripciones deben tratarse como entradas de seguridad. Conviene comprobar quién puede modificarlas, si se recuperan dinámicamente, si pueden cambiar después de una aprobación y si el usuario ve realmente la misma información que recibe el modelo.

Una discrepancia entre lo que ve la persona y lo que interpreta el modelo puede crear una frontera de confianza especialmente peligrosa.

4. Audita autenticación y autorización por herramienta

No basta con comprobar que el servidor exige login.

Para cada capacidad hay que determinar qué usuario puede utilizarla, contra qué recursos, con qué scopes, en nombre de qué identidad y con qué límites.

Una operación administrativa no está protegida simplemente porque el agente normalmente no la invoque. La autorización debe imponerse en el servidor.

5. Sigue las entradas hasta su destino real

El análisis tradicional de flujo de datos sigue siendo fundamental.

Hay que seguir cada parámetro desde MCP hasta el punto donde termina utilizándose y comprobar si llega a una shell, una consulta SQL, una ruta del sistema de ficheros, una URL, una plantilla o una API externa.

Ahí siguen apareciendo las mismas vulnerabilidades conocidas: command injection, path traversal, SQL injection, SSRF y manipulación de URLs.

6. Audita también la configuración

En servidores locales, la configuración MCP merece prácticamente el mismo nivel de protección que el código ejecutable.

Hay que revisar quién puede modificar el comando de lanzamiento, sus argumentos, las variables de entorno, el transporte utilizado, los servidores registrados y las configuraciones específicas de cada proyecto.

Muchos de los CVEs recientes no estaban en una herramienta concreta, sino precisamente en esa capa de control.

7. Analiza qué devuelve cada herramienta al modelo

Una herramienta puede estar perfectamente protegida frente a inyecciones clásicas y seguir introduciendo un riesgo si devuelve directamente contenido controlado por un atacante al contexto del modelo.

Por eso conviene probar respuestas que intenten cambiar el objetivo del agente, conseguir que invoque otras herramientas, solicitar secretos, ocultar acciones o modificar el orden esperado de la tarea.

8. Piensa en combinaciones

Una de las diferencias más importantes respecto a una auditoría tradicional es que varias herramientas seguras de forma independiente pueden formar una capacidad peligrosa cuando el agente puede combinarlas.

Una herramienta que lee ficheros puede ser razonable. Otra que realiza peticiones HTTP también puede serlo. Pero un agente capaz de utilizar ambas consecutivamente puede crear un canal de exfiltración.

Lo mismo ocurre con una herramienta que enumera secretos y otra que crea incidencias en un servicio externo. Ninguna tiene por qué ser una vulnerabilidad aislada, pero la composición puede producir un resultado que el diseño original nunca pretendió permitir.

Cómo proteger una arquitectura MCP

La defensa empieza por no considerar al modelo, las herramientas y sus resultados como una única zona de confianza.

Diseña herramientas con una función concreta

Cuanto más genérica sea una herramienta, más difícil es limitar su impacto.

Es preferible exponer una capacidad específica para obtener determinada información o realizar una operación concreta que ofrecer directamente una shell, SQL arbitrario o un cliente HTTP sin restricciones.

Valida entradas igual que en cualquier otra aplicación

Los parámetros generados por un modelo siguen siendo datos no confiables. Deben validarse antes de llegar a comandos, rutas, consultas, URLs o servicios externos.

Que el argumento haya sido generado por un modelo no modifica las reglas básicas de secure coding.

Aplica privilegio mínimo

El proceso MCP y las credenciales que utiliza deberían tener únicamente los permisos necesarios para realizar su función.

También conviene limitar el tráfico saliente cuando el servidor no necesita acceder libremente a Internet o a otras redes internas.

No registres automáticamente servidores desde contenido no confiable

Un cliente debería mostrar claramente qué servidor se está añadiendo, qué comando local se va a ejecutar y qué permisos necesita.

Las acciones de alto impacto deberían requerir confirmaciones adecuadas, especialmente cuando la decisión ha sido influida por contenido externo.

Separa datos de instrucciones

Las descripciones y resultados de las herramientas no deberían tratarse como instrucciones de sistema.

El host debe asumir que cualquier contenido que proceda de una herramienta puede estar controlado por una fuente externa.

Protege identidad y secretos

Las credenciales deberían tener scopes mínimos y una vida limitada. También es importante evitar exponer secretos innecesarios mediante variables de entorno o configuraciones accesibles a todos los servidores.

En despliegues OAuth hay que comprobar además que las credenciales se entregan al servidor y recurso correctos.

Controla la cadena de suministro

Instalar un servidor MCP local equivale en muchos casos a instalar y ejecutar software.

Por eso deben utilizarse fuentes verificadas, fijarse versiones, revisarse dependencias y mantenerse un inventario de servidores MCP autorizados dentro de la organización.

Los mecanismos que descargan y ejecutan automáticamente la versión más reciente de un paquete son especialmente delicados en entornos sensibles.

Registra lo que hacen los agentes

La trazabilidad debe incluir quién realizó la acción, qué servidor participó, qué herramienta se invocó, los parámetros relevantes, el resultado obtenido, la autorización utilizada y las acciones posteriores.

Sin ese contexto, investigar un incidente puede convertirse en intentar reconstruir a posteriori una cadena de decisiones que ocurrió entre un modelo y varios sistemas externos.

Qué significa para seguridad ofensiva

MCP resulta especialmente interesante para seguridad ofensiva porque no obliga a abandonar los fundamentos clásicos.

La mayor parte del análisis sigue dependiendo de entender fronteras de confianza, autenticación, autorización, APIs, OAuth, SSRF, inyecciones, secretos, ficheros, procesos y lógica de negocio.

Lo que cambia es que ahora existe otra capa tomando decisiones entre la entrada y la acción final: el modelo.

Por eso aparece una pregunta adicional que merece acompañar toda auditoría: ¿puede información no confiable influir en la acción que el agente decide ejecutar?

Si la respuesta es sí, hay que seguir esa decisión hasta la capacidad final y comprobar qué controles existen realmente entre ambas.

La base técnica necesaria para analizar estas fronteras es la misma que trabajamos en el curso Web eXploitation Expert (WXE): APIs, autenticación, autorización, SSRF, inyecciones, OAuth, lógica de negocio y análisis de relaciones de confianza.

MCP cambia la interfaz, pero debajo siguen existiendo servidores, endpoints, tokens, procesos y datos. Saber seguir esas relaciones es lo que permite distinguir una característica potente de una vulnerabilidad explotable.

Las interfaces cambian. Las fronteras de confianza siguen ahí.

En SixHack Academy entrenamos el razonamiento ofensivo necesario para analizar aplicaciones modernas más allá de una lista de vulnerabilidades. En el curso Web eXploitation Expert (WXE) profundizamos en las técnicas que siguen apareciendo detrás de arquitecturas como MCP: autenticación, APIs, OAuth, SSRF, inyecciones y lógica de negocio.

Preguntas frecuentes

¿Qué es Model Context Protocol?

MCP es un protocolo abierto presentado originalmente por Anthropic que estandariza cómo las aplicaciones de IA se conectan con herramientas y fuentes de datos externas. Desde diciembre de 2025 el proyecto forma parte de la Agentic AI Foundation bajo la Linux Foundation.

¿MCP pertenece todavía a Anthropic?

Anthropic creó MCP, pero en diciembre de 2025 donó el proyecto a la Agentic AI Foundation, un proyecto de la Linux Foundation cofundado inicialmente por Anthropic, Block y OpenAI y apoyado por otras empresas del sector.

¿MCP es inseguro por diseño?

No sería correcto afirmarlo así. MCP permite construir integraciones muy potentes y eso crea fronteras de seguridad que deben protegerse. Algunos riesgos proceden de implementaciones vulnerables, otros de clientes que confían demasiado en configuraciones o contenido externo y otros del propio modelo de agentes y de la prompt injection.

¿Qué es tool poisoning?

Es la manipulación de una herramienta, su descripción, metadatos o resultados para influir en el comportamiento del modelo. OWASP lo incluye entre los principales riesgos específicos del ecosistema MCP.

¿Que un servidor MCP use STDIO significa que existe RCE?

No. En STDIO, ejecutar el proceso configurado para arrancar el servidor es el comportamiento esperado. El riesgo aparece cuando una parte no confiable puede controlar el comando o los argumentos, registrar servidores sin consentimiento o manipular esa configuración.

¿Puede una prompt injection terminar ejecutando comandos?

Puede ocurrir si existe una cadena que conecte contenido no confiable con las decisiones del agente y este dispone de herramientas capaces de modificar configuración, ejecutar procesos o realizar acciones equivalentes. CVE-2026-30615 en Windsurf es un ejemplo real de una cadena donde contenido controlado podía terminar registrando un servidor MCP STDIO malicioso.

¿Un servidor MCP remoto necesita autenticación?

Depende de lo que exponga, pero cualquier servidor que proporcione recursos privados o acciones sensibles debe disponer de autenticación y autorización adecuadas. CVE-2026-33032 demostró el impacto de dejar un endpoint MCP sensible accesible sin la autenticación prevista.

¿MCP utiliza OAuth?

Los despliegues remotos pueden utilizar OAuth para autorización. La especificación MCP de 2026 incorpora además varias mejoras relacionadas con issuer validation, scopes y vinculación de credenciales.

¿Qué es un shadow MCP server?

Es un servidor MCP instalado o utilizado fuera del inventario y de los controles de la organización. Puede introducir software, credenciales o capacidades que el equipo de seguridad desconoce.

¿Necesito conocimientos de machine learning para auditar MCP?

No para empezar. Los fundamentos más importantes siguen siendo seguridad web, APIs, autenticación, OAuth, inyecciones, SSRF, permisos, procesos y gestión de secretos. Después hay que añadir el modelo de amenazas específico de los agentes y la prompt injection.

Referencias

← Volver a Artículos