Se descubrió una vulnerabilidad en el servidor MCP de Azure DevOps de Microsoft que permite ataques de inyección de prompts indirectos mediante comentarios HTML invisibles en las descripciones de pull requests. Un atacante puede engañar al agente de IA de un revisor para que acceda a proyectos confidenciales y filtre datos usando los permisos del usuario afectado. El problema radica en que Microsoft omitió una protección de seguridad ya implementada en otras herramientas del mismo servidor.

Un solo comentario invisible en una solicitud de extracción (pull request) de Azure DevOps puede volver contra ti a tu propio agente de codificación de IA, impulsándolo hacia proyectos a los que el atacante no tiene derechos de acceso y filtrando silenciosamente lo que encuentre.

El fallo reside en el servidor MCP oficial de Azure DevOps de Microsoft [https://github.com/microsoft/azure-devops-mcp], y funciona porque una de sus herramientas devuelve descripciones de pull requests sin una barrera de protección contra la inyección de prompts que la empresa ya había aplicado a otras.

La firma de seguridad ofensiva Manifold Security [https://www.manifold.security/blog/azure-devops-mcp-server-vulnerability] detalló este error de "delegado confundido" esta semana. Microsoft distribuye el servidor para que los agentes de IA puedan leer y operar Azure DevOps para un usuario, a través de pull requests, canalizaciones (pipelines), wikis y elementos de trabajo, todo con los permisos del propio usuario. Ese es precisamente el problema: el contenido que escribieron otras personas puede convertirse en instrucciones que el agente ejecuta.

Las descripciones de PR de Azure DevOps aceptan Markdown, lo que permite comentarios HTML. En la interfaz web, un comentario HTML (<!-- ... -->) no se muestra, por lo que un revisor que se desplace por la descripción verá un cambio ordinario. Sin embargo, la API REST lo devuelve textualmente y el servidor entrega ese texto directamente al agente.

Esa diferencia entre lo que ve el humano y lo que recibe el modelo es el mecanismo de entrega: el atacante nunca habla con el agente, sino que planta instrucciones en el contenido que sabe que este leerá más tarde.

Cuando pides a tu agente que revise el PR, el texto oculto puede reescribir el objetivo del agente. El agente utiliza tus credenciales de revisor, por lo que puede actuar en proyectos a los que el atacante no tiene acceso.

Manifold afirma que el acceso alcanza el código fuente, secretos y elementos de trabajo, no solo la página de la wiki que exfiltró su prueba de concepto. La firma califica esta escalada como el caso normal, ya que los revisores suelen tener un cargo superior al de quien abrió el pull request. El atacante no gana nada directamente; toma prestado tu acceso a través de un texto que nunca ves.

La ruta de la solicitud de extracción omitió la barrera de protección

Lo que eleva esto por encima de una advertencia genérica de inyección de prompts es que Microsoft ya había implementado una defensa para ello. Al leer el código fuente del servidor, Manifold descubrió que utiliza "spotlighting", una técnica de la propia guía de Microsoft sobre inyección indirecta de prompts [https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks]: envuelve el contenido no confiable en delimitadores para que el modelo pueda distinguir los datos de las instrucciones que debe seguir.

La empresa lo añadió en el PR #1062 [https://github.com/microsoft/azure-devops-mcp/pull/1062], donde las herramientas de página de wiki y registros de compilación pasan su salida a través de un ayudante compartido, createExternalContentResponse. La herramienta que devuelve un pull request, repo_get_pull_request_by_id, nunca lo llama, por lo que devuelve la descripción en bruto, que es exactamente la superficie donde escribe el atacante.

Se confirmó que la misma ruta [https://github.com/microsoft/azure-devops-mcp/blob/main/src/tools/repositories.ts] seguía sin protección en el código fuente actual hasta el 21 de julio.

En la prueba de concepto de Manifold, ejecutada en una compilación local de la v2.7.0, un colaborador de un proyecto abre un PR de aspecto normal cuyo comentario oculto lleva la carga útil. Una vez que el agente comienza su revisión, la traza de la herramienta ejecuta una cadena: activa una canalización en un proyecto diferente, lee una página de wiki confidencial que el atacante no puede abrir y publica esa página como un comentario en el PR, donde el atacante puede leerla.

Un solo comentario oculto impulsó toda la secuencia, y cada llamada fue una que el agente tenía permitido hacer. El problema, escribieron los investigadores, fue "la secuencia y la intención, impulsadas por un texto que un humano nunca vio". El equipo lo reprodujo tanto con Copilot CLI como con Claude Code, por lo que no está ligado a un solo agente.

Sin embargo, la cadena tiene requisitos previos: texto de PR escrito por el atacante, un flujo de trabajo que lo envíe a un agente, un revisor cuyo acceso supere al del atacante y un agente autorizado para ejecutar herramientas sin preguntar.

Manifold confirmó que probó esto último como una postura de auto-aprobación sin prompts por herramienta, el punto de control que, de otro modo, permitiría a un revisor detectar una ejecución de canalización extraña entre proyectos antes de que se dispare. El riesgo se concentra en un token amplio sumado a esa postura de configuración.

La demostración supone que una persona inicia la revisión, pero Manifold señala hacia dónde se dirigen los equipos: revisión automatizada, triaje y resúmenes activados por disparadores, sin que un humano solicite cada ejecución o lea cada resultado. En esa configuración, la descripción plantada se activa por sí sola y la filtración dura más tiempo antes de que alguien lo note.

Este patrón no es nuevo. En mayo de 2025, Invariant Labs mostró el mismo tipo de ataque contra el servidor MCP de GitHub [https://invariantlabs.ai/blog/mcp-github-vulnerability], utilizando un problema público para obligar a un agente a leer un repositorio privado y filtrarlo a través de un pull request; la misma técnica ha llegado desde entonces a los flujos de trabajo automatizados de agentes de GitHub.

Ese caso fue uno de los ejemplos que Simon Willison señaló al nombrar la "trifecta letal" [https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/]: un agente con acceso a datos privados, exposición a contenido no confiable y una forma de enviar datos al exterior. Cualquier agente con estas tres características puede ser vuelto contra su dueño mediante un trozo de texto, y la mayoría de los agentes útiles tienen las tres.

Un portavoz de Microsoft agradeció a Manifold por reportar el comportamiento bajo divulgación coordinada y lo calificó como "una clase conocida de riesgo de IA" que informa el trabajo continuo de la empresa en sus salvaguardas. Microsoft no indicó si cambiaría el código o asignaría un CVE.

Señaló que el ataque requiere que un atacante ya tenga acceso de escritura a un proyecto y que un segundo usuario invoque una herramienta de IA sobre el contenido, y recomendó a los clientes limitar el acceso a los proyectos y "revisar los cambios propuestos antes de pedir a una herramienta de IA que actúe sobre ellos". El problema es que la carga útil aquí es invisible en la interfaz que revisa el humano.

Hasta el 21 de julio, no hay una versión corregida y no se encontró ningún CVE asignado al fallo en las bases de datos públicas. La última versión, v2.8.0 [https://github.com/microsoft/azure-devops-mcp/releases/tag/v2.8.0], fue lanzada el 24 de junio. Ningún informe público sitúa la técnica en uso fuera de las propias pruebas de Manifold.

Manifold probó solo el servidor local basado en PAT, pero dijo que la causa raíz está "en el código del servidor, no en el transporte". Bajo esa lógica, el servidor MCP remoto alojado [https://devblogs.microsoft.com/devops/azure-devops-remote-mcp-server-public-preview] también estaría expuesto, aunque Manifold no lo probó y Microsoft no lo abordó.

El "spotlighting" eleva el listón pero no cierra la inyección de prompts por sí solo, por lo que las defensas son las habituales. Dale al agente tokens de privilegio mínimo y limítalo al proyecto bajo revisión. Carga solo los dominios MCP que la tarea necesite; el servidor local los reduce con el flag -d.

Mantén las ejecuciones de canalización, las lecturas de wiki y la publicación de comentarios fuera de un conjunto de herramientas de revisión de código que no los necesite. Para comprobar si la cadena ya se ha ejecutado, busca en las trazas de herramientas del agente ejecuciones de canalizaciones entre proyectos, lecturas de wiki o comentarios que haya publicado durante una revisión, y escanea las descripciones de los PR abiertos en busca de comentarios HTML ocultos. Un revisor humano que no puede ver la carga útil no es un control eficaz.

La barrera de protección solo funciona donde alguien recuerda añadirla. Envuelve el contenido no confiable una ruta de respuesta a la vez, por lo que la defensa es tan fuerte como su ruta menos cubierta, y la falta de un envoltorio en una sola función es casi invisible desde el exterior. En una superficie de herramientas que sigue creciendo, brechas como esta se abren más rápido de lo que nadie piensa en auditarlas.

Fuente:
THN