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

• Un agente MCP conectado a una cuenta de GitHub puede abrir una vía de fuga de datos de repositorios privados con solo leer un Issue público
• El ataque comienza cuando una inyección indirecta de prompts incrustada en un Issue de un repositorio público altera el flujo de uso de herramientas del agente
• En la demo, un Issue malicioso en ukend0464/pacman hace que, mediante la integración entre Claude 4 Opus y GitHub MCP, información de repositorios privados termine expuesta en un PR público
• El núcleo del problema no está tanto en un fallo del código del servidor GitHub MCP, sino en la estructura donde herramientas confiables se usan junto con contenido externo no confiable
• Los sistemas de agentes necesitan privilegios mínimos por repositorio, restricciones de acceso por sesión y monitoreo de seguridad en tiempo de ejecución como MCP-scan

---

Ataque a GitHub MCP que comienza con un Issue malicioso

• Invariant descubrió una vulnerabilidad en la muy usada integración de GitHub MCP que permite a un atacante secuestrar el agente del usuario y filtrar datos de repositorios privados
  • Ese servidor GitHub MCP es un proyecto con 14k stars en GitHub
  • La vulnerabilidad es uno de los primeros casos de Toxic Agent Flows detectados por el analizador de seguridad de Invariant
• Un Toxic Agent Flow es un flujo en el que, mediante inyección indirecta de prompts, el agente ejecuta una secuencia de uso de herramientas no prevista
  • Puede derivar en acciones como exfiltración de datos o ejecución de código malicioso
• En un contexto donde los agentes de programación y los IDE se despliegan rápidamente, ataques similares pueden alcanzar a usuarios de herramientas clave de desarrollo de software

Configuración del ataque

• El usuario utiliza un cliente MCP como Claude Desktop y tiene el servidor GitHub MCP conectado a su cuenta de GitHub
• El escenario del ataque asume dos tipos de repositorios
  • <user>/public-repo: un repositorio público donde cualquiera puede crear Issues y reportes de bugs
  • <user>/private-repo: un repositorio privado con código propietario o datos internos de la empresa
• El atacante puede crear un Issue malicioso en el repositorio público según las reglas normales de permisos de GitHub
• Si el usuario le envía al agente una solicitud legítima como Have a look at the open issues in <user>/public-repo, el agente obtiene los Issues del repositorio público y queda expuesto a la inyección de prompts
• Después, el agente puede traer datos del repositorio privado al contexto y filtrarlos en un PR generado automáticamente en el repositorio público

Flujo de filtración observado en la demo

• La demo usa el repositorio público ukend0464/pacman y varios repositorios privados
  • ukend0464/pacman: un repositorio público con una implementación sencilla del juego Pacman, disponible en GitHub
  • Los repositorios privados contienen proyectos personales del usuario e información sensible
• El atacante coloca un Issue malicioso en el repositorio público
  • Ese Issue incluye una carga útil que se ejecuta en el momento en que el agente consulta la lista de Issues del repositorio público
• El usuario dispara el ataque al enviar una solicitud a Claude 4 Opus
  • Claude Desktop exige por defecto confirmación del usuario para cada llamada de herramienta individual
  • Muchos usuarios eligen la política de confirmación “Always Allow” al usar agentes y dejan de vigilar cada acción individual
• El agente recorre la lista de Issues, encuentra la carga maliciosa, trae datos de repositorios privados al contexto y luego los filtra en un pull request del repositorio pacman
• El PR público incluye información privada del usuario ukend0464
  • Información de repositorios privados como Jupiter Star
  • Planes para mudarse a Sudamérica
  • Información salarial
• Toda la secuencia de razonamiento del agente y uso de herramientas puede verse en el trace completo de Invariant Explorer

Toxic Agent Flow también en herramientas confiables

• Esta vulnerabilidad es distinta de los ataques tradicionales de contaminación de herramientas, donde la herramienta MCP en sí debe estar comprometida
• Si un agente conectado a una plataforma externa como GitHub queda expuesto a información no confiable, el problema puede aparecer incluso cuando la herramienta es totalmente confiable
• Entender, analizar y mitigar estos flujos en sistemas de agentes es algo difícil de hacer manualmente a gran escala
• Invariant está desarrollando métodos automatizados para detectar Toxic Agent Flows y ayudar a las organizaciones a identificar y modelar amenazas potenciales antes de que actores maliciosos las exploten

Alcance y mitigaciones

• El experimento se centró en Claude Desktop, pero la vulnerabilidad no se limita a un agente o cliente MCP específico
• Cualquier agente que use el servidor GitHub MCP puede verse afectado, sin importar el modelo base o la implementación
• Lo importante es que este problema no es un fallo del código del propio servidor GitHub MCP
  • No es una vulnerabilidad que GitHub pueda resolver por sí solo con un parche del lado del servidor
  • Es un problema estructural que debe abordarse a nivel del sistema de agentes

• Control de permisos granular

  • Al usar integraciones MCP como GitHub, el acceso del agente debe limitarse a los repositorios necesarios
  • Los permisos tradicionales basados en tokens ofrecen cierta protección, pero pueden imponer restricciones rígidas que limitan la funcionalidad del agente
  • Invariant recomienda una capa de seguridad dinámica en tiempo de ejecución adaptada a sistemas de agentes
  • Invariant Guardrails ofrece control de acceso con conciencia de contexto que se adapta al flujo de trabajo del agente
  • Un ejemplo de política limita el acceso a un solo repositorio por sesión para evitar fugas de información entre repositorios
  • Si se encadenan llamadas a herramientas relacionadas con repositorios de distinto repo o owner, se considera una infracción
  • La política completa puede consultarse en github_policy.txt
  • El método de aplicación está en la documentación de MCP-scan
  • Las políticas pueden probarse antes del despliegue en el Guardrails Playground

• Monitoreo de seguridad continuo

  • Además de las medidas preventivas, hace falta monitoreo para detección y respuesta a amenazas en tiempo real
  • Invariant recomienda desplegar escáneres de seguridad dedicados como MCP-scan para auditar de forma continua las interacciones entre agentes y sistemas MCP
  • El modo proxy de MCP-scan permite escanear conexiones MCP en tiempo real sin modificar la infraestructura existente de agentes
  • Al enrutar el tráfico MCP a través de un proxy, se obtiene visibilidad y escaneo en tiempo real de violaciones de seguridad
  • Un monitoreo integral crea trazas de auditoría que ayudan a verificar vulnerabilidades potenciales, intentos de explotación y el estado de protección frente a nuevos ataques

La alineación del modelo por sí sola no basta

• En el experimento se usó Claude 4 Opus, con entrenamiento reciente de alineación y seguridad
• Incluso con un entrenamiento sólido de seguridad, el agente pudo ser manipulado mediante una inyección de prompts relativamente simple
• Muchas defensas existentes de detección de inyección de prompts tampoco lograron detener este ataque
• La seguridad de los sistemas de agentes depende del contexto y del entorno
  • El entrenamiento general de alineación del modelo no puede anticipar todos los escenarios de despliegue ni los requisitos de seguridad de cada organización
  • Las medidas de seguridad a nivel sistema deben complementar las protecciones a nivel modelo

Retos pendientes en la seguridad de agentes

• Los agentes que usan el servidor GitHub MCP pueden ser manipulados mediante un Issue malicioso de GitHub para filtrar datos de repositorios privados hacia repositorios públicos
• Aunque esta vulnerabilidad está especializada en GitHub MCP, ataques similares siguen apareciendo en otros entornos
  • Legit Security reportó recientemente una vulnerabilidad de inyección remota de prompts en GitLab Duo
• Para un despliegue responsable a gran escala, las integraciones MCP y los sistemas de agentes necesitan escáneres de seguridad y controles de políticas dedicados, como MCP-scan y Guardrails

[crawler]

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.