Abuso de GitHub MCP: acceso a repositorios privados a través de MCP

 (invariantlabs.ai)
3 puntos por GN⁺ 2025-05-28 | 2 comentarios | Compartir por WhatsApp
  • Se descubrió una vulnerabilidad crítica en la integración de GitHub MCP que permite a un atacante manipular el agente del usuario mediante un GitHub Issue malicioso y filtrar datos de repositorios privados
  • Esta vulnerabilidad corresponde a un nuevo tipo llamado Toxic Agent Flow, en el que el agente expone datos en un repositorio público debido a prompts maliciosos
  • La vulnerabilidad no surge de una falla de la herramienta en sí, sino de una limitación arquitectónica, y prácticas de uso realistas como políticas simples de confirmación de uso agravan el riesgo
  • Para una defensa efectiva, es necesario introducir protecciones sistemáticas para agentes, como control de permisos granular y monitoreo de seguridad continuo
  • Como la alineación del modelo por sí sola no es suficiente, son importantes las medidas de seguridad a nivel de sistema en todo el entorno de MCP y de los agentes

Resumen

Invariant descubrió una vulnerabilidad muy grave en la integración de GitHub MCP (14,000 stars) ampliamente utilizada. Esta vulnerabilidad permite que un atacante cree un GitHub Issue malicioso, manipule el agente del usuario y filtre al exterior datos de un repositorio privado

Este problema fue el primer caso detectado por el escáner automatizado de detección de Toxic Agent Flow de Invariant. En estos escenarios, el agente es inducido a realizar acciones no deseadas, causando daños como filtración de datos o ejecución de código malicioso

Dado que recientemente la industria ha adoptado ampliamente los agentes de programación y los IDE, es un momento importante para aumentar la conciencia sobre este tipo de ataques

Escenario de ataque

  • Preparación del ataque

    • Se asume que el usuario tiene conectado un cliente MCP como Claude Desktop con el servidor GitHub MCP
    • <user>/public-repo: repositorio público donde cualquiera puede crear un Issue
    • <user>/private-repo: repositorio privado, donde se almacenan datos internos de la empresa, etc.
    • El atacante crea un Issue malicioso en el repositorio público (incluyendo prompt injection)
    • Cuando el usuario hace una solicitud común como “muéstrame la lista de issues de public-repo”, el agente obtiene los issues del repositorio público y queda expuesto a la inyección

  • Flujo del ataque

    • En el momento en que el agente lee el Issue malicioso, trae al contexto datos del repositorio privado y los publica en el repositorio público en forma de PR, dejándolos accesibles para cualquiera
    • Este proceso se define como Toxic Agent Flow, y el analizador de seguridad de Invariant puede detectarlo automáticamente en entornos reales

Demostración del ataque

  • Como ejemplo, se reprodujo el ataque usando el repositorio público (ukend0464/pacman) y repositorios privados
  • El atacante crea un Issue malicioso en el repositorio público, y cuando el agente consulta la lista de issues de ese repositorio, se ejecuta la prompt injection
  • Cuando el usuario pide ayuda a Claude 4 Opus, Claude ejecuta la inyección a través de la integración con GitHub MCP
    • Claude Desktop solicita confirmación por defecto al usar herramientas, pero muchos usuarios operan con una política de "permitir siempre" y actúan sin pensarlo
  • El agente extrae datos del repositorio privado y los expone en un PR público
  • En el experimento se filtraron incluso nombres de proyectos privados, planes de reubicación laboral, salarios y otra información sensible

Detección de Toxic Agent Flows

  • Esta vulnerabilidad puede producirse incluso sin que la herramienta MCP tradicional haya sido comprometida, debido a información no confiable proveniente de una plataforma externa (GitHub)
  • En sistemas de agentes a gran escala, analizar y mitigar manualmente este tipo de riesgos es muy complejo, por lo que Invariant desarrolló un método de detección automatizado para permitir un análisis preventivo de amenazas

Alcance del impacto y medidas de respuesta

  • Esta vulnerabilidad no se limita a un agente o cliente específico, sino que afecta a todos los agentes que usan servidores MCP
  • No se trata de un defecto en el código del propio servidor GitHub MCP, sino de un problema de diseño, por lo que no puede resolverse con un parche del servidor GitHub
  • Se proponen dos estrategias de respuesta clave

1. Control de permisos granular

  • En entornos con integración MCP, es necesario aplicar el principio de mínimo privilegio para que el agente solo pueda acceder a los repositorios estrictamente necesarios
  • La autorización tradicional basada en tokens tiene limitaciones importantes de usabilidad
  • Con una capa dinámica de seguridad en tiempo de ejecución como Invariant Guardrails, es posible reforzar el control de acceso según el contexto del flujo de trabajo
    • Ejemplo de política: permitir acceso a un solo repositorio por sesión para evitar filtraciones de información entre repositorios
    • Ejemplo de definición de política: 
      raise Violation("You can access only one repo per session.") if:
    (call_before: ToolCall) -> (call_after: ToolCall)
    call_before.function.name in (...set of repo actions)
    call_after.function.name in (...set of repo actions)
    call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
    call_before.function.arguments["owner"] != call_after.function.arguments["owner"]
    • Es posible probar políticas en Guardrails Playground, entre otros

2. Monitoreo de seguridad continuo

  • Además de las medidas preventivas, se necesitan herramientas sólidas de monitoreo que escaneen en tiempo real las interacciones entre los agentes y los sistemas MCP
  • Ejemplo: introducir Invariant MCP-scan para vigilancia y detección de señales anómalas
  • Usando el modo proxy más reciente, es posible redirigir el tráfico MCP a través de un proxy y realizar diagnósticos en tiempo real sin cambiar la infraestructura actual
  • Un monitoreo integral permite detectar vulnerabilidades, registrar intentos de intrusión y bloquear de forma temprana flujos maliciosos

Por qué la alineación del modelo no es suficiente

  • Incluso los modelos de lenguaje grandes más recientes (por ejemplo, Claude 4 Opus) siguen estando fácilmente expuestos a ataques simples de prompt injection
  • El entrenamiento básico de alineación por sí solo no puede prevenir todos los ataques diversos y dependientes del contexto que aparecen en entornos de despliegue reales
  • Por lo tanto, es indispensable construir mecanismos de seguridad y detección de contexto a nivel de sistema, separados de la etapa del modelo

Conclusión

  • Invariant demostró una vulnerabilidad grave en el servidor GitHub MCP que permite tomar control del agente mediante un GitHub Issue malicioso y filtrar repositorios privados
  • Esta vulnerabilidad es un caso representativo descubierto por el sistema automatizado de detección de Invariant, y ataques similares siguen ocurriendo en diversos entornos, incluido MCP
  • El uso de escáneres de seguridad dedicados como MCP-scan y Guardrails es clave para una adopción y operación seguras de sistemas MCP/agentes

Referencias y contacto

  • Para aplicar medidas de seguridad adicionales o solicitar consultoría, se puede contactar a earlyaccess@invariantlabs.ai

Autor:
Marco Milanta
Luca Beurer-Kellner

Lecturas relacionadas

2 comentarios

 
crawler 2025-05-28

Suena grandilocuente, pero al final es simplemente un problema causado por prompt injection + demasiados permisos que MCP puede usar.
Así que da la impresión de que están promocionando una herramienta que permite controlar desde afuera los permisos de MCP.
Estaría bien que los prompts que entran desde afuera, los prompts que solo se ingresan internamente y los permisos que MCP puede usar tuvieran niveles distintos.
 
GN⁺ 2025-05-28
Opiniones de Hacker News

  • Siento que este ataque no se está entendiendo del todo. Si le das un token de acceso a Claude, entonces, sin importar para qué le indiques usarlo, se le puede inducir a hacer cualquier cosa que esté dentro de los permisos de ese token. Si le das credenciales a un LLM, hay que asumir que el LLM puede aprovechar todos los privilegios de esas credenciales. Hay que tener especial cuidado si se permite automáticamente el uso de herramientas. Pero GitHub sí tiene tokens de acceso con permisos granulares, así que si solo se otorgan permisos para acceder a repositorios específicos, se limita el alcance del posible abuso por parte del LLM. Este ataque solo es posible cuando el LLM tiene acceso a toda la cuenta, y el verdadero problema es darle a Claude unas credenciales tan riesgosas

    • La parte importante de este tema es que, como en la mayoría de los ataques de prompt injection, el LLM termina en un entorno donde tiene acceso simultáneo a al menos dos de estas tres cosas: datos controlados por un atacante, información sensible y capacidad de exfiltrar datos. El principio básico del diseño de agentes es permitir como máximo dos a la vez, y diseñar con esa regla evita problemas de seguridad. Por ejemplo, en cuanto ves un issue creado por alguien no confiable, el contexto del LLM ya quedó contaminado con datos creados por un atacante. Luego, si va a acceder a información sensible, hay que desactivar funciones como la conexión a internet. Si se sigue este modelo, se puede estar seguro incluso sin tokens por repositorio. Lamentablemente, MCP no tiene herramientas que garanticen esto

    • El problema es que los permisos de los tokens suelen configurarse de forma demasiado amplia, pero al mismo tiempo los desarrolladores tampoco quieren abrir un token por cada repositorio. Entonces terminan dándole permisos amplios al token y confiando ciegamente en el LLM. Esta precaución es sensata, pero en la práctica muchos actores del ecosistema no la siguen. Por eso este reporte es importante: educa sobre cómo un LLM puede ser secuestrado para hacer cualquier cosa si tiene permisos y datos no confiables. La solución es limitar dinámicamente el alcance de uso del token. Nosotros estamos investigando este enfoque en esta lista

    • Esto puede pasar en servicios como Railway. A veces Railway pide acceso a todos los repositorios de GitHub incluso para desplegar un solo proyecto, mientras que Netlify sí respeta dar permisos solo al repositorio que quieres. GitHub debería impedir directamente la aprobación de apps que no respeten así los permisos de acceso

    • Es el mismo patrón que se repite cada vez que aparece una tecnología nueva. Se actúa como si los principios básicos de seguridad pudieran ignorarse en un contexto nuevo. En realidad, aunque uses la tecnología más “brillante” y reciente, jamás debes ignorar los principios básicos de seguridad. En el mundo cripto pasó lo mismo: se repitieron estafas y delitos financieros de siempre porque se ignoraron las lecciones anteriores solo por tratarse de una tecnología distinta

    • Si un chatbot interactúa con usuarios, hay que asumir que hará cualquier cosa que esté permitida dentro de su alcance. Un chatbot no es más que una capa de conveniencia sobre una API; claramente no es un mecanismo de seguridad en sí mismo

  • Si te interesa MCP y la seguridad de agentes, hay varios materiales en los que hemos trabajado: el trace de ejecución completo de Claude para todo el escenario de ataque (enlace), un escáner de seguridad para conexiones MCP (enlace), ataques de envenenamiento de herramientas MCP (blog), un caso de explotación de WhatsApp MCP (blog), Guardrails como capa de seguridad para agentes (blog) y AgentDojo, que evalúa conjuntamente seguridad y utilidad de agentes de IA (blog)

  • No sé si esto realmente merece llamarse un “exploit”. Si le das a un agente un token que puede acceder a repositorios privados, entonces va a poder acceder a ellos. MCP es solo un servidor API. Si algo no debería exponerse vía API, entonces tampoco debería tener permisos

    • Como mucha gente, yo también leí primero los comentarios antes del artículo. Viendo el contenido real, lo que pasa es que se crea un issue malicioso en GitHub y dentro de ese issue viene un prompt que busca inducir al LLM a exfiltrar datos. Cuando el dueño del repositorio activa el agente, este termina actuando siguiendo ese prompt malicioso

    • Este sí es un exploit real en el sentido de que abusa del error humano, o de la sobreconfianza. El problema es que la gente se deja llevar por el hype y le entrega con tranquilidad a un LLM un token privado con acceso completo y sensible a GitHub

    • El tema es importante, así que quiero hacer un pequeño señalamiento: todo el mundo debe entender con precisión el riesgo de ejecutar herramientas de IA. Hoy los agentes ejecutan herramientas según su atención actual, es decir, según su contexto, y esa atención se ve fácilmente influida por el resultado de herramientas o por prompts. Pero en los comentarios solo se repite la idea simplista de “eso pasa por darle el token”. Y además, incluso después de que se explica bien el problema, sigue habiendo quien desvía el punto diciendo “es culpa del usuario por haberlo permitido”. Ese es el argumento clásico equivocado sobre el problema de confused deputy. También hablan de responsabilidad del usuario, pero en la práctica el problema es que MCP no hace controles posteriores de acceso ni registros. Yo solo me sentiría tranquilo si quedara un logging obligatorio. También me parece mal que se descarte la investigación de seguridad llamándola “sentido común”; hablar de seguridad nunca sobra. Que una vulnerabilidad sea débil no significa que no valga la pena discutirla. Incluso se podría comparar con SQL injection. Y me parece peligroso no entender la perspectiva de que el sistema fue contaminado indirectamente, es decir, mediante la creación de un issue público que entrega instrucciones maliciosas. Por último, es una lástima ver tanta actitud defensiva en vez de apertura a ideas nuevas

  • Desde una perspectiva de seguridad, cuando un LLM ve texto de una fuente no confiable, hay que asumir que esa fuente puede manipularlo para que genere cualquier salida que quiera. Si ese resultado termina en una llamada a herramientas, entonces esa fuente no confiable en la práctica también puede usar esas herramientas. Buscando más información, pensé que la documentación de Guardrails de invariant labs también tiene un componente de marketing. Asusta que la estructura sea tan compleja como para necesitar productos de guardrails desde el punto de vista de seguridad. Da un poco de pena pensar que si las empresas de IA hubieran diseñado todo con foco en seguridad desde el principio, quizá ni siquiera harían falta estos productos

    • Es un problema fácil si solo se separan bien los inputs. Basta con marcarlo en el prompt con etiquetas como <github_pr_comment> y dejar explícito que eso debe tratarse solo como lectura, nunca como instrucciones. Este ataque en realidad tiene una estructura algo compleja. Se siente parecido a cuando antes salían issues de prompt injection en chatbots. Ahora también MCP está entrando en esa conversación

    • Me pregunto si sería posible entrenar al LLM para marcar parte del texto como datos sin depurar, o impuros, y hacer que ignore cualquier interpretación imperativa de esa parte

    • En realidad las empresas de IA sí están pensando en el diseño de seguridad. Pero este “exploit” solo es posible cuando se desactiva la seguridad, algo que además se ofrece con advertencias fuertes. Por ejemplo, Claude Desktop por defecto pide aprobación explícita para cada llamada a herramientas. Pero muchos usuarios lo configuran en “permitir siempre” y ya no monitorean las acciones individuales

    • Este patrón de vulnerabilidad de software se ha repetido históricamente, y resulta entre curioso y absurdo verlo aparecer siempre con tecnologías nuevas. El patrón de “recibir input del usuario, interpretarlo y ejecutarlo como si fuera una orden en un entorno mal defendido” se repite una y otra vez. Ya lo vimos con SQL injection, XSS, includes de PHP y demás, y ahora se repite también con los LLM

  • No creo que MCP en sí sea especialmente innovador ni particularmente vulnerable al hackeo, aunque sí tengo opiniones aparte sobre MCP. Me da la impresión de que esto es una forma de empaquetar en marketing una técnica de prompt injection. Cuando diseño sistemas de agentes, siempre parto de esta filosofía: “todo a lo que el agente puede acceder, también puede ser accedido por cualquiera que tenga acceso a ese agente”. No dejo el control de acceso en manos del LLM, y dejo claro que la responsabilidad de seguridad de lo que hace el agente siempre recae en el sujeto que lo invoca. De principio a fin, lo que de verdad importa en este artículo es a qué recursos reales se le permite acceder al agente. Si le permites acceder a correos, y un correo con prompt injection induce al LLM a robar un token de seguridad y enviarlo, ahí sí hay un riesgo realmente grave

    • Pegarle la etiqueta de MCP a esto se siente como la moda de hace 10 años de decir “está en blockchain”. Decir que “como el LLM aprueba y actúa, hay que aplicar estrictamente el principio de mínimo privilegio” es algo obvio para cualquiera con experiencia, pero quizá otra generación tenga que volver a aprender estos fundamentos

  • El caso de ataque real y la reacción del agente pueden verse aquí. Da un poco de risa que el agente haya ejecutado el ataque con éxito total

  • Yo también probé hace una semana el agente de programación Jules de Google, y la solicitud de permisos de GitHub OAuth pedía acceso total a todos los repositorios y permisos de la cuenta. Ese diseño tiene que ver en parte con la comodidad para desarrolladores, pero también con el propio flujo de autenticación de GitHub OAuth. Desde el principio debería ser más fácil dar permisos limitados por repositorio y luego solicitar permisos adicionales si hacen falta. Pero en la práctica no queda otra que crear una cuenta separada de GitHub solo para darle acceso a ciertos repositorios (cuenta de ejemplo). Es bastante incómodo. La propia documentación oficial de GitHub recomienda crear estos machine users por separado, pero debería ser mucho más fácil definir el alcance por repositorio desde el inicio. Si alguien conoce una mejor forma, me gustaría mucho saberla

  • Siento que la afirmación central de este artículo está muy exagerada. Cuando se dice que hubo exfiltración de datos por un issue simple, en realidad eso solo fue posible porque el usuario tuvo que realizar personalmente varias acciones inseguras. Es decir: montar un servidor MCP, darle credenciales con acceso tanto a repos públicos como privados, permitir al LLM acceder a ese servidor y leer los issues del repositorio, y además hacer que lea el issue malicioso y publique el resultado hacia afuera. El resultado es malo, sí, pero no me parece algo que realmente encaje con “una vulnerabilidad de seguridad explotable por terceros maliciosos”. Fue el resultado de hacer que el usuario leyera datos no confiables y luego enviara el resultado a un lugar no confiable. Aun así, GitHub MCP sí tiene parte de responsabilidad. Es un problema que no impida cruces entre repositorios públicos y privados

    • En esencia, no hay que pasar por alto que incluso una instrucción tan simple como “por favor resume los issues” puede llevar a ejecutar órdenes incrustadas directamente dentro de un issue malicioso

    • También importa la perspectiva del marketing de MCP. Lo correcto sería separar el protocolo para que solo puedan acceder entornos o usuarios confiables. El problema es que no existe una forma estándar de definir alcance o autenticación en los servidores MCP. Siento que el problema de fondo no es tanto GitHub MCP, sino cómo toda la industria está usando e implementando esto. De hecho, cuando se usan servidores MCP personalizados, se suele agregar información extra además de la IA, como ID o JWT, para bloquear por seguridad

    • Con la fiebre actual por la IA, la realidad es que mucha gente aplica este tipo de configuraciones y flujos peligrosos sin pensarlo mucho. Es fácil decir “obviamente no deberías usar eso así”, pero precisamente por eso hacen falta guardrails. La gente a menudo toma decisiones riesgosas

    • Sobre la idea de no mezclar repositorios públicos y privados: en la práctica estas son llamadas a herramientas completamente separadas. Desde la perspectiva del servidor MCP, no hay forma de detectar esa interacción

  • Acabo de notar que la discusión ahora continúa en ese hilo de HN

    • Como ya se mencionó allá también, el riesgo de seguridad es claro: si a un sistema se le da acceso a datos privados y al mismo tiempo se permite que usuarios externos introduzcan texto arbitrario, entonces en la práctica se les está dando indirectamente acceso a datos privados a esos usuarios externos. Es un problema fácil de prevenir si se siguen las prácticas de seguridad estándar

    • Los comentarios ahora se trasladaron y están reunidos aquí

  • MCP es solo un protocolo; hay muchos casos parecidos como A2A y también enfoques más primitivos. Incluso se podría hacer que un LLM lea la documentación de la API de GitHub y use el token directamente contra la API. Todavía no todos los LLM tienen ese nivel de capacidad, pero pronto lo tendrán. Asegurar perfectamente el mecanismo de registro de herramientas es, en la práctica, casi imposible. La responsabilidad final por la exfiltración de datos termina recayendo en el LLM. Como los desarrolladores quieren aumentar la productividad con LLM, o bien tendrá que haber garantías reales de seguridad, o podríamos llegar a un escenario donde haya que poner un firewall de seguridad en cada laptop. Lo realmente fastidioso es que en el futuro tal vez terminemos incluso con una pelea de “LLM que detecta LLM malicioso” contra “LLM malicioso que explota hasta el firewall de seguridad”